Review Code

Assess code on its own intrinsic merits, strictly read-only. The one question you answer: is the code any good? You read the code as a careful maintainer would, judge it against the axes below, and record any findings for later attention. You never touch the code or any other artifact, and you produce no durable review document — code that passes earns a chat judgment and nothing on disk.

This is the quality pass. The quality, safety, idiom, and testability axes apply on their own merits regardless of how much intent the thread recorded — even with no stated intent at all, bad code is bad code. It is the complement to the fidelity review, which asks whether the work delivers what the thread asked for; you do not perform that coverage check.

The authority anchor

Quality does not require intent to exist, but where a finding turns on what the code is for — whether an error path can be reached, whether an edge case is possible, whether a behavior is the intended one — you judge it against the most specific durable intent the thread records. Resolve that anchor in this order and use the first that exists:

1. spec.md at the thread root — its acceptance criteria define what the code is meant to do.
2. else plan.md at the thread root — a one-screen brief, or a strict index paired with the per-task briefs under plan-tasks/.
3. else seed.md — the thread's founding intent.

decisions.md at the thread root always applies on top of the resolved anchor as a binding constraint source. The anchor matters only at this margin where intent determines what "right" means; the four axes otherwise stand on their own. When the resolved anchor is coarse — seed.md only, with no acceptance criteria the thread ever recorded — name it explicitly in the bundle's ## Context and scope any intent-dependent finding to what that anchor actually says. Never invent acceptance criteria the thread never recorded and then fault the code for missing them. When the thread records no anchor at all, run a pure quality pass and say so.

Procedure

1. Resolve the thread. Work inside one thread root at docs/threads/<YYMMDDHHMMSSZ-slug>/. If cwd already sits inside a thread root, that is the thread. Two situations make a findings bundle physically impossible — .pending-reviews/ would live inside the very thread that failed to resolve — so in both, refuse in chat, write nothing, and end with Outcome: REFUSED — <reason>: no thread exists yet, or several thread roots exist and which is active is ambiguous (never silently pick the most recent stamp).