Entry/Exit
- Entry: Code that has passed Spec Compliance review (functionally complete)
- Exit: Code quality review report (pass/fail + five-axis scoring + improvement suggestions)
- Points to: Pass → ship phase; Fail → return to build to fix quality issues
- Preloading: CANON.md, verify-team-code-review-standards
- Output path:
docs/features/YYYYMMDD-<name>/04-review.md(quality review portion) → ship-workflow-ship (on pass) or build-workflow-execute (on fail, return to fix quality issues)
When Not to Use
- Code has not yet passed Spec Compliance review (do not enter quality review when functionality is incomplete)
- Non-software artifacts (document/article/deck/visual use the corresponding content-review or visual-review)
Iron Law
Core Responsibilities
Assessalready functionally completecode's implementation quality. Care about: logical correctness, readability, architectural soundness, security measures, performance. Do not care about: spec requirement coverage (Spec Compliance responsibility), functional completeness (Spec Compliance responsibility), scope creep (Spec Compliance responsibility).
Review Process
Use the verify-team-code-review-standards skill to perform the five-axis review.
Step 1: Confirm Prerequisites
Confirm the code has passed Spec Compliance. Accept the following evidence: results just completed in the current /review , the Stage 1 block in04-review.md , or a PASS from an externally dispatched auditor. Do not require that 04-review.md already exists (it is usually the final artifact after the two stages are merged).
If there is no evidence or it does not pass, stop immediately and tell the user to complete Spec Compliance first.
Step 2: Load Review Standards
Load verify-team-code-review-standardsto obtain the five-axis standards: Correctness / Readability / Architecture / Security / Performance.
Step 3: Perform the Five-Axis Review
Check item by item according to verify-team-code-review-standards . For detailed check items see rubric.md. Requirements:
- Each axis must have a conclusion and evidence citations
- Blocking / Important / Suggestion must be graded
- Security and correctness issues take priority over readability preferences
- Passing tests cannot be treated as passing code quality
Step 4: Generate Report + Verdict
Summarize the five-axis review results. For the full report template see report-template.md。
Pass: all five axes covered + no Blocking + Important ≤2 and with a fix plan. Fail: has Blocking or Important >2 with no fix plan → return to build to fix. Gray areas: code style follows the project's existing style; performance only focuses on obvious issues (N+1, unbounded loops); architecture only focuses on the soundness of the current change, not requiring refactoring the entire project.
Verification Evidence
The output or record must include: input/source, actions performed, verification results, blocking/fallback.
Verification Failure Handling
| Failure Scenario | Handling Method |
|---|---|
| Blocking security issues (XSS/injection/hardcoded secrets) | Immediately fail, return to build to fix |
| Blocking correctness issues (unhandled errors/type unsafety) | Fail, provide file name + line number + issue description |
| Important >2 and no remediation plan | Fail, require a remediation plan to be formulated |
| Not all five axes covered | Review incomplete, complete it before making a determination |
| Spec Compliance not passed but already entered quality review | Stop immediately |
| Issue found falls under Spec Compliance responsibility | Hand off to Spec Compliance Auditor |
Common excuses
| Excuse | Reality | Consequence |
|---|---|---|
| "This security issue is unlikely to be exploited" | There is no "unlikely" for security issues, only "already exploited" and "not yet exploited". | Exploited at the worst possible moment. Unfixed = potential security incident |
| "The N+1 query data volume is not large" | Data volume will grow. 10 rows today, 1000 rows tomorrow. | The cost of fixing once performance issues become obvious is far higher than now |
| "This function is complex, but I can understand it" | Code is for the whole team to read. | Details are forgotten during maintenance 6 months later; complex code = hard to maintain = easy to introduce bugs |
| "Architecture issues only affect this one feature" | Architecture issues are contagious. If one module breaks the rules, others will follow. | Ultimately leads to architectural chaos |
Violating the letter of the rule is violating its spirit. There is no gray area.
Boundary with Spec Compliance
What the spec explicitly requires = Spec Compliance; what the spec does not mention but should have = Code Quality. Example: "the function does not handle null" → required by spec = Spec Compliance; not mentioned by spec = Code Quality (Correctness axis).
Red flags
- Obvious security vulnerabilities in the code (XSS, SQL injection, command injection, hardcoded secrets)
- Obvious correctness issues in the code (unhandled errors, unvalidated boundaries, type unsafety)
- Obvious performance issues in the code (N+1 queries, unbounded loops, resource leaks)
- The reviewer skips an axis, claiming it is "not applicable"
- The reviewer performs quality review while the code has not passed Spec Compliance
- The reviewer marks "missing functionality" as a quality issue
Verification checklist
- Confirmed the code has passed Spec Compliance review
- Executed the five-axis review (Correctness/Readability/Architecture/Security/Performance)
- Marked all Blocking issues
- Marked all Important issues
- Provided clear remediation suggestions
- Generated the quality review report
- Determined pass/fail
Review completion verification checklist
- A score (1-5) has been given for each of the five axes
- Each deduction item has a specific file name + line number + issue description
- All findings have been classified as Blocking / Important / Suggestion
- Blocking issues have clear remediation suggestions
- The review scope corresponds one-to-one with the spec requirements checklist
- Security-related findings have been handed off to verify-quality-security (if any)
Output template
See the full report template at verify-quality-code-quality/report-template.md。
### Code Quality Report — <feature-name>
**五轴评分**:
| 轴 | 评分 (1-5) | 关键发现 |
|----|-----------|---------|
| Correctness | [N] | [具体问题] |
| Readability | [N] | [具体问题] |
| Architecture | [N] | [具体问题] |
| Security | [N] | [具体问题] |
| Performance | [N] | [具体问题] |
**Findings Summary**:
| # | Severity | Category | Description | File:Line | Status |
|---|----------|----------|-------------|-----------|--------|
| 1 | Blocking | [轴] | [问题] | [位置] | Open |
**Verdict**: APPROVED / APPROVED_WITH_CONCERNS / REJECTED