mirror of
https://github.com/duthaho/claudekit.git
synced 2026-07-17 13:15:16 +03:00
Add new methodology skills for enhanced development workflows
This commit is contained in:
@@ -0,0 +1,239 @@
|
||||
# Requesting Code Review
|
||||
|
||||
## Description
|
||||
|
||||
Workflow for initiating code reviews with clear scope, context, and expectations. Ensures reviewers have everything needed for effective feedback.
|
||||
|
||||
## When to Use
|
||||
|
||||
- After completing a task (before proceeding to next)
|
||||
- After implementing a feature
|
||||
- Before merging to main branch
|
||||
- When unsure about implementation approach
|
||||
- After fixing critical bugs
|
||||
|
||||
---
|
||||
|
||||
## Review Request Components
|
||||
|
||||
### 1. Scope Definition
|
||||
|
||||
Clearly state what should be reviewed:
|
||||
|
||||
```markdown
|
||||
## Review Scope
|
||||
|
||||
**Files changed**:
|
||||
- src/services/user-service.ts (modified)
|
||||
- src/services/user-service.test.ts (added)
|
||||
- src/types/user.ts (modified)
|
||||
|
||||
**Lines changed**: ~150 additions, ~20 deletions
|
||||
|
||||
**Not in scope** (don't review):
|
||||
- package.json changes (unrelated dependency update)
|
||||
- Generated files in dist/
|
||||
```
|
||||
|
||||
### 2. Context
|
||||
|
||||
Explain why these changes were made:
|
||||
|
||||
```markdown
|
||||
## Context
|
||||
|
||||
**Task**: Implement user email verification
|
||||
|
||||
**Requirements**:
|
||||
- Users must verify email before accessing features
|
||||
- Verification link expires after 24 hours
|
||||
- Users can request new verification email
|
||||
|
||||
**Design decisions**:
|
||||
- Used JWT for verification token (stateless)
|
||||
- Stored verification status in existing User table
|
||||
```
|
||||
|
||||
### 3. Areas of Concern
|
||||
|
||||
Highlight where you want focused attention:
|
||||
|
||||
```markdown
|
||||
## Areas of Concern
|
||||
|
||||
1. **Security**: Is the token generation secure enough?
|
||||
2. **Error handling**: Are all edge cases covered?
|
||||
3. **Performance**: Will the verification lookup be efficient?
|
||||
```
|
||||
|
||||
### 4. Test Coverage
|
||||
|
||||
Show what's tested:
|
||||
|
||||
```markdown
|
||||
## Test Coverage
|
||||
|
||||
- Unit tests: 8 new tests in user-service.test.ts
|
||||
- Integration: Manual testing of full flow
|
||||
- Edge cases: Expired token, invalid token, already verified
|
||||
|
||||
**Not tested** (known gaps):
|
||||
- Load testing with many concurrent verifications
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Review Request Template
|
||||
|
||||
```markdown
|
||||
## Code Review Request
|
||||
|
||||
### Summary
|
||||
[1-2 sentence description of changes]
|
||||
|
||||
### Files Changed
|
||||
- `path/to/file1.ts` - [Brief description]
|
||||
- `path/to/file2.ts` - [Brief description]
|
||||
|
||||
### Context
|
||||
[Why these changes were needed]
|
||||
|
||||
### Implementation Notes
|
||||
[Key decisions made and why]
|
||||
|
||||
### Areas for Focus
|
||||
1. [Specific concern 1]
|
||||
2. [Specific concern 2]
|
||||
|
||||
### Testing
|
||||
- [x] Unit tests added/updated
|
||||
- [x] Integration tests pass
|
||||
- [ ] E2E tests (not applicable)
|
||||
|
||||
### Checklist
|
||||
- [x] Code follows project conventions
|
||||
- [x] No security vulnerabilities introduced
|
||||
- [x] Documentation updated if needed
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What to Include
|
||||
|
||||
### Always Include
|
||||
|
||||
- List of changed files
|
||||
- Summary of what changed
|
||||
- Why the change was needed
|
||||
- Test status
|
||||
|
||||
### Include When Relevant
|
||||
|
||||
- Design alternatives considered
|
||||
- Performance implications
|
||||
- Security considerations
|
||||
- Breaking changes
|
||||
|
||||
### Never Include
|
||||
|
||||
- Unrelated changes
|
||||
- Formatting-only commits
|
||||
- Debug code
|
||||
- TODO comments (resolve first)
|
||||
|
||||
---
|
||||
|
||||
## Review Types
|
||||
|
||||
### Quick Review
|
||||
|
||||
For small, low-risk changes:
|
||||
|
||||
```markdown
|
||||
## Quick Review: Fix typo in error message
|
||||
|
||||
**File**: src/errors.ts
|
||||
**Change**: Fixed "recieved" → "received" in error message
|
||||
**Risk**: None
|
||||
```
|
||||
|
||||
### Standard Review
|
||||
|
||||
For typical feature work:
|
||||
|
||||
```markdown
|
||||
## Review: Add user preferences
|
||||
|
||||
**Files**: 3 files, ~200 lines
|
||||
**Context**: Users can now save display preferences
|
||||
**Focus**: Data validation, storage approach
|
||||
```
|
||||
|
||||
### Critical Review
|
||||
|
||||
For high-risk changes:
|
||||
|
||||
```markdown
|
||||
## CRITICAL REVIEW: Authentication refactor
|
||||
|
||||
**Files**: 12 files, ~800 lines
|
||||
**Risk**: HIGH - Authentication system changes
|
||||
**Required reviewers**: Security team
|
||||
**Focus**: Token handling, session management, encryption
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Keep Reviews Focused
|
||||
|
||||
```markdown
|
||||
BAD: "Review my last week of work"
|
||||
GOOD: "Review the user verification feature (3 files)"
|
||||
```
|
||||
|
||||
### Provide Runnable Context
|
||||
|
||||
```markdown
|
||||
## To test locally
|
||||
1. git checkout feature/email-verification
|
||||
2. npm install
|
||||
3. npm test -- --grep "email verification"
|
||||
```
|
||||
|
||||
### Be Specific About Concerns
|
||||
|
||||
```markdown
|
||||
BAD: "Let me know if anything looks wrong"
|
||||
GOOD: "I'm unsure about the error handling in lines 45-60"
|
||||
```
|
||||
|
||||
### Include Relevant Links
|
||||
|
||||
```markdown
|
||||
Related:
|
||||
- Ticket: PROJ-123
|
||||
- Design doc: [link]
|
||||
- Previous discussion: [link]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## After Submitting
|
||||
|
||||
### What to Expect
|
||||
|
||||
```markdown
|
||||
Reviewer will return:
|
||||
- Critical issues (must fix)
|
||||
- Important issues (should fix)
|
||||
- Minor issues (optional)
|
||||
- Approval/rejection status
|
||||
```
|
||||
|
||||
### How to Handle Feedback
|
||||
|
||||
See `receiving-code-review` skill for detailed guidance.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user