Setting the file. One moment.
Chapter 56 · Reviewing Claude Config
Subchapter 56.12
examples/example-prompts-review.mdMarkdown5 KBView on GitHub
Context: Reviewing a new slash command prompt.
.claude/commands/review-feature.md:1 - IMPORTANT: Missing usage information
Add usage format and example after description:
# review-feature
Reviews a feature implementation for architectural compliance and code quality.
**Usage:** /review-feature <feature-name>
**Example:** /review-feature user-authentication
This command analyzes all files related to the specified feature.Users need clear invocation syntax. Without it, they may guess incorrectly or not use the command at all.
.claude/commands/review-feature.md:10 - IMPORTANT: Vague instructions
Current: “Look at the code and check for issues.”
Change to specific criteria:
Analyze feature implementation for:
1. **Architecture Compliance**
- MVVM pattern adherence
- Proper dependency injection
- Module boundaries respected
2. **Code Quality**
- Error handling (Result types)
- Null safety
- KDoc documentation on public APIs
3. **Testing**
- Unit tests for business logic
- UI tests for user flows
- Edge cases coveredSpecific criteria ensure consistent, thorough reviews.
Reference: Prompt engineering - Specificity
.claude/commands/review-feature.md:25 - SUGGESTED: Add expected output format
Show reviewers what the output should look like:
**Expected Output Format:**
\```
## Feature: [name]
### Architecture: ✅ Pass / ❌ Issues Found
[Details]
### Code Quality: ✅ Pass / ❌ Issues Found
[Details]
### Testing: ✅ Pass / ❌ Issues Found
[Details]
\```Explicit output format improves consistency and clarity.
.claude/commands/review-feature.md:30 - SUGGESTED: Reference existing skill
If a reviewing-changes skill exists, consider referencing it:
## Implementation
Use the `reviewing-changes` skill with feature-addition checklist:
1. Identify all files in feature scope
2. Apply feature-addition review checklist
3. Document findings in structured format aboveReusing existing skills improves consistency and reduces duplication.
Overall Assessment: REQUEST CHANGES
Must Fix (IMPORTANT):
Nice to Have (SUGGESTED):
The core concept is good - this command would be very useful once the instructions are clarified and the usage format is documented.
DON’T DO THIS:
**Overall Review**
I found these issues:
1. Missing YAML frontmatter on line 1
2. File too long (line 1-650)
3. No structured thinking (line 45)
4. Missing examples (line 120)
...Why this is bad:
DO THIS INSTEAD: Create separate inline comment for EACH issue on the specific line.
DON’T DO THIS:
**file.kt:50** - You clearly don't understand MVVM. This is completely wrong.Why this is bad:
DO THIS INSTEAD:
**file.kt:50** - IMPORTANT: Exposes mutable state
ViewModels should expose StateFlow, not MutableStateFlow:
[code example]
This prevents external mutation, enforcing unidirectional data flow.
Reference: docs/ARCHITECTURE.md#mvvm-patternFocus on code, provide rationale, offer solution.
DON’T DO THIS:
**file.kt:100** - This could be better.Why this is bad:
DO THIS INSTEAD:
**file.kt:100** - SUGGESTED: Extract complex logic to separate function
Current function is 50 lines with nested conditions. Consider extracting validation logic:
[before/after code example]
Improves readability and testability.Specific issue, concrete solution, clear rationale.
DON’T DO THIS:
**settings.json:5** - Overly broad permissions.Why this is bad:
DO THIS INSTEAD:
**settings.json:5** - CRITICAL: Overly broad permissions
[specific fix]
[security rationale]
This must be fixed before approval.Clear priority, specific fix, explicit blocking status.