Apply Recommendations Command Reference
Triage and apply recommendations from reviews.
Purpose
Analyze recommendations from code/test reviews and intelligently split them into immediate actions (apply now) and deferred tasks (create follow-up).
When Used in Workflow
- Task Cycle: After reviews, when issues were found
- Conditionally invoked based on review results
Common Invocation Patterns
apply-recommendations [review-output]
apply-recommendations --quick-only # Only low-risk fixes
apply-recommendations --defer-all # Convert all to tasks
apply-recommendations --dry-run # Preview without applyingCore Principle: Smart Triage
Not all recommendations are equal. Some should be fixed immediately, others need planning. The decision matrix:
APPLY NOW if ALL of:
- Effort: Trivial or Small
- Risk: Low or (Medium with good test coverage)
- Dependencies: Independent or Local
- Clear fix is obvious
- Won't break existing functionality
DEFER TO TASK if ANY of:
- Effort: Large
- Risk: High
- Dependencies: System or Team
- Requires design decisions
- Needs performance benchmarking
- Could introduce breaking changes
Assessment Criteria
Effort Required
- Trivial: < 5 minutes, single line changes
- Small: 5-30 minutes, single file
- Medium: 30-60 minutes, 2-3 files
- Large: > 60 minutes, multiple files/systems
Risk Level
- Low: Style, documentation, isolated cleanup
- Medium: Logic changes, refactoring with tests
- High: Architecture, external APIs, data handling
Dependencies
- Independent: Can be done in isolation
- Local: Requires understanding of immediate context
- System: Requires broader architectural knowledge
- Team: Needs discussion or approval
Category Handling
Critical Security Issues → ALWAYS APPLY NOW
- Hardcoded secrets/credentials
- SQL injection vulnerabilities
- XSS vulnerabilities
- Exposed sensitive data
High Priority Bugs → USUALLY APPLY NOW
- Null reference errors
- Unhandled promise rejections
- Memory leaks (if isolated)
- Clear logic errors
Code Quality → SELECTIVE
Apply Now:
- Dead code removal
- Obvious duplications (< 10 lines)
- Simple variable renames
- Missing error handling (simple cases)
Defer:
- Large-scale refactoring
- Architecture changes
- Complex abstraction creation
Test Improvements → USUALLY APPLY NOW
- Adding missing assertions
- Fixing tautological tests
- Improving test names
- Fixing test isolation
Documentation → APPLY NOW
- Adding missing comments
- Updating incorrect docs
- Clarifying confusing names
Output Format
# Recommendation Application Report
## Summary
- Total recommendations: X
- Applied immediately: Y
- Deferred to tasks: Z
## Applied Immediately
### 1. [Recommendation Title]
**Type**: [Security/Bug/Quality/Test/Documentation]
**Files Modified**:
- `path/to/file.ts` - [What changed]
**Risk**: Low
## Deferred to Tasks
### High Priority
#### Task: [Clear Task Title]
**Original Recommendation**: [What was recommended]
**Why Deferred**: [Reason]
**Effort Estimate**: [Size]
**Created at**: `/tasks/[type]/[filename].md`
## Validation
- [ ] All tests pass
- [ ] Linting passes
- [ ] No regressions detected
## Next Steps
1. Review applied changes
2. Run full test suite
3. Review high-priority deferred tasksQuality Guidelines
- Never break working code - If unsure, defer
- Maintain test coverage - Add tests for bug fixes
- Preserve behavior - Refactoring shouldn't change functionality
- Document decisions - Explain why items were deferred
- Incremental progress - Many small improvements > one risky change
Orchestration Notes
After applying recommendations:
- If all applied successfully: ready for PR prep
- If issues remain: loop back to review
- Deferred tasks are created but don't block workflow