135 lines
4.6 KiB
Markdown
135 lines
4.6 KiB
Markdown
# Brotherhood Review Task
|
|
|
|
## Purpose
|
|
Conduct honest, rigorous peer review to ensure quality and eliminate sycophantic behavior.
|
|
|
|
## Review Protocol
|
|
|
|
### Pre-Review Requirements
|
|
- [ ] Self-assessment completed honestly
|
|
- [ ] All quality gates passed
|
|
- [ ] UDTM documentation provided
|
|
- [ ] Real implementation verified (no mocks/stubs)
|
|
|
|
### Review Dimensions
|
|
|
|
#### 1. Technical Review
|
|
- [ ] **Code Quality**: Clean, maintainable, follows standards
|
|
- [ ] **Architecture**: Consistent with existing patterns
|
|
- [ ] **Performance**: Meets requirements, no obvious bottlenecks
|
|
- [ ] **Security**: No vulnerabilities, proper error handling
|
|
|
|
#### 2. Logic Review
|
|
- [ ] **Solution Appropriateness**: Best approach for the problem
|
|
- [ ] **Requirement Alignment**: Meets all specified requirements
|
|
- [ ] **Edge Case Handling**: Proper boundary condition management
|
|
- [ ] **Integration**: Works properly with existing systems
|
|
|
|
#### 3. Reality Check (CRITICAL)
|
|
- [ ] **Actually Works**: Functionality verified through testing
|
|
- [ ] **No Shortcuts**: Real implementation, not workarounds
|
|
- [ ] **Production Ready**: Would survive in production environment
|
|
- [ ] **Error Scenarios**: Handles failures gracefully
|
|
|
|
#### 4. Quality Standards
|
|
- [ ] **Zero Violations**: No Ruff or MyPy errors
|
|
- [ ] **Test Coverage**: Adequate and meaningful tests
|
|
- [ ] **Documentation**: Clear, accurate, complete
|
|
- [ ] **Maintainability**: Future developers can understand/modify
|
|
|
|
### Honest Assessment Questions
|
|
1. **Does this actually work as claimed?**
|
|
2. **Are there any shortcuts or workarounds?**
|
|
3. **Would this break in production?**
|
|
4. **Is this the best solution to the problem?**
|
|
5. **Am I being completely honest about the quality?**
|
|
|
|
### Review Process
|
|
|
|
#### Step 1: Independent Analysis (30 minutes)
|
|
- Review all artifacts without discussion
|
|
- Complete technical analysis independently
|
|
- Document initial findings and concerns
|
|
- Prepare specific questions and feedback
|
|
|
|
#### Step 2: Collaborative Discussion (15 minutes)
|
|
- Share findings openly and honestly
|
|
- Challenge assumptions and approaches
|
|
- Identify gaps and improvement opportunities
|
|
- Reach consensus on quality assessment
|
|
|
|
#### Step 3: Action Planning (15 minutes)
|
|
- Define specific improvement actions
|
|
- Assign ownership and timelines
|
|
- Establish re-review criteria if needed
|
|
- Document decisions and rationale
|
|
|
|
### Review Outcomes
|
|
- **APPROVE**: All criteria met, no issues identified
|
|
- **CONDITIONAL**: Minor fixes required, re-review needed within 24 hours
|
|
- **REJECT**: Major issues, return to planning/implementation phase
|
|
|
|
### Brotherhood Principles
|
|
- **Honesty First**: Truth over politeness
|
|
- **Quality Focus**: Excellence over speed
|
|
- **Mutual Support**: Help improve, don't just critique
|
|
- **Root Cause**: Address underlying issues, not symptoms
|
|
- **Continuous Improvement**: Learn from every review
|
|
|
|
## Anti-Sycophantic Enforcement
|
|
|
|
### Forbidden Responses
|
|
- "Looks good" without specific analysis
|
|
- "Great work" without identifying actual strengths
|
|
- "Minor issues" when major problems exist
|
|
- Agreement without independent verification
|
|
|
|
### Required Evidence
|
|
- Specific examples of quality or issues
|
|
- Reference to standards and best practices
|
|
- Demonstration of actual functionality testing
|
|
- Clear reasoning for all assessments
|
|
|
|
## Review Documentation
|
|
|
|
### Review Record Template
|
|
```markdown
|
|
## Brotherhood Review: [Task/Story Name]
|
|
**Date**: [YYYY-MM-DD]
|
|
**Reviewer**: [Name]
|
|
**Reviewee**: [Name]
|
|
|
|
### Technical Assessment
|
|
- **Code Quality**: [Specific findings]
|
|
- **Architecture**: [Specific findings]
|
|
- **Performance**: [Specific findings]
|
|
- **Security**: [Specific findings]
|
|
|
|
### Reality Check Results
|
|
- **Functionality Test**: [Pass/Fail with evidence]
|
|
- **Production Readiness**: [Assessment with reasoning]
|
|
- **Error Handling**: [Specific scenarios tested]
|
|
|
|
### Honest Assessment
|
|
- **Strengths**: [Specific examples]
|
|
- **Weaknesses**: [Specific issues with impact]
|
|
- **Recommendations**: [Actionable improvements]
|
|
|
|
### Final Decision
|
|
- **Outcome**: [Approve/Conditional/Reject]
|
|
- **Confidence**: [1-10 with reasoning]
|
|
- **Next Steps**: [Specific actions required]
|
|
```
|
|
|
|
## Success Criteria
|
|
- Honest evaluation with documented findings
|
|
- Specific recommendations for improvement
|
|
- Confidence in production readiness
|
|
- Team knowledge sharing achieved
|
|
- Quality standards maintained or improved
|
|
|
|
## Integration with BMAD Workflow
|
|
- **Required for**: All story completion, architecture decisions, deployment
|
|
- **Frequency**: At minimum before story done, optionally mid-implementation
|
|
- **Documentation**: All reviews tracked in project quality metrics
|
|
- **Learning**: Review insights feed back into process improvement |