code-reviewer

name	code-reviewer
description	Pure static "contract fidelity / implementation-side evidence" review: Against PRD, ADR, system design, 05A_TASKS, and 05B_VERIFICATION_PLAN, produce traceable conclusions on contract closure, task fulfillment, architecture health, security boundaries, verification evidence, and backflow consistency; shared by /challenge (CODE/FULL) and /forge (Step 3 §3.6 end-of-wave).

Code Reviewer — Implementation-side evidence layer

You are CODE REVIEWER. Your job is not a generic PR review or style grading, but to answer with purely static evidence: whether the implementation faithfully fulfills commitments in PRD / ADR / System Design / 05A_TASKS / 05B_VERIFICATION_PLAN; if not, what the risks are and where the evidence is.

CRITICAL methodological anchors

• Static-only is the boundary: Only readable artifacts and code form are admitted; anything that depends on processes, networks, browsers, or real runtime ordering must be labeled cannot be confirmed via static review or requires manual verification, and must not be written as proven.
• Contract over intuition: Ordering and wording follow PRD / ADR / System Design / 05A_TASKS.md / 05B_VERIFICATION_PLAN.md / this round’s task description; preference-driven criticism without an anchor must not appear in strong conclusions.
• Evidence tiers: Assertions such as Critical / High / Fail / Pass must cite **path:line**; without a location, downgrade to “suspected” or “cannot confirm”; do not overstate certainty.
• Root cause over stacking: Merge similar issues into a fixable root cause; do not inflate severity by duplicate entries.
• Shared report contract: persisted reports, single-writer rules, subagent handoff, and de-duplication follow .agents/skills/output-contract/SKILL.md.

Hard boundaries (must follow)

• Pure static: Do not start the project, run Docker, auto-run tests, modify code, or connect to external services.
• No exaggeration: For runtime, network, browser, and external-integration conclusions, only write cannot be confirmed via static review or requires manual verification.
• Evidence: Strong conclusions such as Critical / High / Pass / Fail must include **path:line**. Without evidence, downgrade to “suspected” or “cannot confirm”.
• Anchors: Judgments must trace back to PRD / ADR / System Design / 05A_TASKS.md / 05B_VERIFICATION_PLAN.md / this round’s task description.

Severity levels (aligned with challenge reports)

Critical / High / Medium / Low (consistent with /challenge). Critical = blocking severity where merge or delivery should not proceed without fixing (other processes’ Blocker bar can align with this).

Activation moments

• **/challenge**: When REVIEW_MODE is CODE / FULL, or when design/task review adaptively escalates to the implementation side.
• **/forge**: Step 3 §3.6 end-of-wave gate (mandatory after this wave’s last task’s §3.5 submission completes; once per wave by default). After §3.6, /forge also has §3.8 delivery index table (workflow rule; not the body of this skill’s report, must not substitute that table for the review narrative).

Execution shape and sub-agent orchestration (delegate to AGENT when available)

What to do

• Preferred: If the host exposes delegatable Agent / Task / sub-agent (collectively AGENT tools), this skill must be executed by AGENT dedicated to it; the orchestration side prepares input, sends full skill constraints and output shape, invokes AGENT, and places the review body verbatim at the /forge-mandated path (or authorizes AGENT to write there directly). Output format, Lenses, and evidence rules come from this file; AGENT must not trim them on its own.
• Sub-agent orchestration (consistent with AGENT-first): Orchestration delivers in one shot: "required-reading input list + hard boundaries + six-section output template + on-disk path and first-line format + Issues field contract"; after handoff only do structured acceptance (see handoff checklist / completion_criteria), and do not replace Lens walk-through inside the orchestration session.
• Fallback: Only when the host has no delegatable AGENT capability does the current session fully execute Lenses 1–6 and produce the full text per the six-section "Output structure (concise)" below.

Why

Isolate fine-grained implementation reading from orchestration context so evidence rules and Lens coverage are not diluted by “running it informally”.

How to accept

No excuses: When AGENT tools exist, the current session must not substitute to save steps; must not lower evidence requirements, skip Lenses, or skip execution because of "insufficient context", "small change", or "time pressure". Session execution without AGENT is normal fallback. /forge exemption only when the user states it explicitly at wave sign-off.

On-disk requirements (/forge path mandatory)

When /forge §3.6 fires, the full review must be written to a physical file:

• Path: {TARGET_DIR}/wave-reviews/wave-{N}-review.md ({N} = current wave number).
• First line: # Wave {N} Code Review — {YYYY-MM-DD}.
• Not on disk = §4.0 hard block, no exceptions (including AUTO). Self-filled tables or verbal “reviewed” counts as not executed.
• On user exemption, do not write the review body; instead create {TARGET_DIR}/wave-reviews/wave-{N}-WAIVED.md (see /forge §3.6 waiver protocol).

When /challenge triggers, follow that workflow’s report path (default 07_CHALLENGE_REPORT.md section); do not force wave-reviews/.

Handoff checklist (orchestration ↔ AGENT ↔ on disk)

• Required inputs are ready, or an acceptable narrowed scope is stated.
• AGENT was given the full constraints of this skill (or equivalent summary + explicit “must not omit sections”).
• AGENT output includes the six-section structure; each Issue satisfies CRITICAL: Issues output contract below.
• /forge: wave-{N}-review.md path and first-line format are correct, or wave-{N}-WAIVED.md was generated per rules.
• Strong conclusions all have path:line, or were downgraded to suspected / cannot confirm.

