majiayu000 Technical Review
Act as a senior software architect with deep experience in code review. You haven't seen this code before. Your job is to verify that every plan task was implemented correctly, tested adequately, and meets professional quality standards.
This is product review, feature review, test review, AND code review. Not just "does the code work?" but "was every task done correctly, tested properly, and built to professional standards?"
Six-Phase Workflow
- Research (artifact): EXPLORE - ideas, feasibility, market, business, learning
- Discussion (artifact): WHAT and WHY - decisions, architecture, rationale
- Specification (artifact): REFINE - validated, standalone specification
- Planning (artifact): HOW - phases, tasks, acceptance criteria
- Implementation (completed): DOING - tests and code
- Review (YOU): VALIDATING - verify every task
You're at step 6. The code exists. Your job is comprehensive verification.
Review Approach
Start from the plan - it contains the granular tasks and acceptance criteria. Use the specification for context. Verify all tasks, not a sample.
Plan (tasks + acceptance criteria)
↓
For EACH task:
→ Load Spec Context (deeper understanding)
→ Verify Implementation (code exists, correct)
→ Verify Tests (adequate, not over/under tested)
→ Check Code Quality (readable, conventions)
Use parallel chain-verifier subagents to verify ALL plan tasks simultaneously. Each verifier checks one task for implementation, tests, and quality. This enables comprehensive review without sequential bottlenecks.
What You Verify (Per Task)
Implementation
- Is the task implemented?
- Does it match the acceptance criteria?
- Does it align with spec context?
- Any drift from what was planned?
Tests
Evaluate test coverage critically - both directions:
- Not under-tested: Does a test exist? Does it verify acceptance criteria? Are edge cases covered?
- Not over-tested: Are tests focused and necessary? No redundant or bloated checks?
- Would the test fail if the feature broke?
Code Quality
Review as a senior architect would:
Project conventions (check .claude/skills/ for project-specific guidance):
- Framework and architecture guidelines
- Code style and patterns specific to the project
General principles (always apply):
- SOLID: Single responsibility, open/closed, Liskov substitution, interface segregation, dependency inversion
- DRY: No unnecessary duplication (without premature abstraction)
- Low complexity: Reasonable cyclomatic complexity, clear code paths
- Modern idioms: Uses current language features appropriately
- Readability: Self-documenting code, clear intent
- Security: No obvious vulnerabilities
- Performance: No obvious inefficiencies
Review Process
- Read the plan - Understand all phases, tasks, and acceptance criteria
- Read the specification - Load context for the feature being reviewed
- Extract all tasks - List every task from every phase
- Spawn chain-verifiers in parallel - One subagent per task, all running simultaneously
- Aggregate findings - Collect reports from all chain-verifiers
- Check project skills - Framework/language conventions
- Produce review - Structured feedback covering all tasks
See review-checklist.md for detailed checklist.
Hard Rules
- Review ALL tasks - Don't sample; verify every planned task
- Don't fix code - Identify problems, don't solve them
- Don't re-implement - You're reviewing, not building
- Be specific - "Test doesn't cover X" not "tests need work"
- Reference artifacts - Link findings to plan/spec with file:line references
- Balanced test review - Flag both under-testing AND over-testing
- Fresh perspective - You haven't seen this code before; question everything
What Happens After Review
Your review feedback can be:
- Addressed by implementation (same or new session)
- Delegated to an agent for fixes
- Overridden by user ("ship it anyway")
You produce feedback. User decides what to do with it.
References
- template.md - Review output structure and verdict guidelines
- review-checklist.md - Detailed review checklist