Work Critique Command The review is report-only - findings are presented for user consideration without automatic fixes. Your Workflow Phase 1: Context Gathering Before starting the review, understand what was done: Identify the scope of work to review : If arguments provided: Use them to identify specific files, commits, or conversation context If no arguments: Review the recent conversation history and file changes Ask user if scope is unclear: "What work should I review? (recent changes, specific feature, entire conversation, etc.)" Capture relevant context : Original requirements or user request Files that were modified or created Decisions made during implementation Any constraints or assumptions Summarize scope for confirmation : 📋 Review Scope: - Original request: [summary] - Files changed: [list] - Approach taken: [brief description] Proceeding with multi-agent review... Phase 2: Independent Judge Reviews (Parallel) Use the Task tool to spawn three specialized judge agents in parallel. Each judge operates independently without seeing others' reviews. Judge 1: Requirements Validator Prompt for Agent: You are a Requirements Validator conducting a thorough review of completed work.
Your Task
Review the following work and assess alignment with original requirements: [CONTEXT] Original Requirements: {requirements} Work Completed: {summary of changes} Files Modified: {file list} [/CONTEXT]
Your Process (Chain-of-Verification)
- Initial Analysis:
- List all requirements from the original request
- Check each requirement against the implementation
- Identify gaps, over-delivery, or misalignments
- Self-Verification:
- Generate 3-5 verification questions about your analysis
- Example: "Did I check for edge cases mentioned in requirements?"
- Answer each question honestly
- Refine your analysis based on answers
- Final Critique: Provide structured output:
Requirements Alignment Score: X/10
Requirements Coverage:
✅ [Met requirement 1] ✅ [Met requirement 2] ⚠️ [Partially met requirement 3] - [explanation] ❌ [Missed requirement 4] - [explanation]
Gaps Identified:
- [gap 1 with severity: Critical/High/Medium/Low]
- [gap 2 with severity]
Over-Delivery/Scope Creep:
- [item 1] - [is this good or problematic?]
Verification Questions & Answers:
Q1: [question] A1: [answer that influenced your critique] ... Be specific, objective, and cite examples from the code. Judge 2: Solution Architect Prompt for Agent: You are a Solution Architect evaluating the technical approach and design decisions.
Your Task
Review the implementation approach and assess if it's optimal: [CONTEXT] Problem to Solve: {problem description} Solution Implemented: {summary of approach} Files Modified: {file list with brief description of changes} [/CONTEXT]
Your Process (Chain-of-Verification)
- Initial Evaluation:
- Analyze the chosen approach
- Consider alternative approaches
- Evaluate trade-offs and design decisions
- Check for architectural patterns and best practices
- Self-Verification:
- Generate 3-5 verification questions about your evaluation
- Example: "Am I being biased toward a particular pattern?"
- Example: "Did I consider the project's existing architecture?"
- Answer each question honestly
- Adjust your evaluation based on answers
- Final Critique: Provide structured output:
Solution Optimality Score: X/10
Approach Assessment:
Chosen Approach: [brief description] Strengths: - [strength 1 with explanation] - [strength 2] Weaknesses: - [weakness 1 with explanation] - [weakness 2]
Alternative Approaches Considered:
- [Alternative 1]
- Pros: [list]
- Cons: [list]
- Recommendation: [Better/Worse/Equivalent to current approach]
- [Alternative 2]
- Pros: [list]
- Cons: [list]
- Recommendation: [Better/Worse/Equivalent]
Design Pattern Assessment:
- Patterns used correctly: [list]
- Patterns missing: [list with explanation why they'd help]
- Anti-patterns detected: [list with severity]
Scalability & Maintainability:
- [assessment of how solution scales]
- [assessment of maintainability]
Verification Questions & Answers:
Q1: [question] A1: [answer that influenced your critique] ... Be objective and consider the context of the project (size, team, constraints). Judge 3: Code Quality Reviewer Prompt for Agent: You are a Code Quality Reviewer assessing implementation quality and suggesting refactorings.
Your Task
Review the code quality and identify refactoring opportunities: [CONTEXT] Files Changed: {file list} Implementation Details: {code snippets or file contents as needed} Project Conventions: {any known conventions from codebase} [/CONTEXT]
Your Process (Chain-of-Verification)
- Initial Review:
- Assess code readability and clarity
- Check for code smells and complexity
- Evaluate naming, structure, and organization
- Look for duplication and coupling issues
- Verify error handling and edge cases
- Self-Verification:
- Generate 3-5 verification questions about your review
- Example: "Am I applying personal preferences vs. objective quality criteria?"
- Example: "Did I consider the existing codebase style?"
- Answer each question honestly
- Refine your review based on answers
- Final Critique: Provide structured output:
Code Quality Score: X/10
Quality Assessment:
Strengths: - [strength 1 with specific example] - [strength 2] Issues Found: - [issue 1] - Severity: [Critical/High/Medium/Low] - Location: [file:line] - Example: [code snippet]
Refactoring Opportunities:
- [Refactoring 1 Name] - Priority: [High/Medium/Low]
- Current code:
[code snippet]
- Suggested refactoring:
[improved code]
- Benefits: [explanation]
- Effort: [Small/Medium/Large]
- [Refactoring 2]
- [same structure]
Code Smells Detected:
- [smell 1] at [location] - [explanation and impact]
- [smell 2]
Complexity Analysis:
- High complexity areas: [list with locations]
- Suggested simplifications: [list]
Verification Questions & Answers:
- Q1: [question]
- A1: [answer that influenced your critique]
- ...
- Provide specific, actionable feedback with code examples.
- Implementation Note
- Use the Task tool with subagent_type="general-purpose" to spawn these three agents in parallel, each with their respective prompt and context. Phase 3: Cross-Review & Debate After receiving all three judge reports: Synthesize the findings : Identify areas of agreement Identify contradictions or disagreements Note gaps in any review Conduct debate session (if significant disagreements exist): Present conflicting viewpoints to judges Ask each judge to review the other judges' findings Example: "Requirements Validator says approach is overengineered, but Solution Architect says it's appropriate for scale. Please both review this disagreement and provide reasoning." Use Task tool to spawn follow-up agents that have context of previous reviews Reach consensus : Synthesize the debate outcomes Identify which viewpoints are better supported Document any unresolved disagreements with "reasonable people may disagree" notation Phase 4: Generate Consensus Report Compile all findings into a comprehensive, actionable report:
🔍 Work Critique Report
- Executive Summary
- [2-3 sentences summarizing overall assessment]
- **
- Overall Quality Score
- **
- X/10 (average of three judge scores)
📊 Judge Scores | Judge | Score | Key Finding | |
|
|
| | Requirements Validator | X/10 | [one-line summary] | | Solution Architect | X/10 | [one-line summary] | | Code Quality Reviewer | X/10 | [one-line summary] |
✅ Strengths [Synthesized list of what was done well, with specific examples] 1. ** [Strength 1] ** - Source: [which judge(s) noted this] - Evidence: [specific example]
⚠️ Issues & Gaps
Critical Issues [Issues that need immediate attention] - ** [Issue 1] ** - Identified by: [judge name] - Location: [file:line if applicable] - Impact: [explanation] - Recommendation: [what to do]
High Priority [Important but not blocking]
Medium Priority [Nice to have improvements]
Low Priority [Minor polish items]
- 🎯 Requirements Alignment
- [Detailed breakdown from Requirements Validator]
- **
- Requirements Met
- **
-
- X/Y
- **
- Coverage
- **
- Z% [Specific requirements table with status]
- 🏗️ Solution Architecture
- [Key insights from Solution Architect]
- **
- Chosen Approach
- **
-
- [brief description]
- **
- Alternative Approaches Considered
- **
- :
- 1.
- [Alternative 1] - [Why chosen approach is better/worse]
- 2.
- [Alternative 2] - [Why chosen approach is better/worse]
- **
- Recommendation
- **
- [Stick with current / Consider alternative X because...]
🔨 Refactoring Recommendations [Prioritized list from Code Quality Reviewer]
High Priority Refactorings 1. ** [Refactoring Name] ** - Benefit: [explanation] - Effort: [estimate] - Before/After: [code examples]
Medium Priority Refactorings [similar structure]
🤝 Areas of Consensus [List where all judges agreed] - [Agreement 1] - [Agreement 2]
💬 Areas of Debate [If applicable - where judges disagreed] ** Debate 1: [Topic] ** - Requirements Validator position: [summary] - Solution Architect position: [summary] - Resolution: [consensus reached or "reasonable disagreement"]
📋 Action Items (Prioritized) Based on the critique, here are recommended next steps: ** Must Do ** : - [ ] [ Critical action 1 ] - [ ] [ Critical action 2 ] ** Should Do ** : - [ ] [ High priority action 1 ] - [ ] [ High priority action 2 ] ** Could Do ** : - [ ] [ Medium priority action 1 ] - [ ] [ Nice to have action 2 ]
🎓 Learning Opportunities [Lessons that could improve future work] - [Learning 1] - [Learning 2]
- 📝 Conclusion
- [Final assessment paragraph summarizing whether the work meets quality standards and key takeaways]
- **
- Verdict
- **
- ✅ Ready to ship | ⚠️ Needs improvements before shipping | ❌ Requires significant rework
- *
- Generated using Multi-Agent Debate + LLM-as-a-Judge pattern
- *
- *
- Review Date: [timestamp]
- *
- Important Guidelines
- Be Objective
-
- Base assessments on evidence, not preferences
- Be Specific
-
- Always cite file locations, line numbers, and code examples
- Be Constructive
-
- Frame criticism as opportunities for improvement
- Be Balanced
-
- Acknowledge both strengths and weaknesses
- Be Actionable
-
- Provide concrete recommendations with examples
- Consider Context
-
- Account for project constraints, team size, timelines
- Avoid Bias
- Don't favor certain patterns/styles without justification Usage Examples
Review recent work from conversation
/critique
Review specific files
/critique src/feature.ts src/feature.test.ts
Review with specific focus
/critique --focus = security
Review a git commit
/critique HEAD~1 .. HEAD Notes This is a report-only command - it does not make changes The review may take 2-5 minutes due to multi-agent coordination Scores are relative to professional development standards Disagreements between judges are valuable insights, not failures Use findings to inform future development decisions