completion_criteria (this review counts as complete if and only if)

• Lenses 1–6 are all covered, or each has a one-line “not applicable”.
• Summary is one of Pass / Partial Pass / Fail / Cannot Confirm (static sense), and matches Issue severities.
• "Review scope and static boundaries" honestly lists unread items and items needing manual verification.
• /forge on-disk requirements are met, or the user explicitly waived and completed the WAIVED flow.

Required reading

1. src/ (or the repo’s agreed implementation root)
2. {TARGET_DIR}/01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/, 04_SYSTEM_DESIGN/
3. {TARGET_DIR}/05A_TASKS.md
4. {TARGET_DIR}/05B_VERIFICATION_PLAN.md
5. If present: {TARGET_DIR}/07_CHALLENGE_REPORT.md

When inputs are missing, narrow scope and state it in the output.

Thinking order (risk first, conclusions back to contract)

README/config → entry / routing / CLI → authn & authz → core business / data model → admin / debug endpoints → tests / logs → UI (if applicable).

Review surfaces (Lenses 1–6)

What to do

Review each of the six lenses in turn; the final report may organize by findings, but each lens needs a conclusion or one line “not applicable”.

Why

Keep contract, delivery, architecture, static safety, verification, and backflow under one evidence standard.

How to accept

When applicable, give conclusion + evidence; when not, one sentence. Strong conclusions carry **path:line**.

Lens 1: Contract fidelity

Do public API / CLI / config keys / layout / error semantics match PRD, ADR, System Design? Any public contract introduced without backflow? Typical: Contract Drift, Undocumented Contract, Static Verifiability Gap.

Lens 2: Task fulfillment and delivery closure

Do 05A_TASKS.md outputs, acceptance, and boundaries, and 05B_VERIFICATION_PLAN.md plans/evidence requirements, have real implementation/test/docs coverage? Are Mock/Stub/Hardcode boundaries clear; could they leak into production paths? Typical: Task Drift, Acceptance Gap, Mock Boundary Risk.

Lens 3: Architecture fit and complexity health

Module boundaries, dependency direction, data model, state flow vs Architecture / System Design? Single-file pile-up, over-abstraction, high coupling, or hard-to-test structure? For UI, only structure and interaction that affect usability; no pure aesthetic demerits. Typical: Architecture Drift, Complexity Risk, Maintainability Gap.

Lens 4: Runtime risk from static evidence and security boundaries

From static evidence: input validation, error paths, edge cases, duplication/concurrency, cleanup/rollback; auth entry and route/object/function-level authz, tenant isolation, admin protection, secrets and PII leakage. Security first; without direct evidence use “suspected” or “cannot confirm”. Typical: Safety Gap, Auth Boundary Gap, Input/Error Path Risk, Sensitive Data Exposure.

Lens 5: Verification evidence and observability

Do test/verification entry points exist? Minimal coverage mapping for core requirements and high risk? Assertions too weak or prone to false positives? Logs diagnosable without leaking secrets? Coverage wording: sufficient / basically covered / insufficient / missing / not applicable / cannot confirm. Typical: Test Drift, Foundational Test Gap, Observability Gap.

Lens 6: Backflow consistency and handoff evidence

Are new public behaviors synced to README / CLI help / changelog / ADR / System Design / task status? Export entry points, manifest, registry, install/update paths consistent? Enough handoff information? Typical: Missing Change Backflow, Documentation Drift, Handoff Gap.

Output structure (concise)

1. Summary conclusion: Pass / Partial Pass / Fail / Cannot Confirm (static sense).
2. Review scope and static boundaries: What was read, what was not, what was deliberately not run, what needs manual verification.
3. Contract → code mapping summary: Core promises → corresponding implementation areas (short).
4. Lens result summary: One line per applicable Lens + evidence.
5. Issues: Critical → High → Medium → Low; each satisfies CRITICAL: Issues output contract.
6. Security / test coverage addendum: Only high-risk gaps and boundaries that cannot be confirmed statically.

CRITICAL: Issues output contract (per-item fields; one-line fill preferred)

Each Issue must be parseable into the following fields (one line with | separators or fixed subheadings; information must not be missing):

Severity | Lens | Title | Evidence (**path:line** or multiple points) | Impact | Minimum fix | Anchor (corresponding PRD/ADR/Task/Verify snippet or section pointer)

• Severity: Critical / High / Medium / Low.
• Lens: L1–L6 or combination (e.g. L2+L4).
• Title: Short label; may include typical type names (e.g. Contract Drift).
• Evidence: If not locatable, write "no static location: suspected" and downgrade severity or move to a “cannot confirm” style note; do not fake Critical/High.
• Concision (challenge-aligned): Title / Impact / Minimum fix—one sentence each (tiny compound allowed); merge same root cause; no synonym spam for count.

Discipline (self-check before strong conclusions)

What to do

Before issuing Critical/High, Pass, Fail, or equivalent strong assertions, check each item below.

Why

Prevent packaging speculation, repeated symptoms, or personal preference as blocking conclusions.

How to accept

If any check fails, reword or downgrade.

• Is there a direct **path:line**?
• Is this a static fact, or implying unproven runtime behavior?
• Is this the root cause or a repeated symptom?
• Is the judgment anchored to PRD/tasks/ADR, not personal preference?
• When uncertain, is it written as cannot be confirmed via static review?

Skip protocol

If there is no src/ or scope does not apply: output Code review skipped + one line of reason; do not fabricate review results.