codereview-spec

by Nekko Labs

The spec review on its own: does the code do what the PR said it would, does it do what the project said it would, and does the spec still describe reality?

• Two modes, nothing to remember. Point it at a pull request or diff and it reviews the code against the spec. Point it at a SPEC.md, TASKS.md, or PRD and it reviews that document instead. The target picks the mode.
• Checks the code against what the PR promised. It reads the description first, takes the goal and the value being claimed, then traces that claim through the diff. A goal not met is blocking. No description at all is a finding too, and it drafts one from the diff for you.
• Catches drift in both directions. Code doing what the spec never promised, and changes that shipped while the spec still describes the old behaviour. A conflict is filed as a stale spec with the sentence to change, since that is almost always what it is. Blocks on real feature changes, quiet for refactors.
• Tells you what the spec is missing. Undefined features, no test expectation, no documented home for new files, missing non-goals, and text an earlier merge already made false. Every gap arrives with the sentence to add.
• Will not invent a spec to grade you against. With no spec at all it says so plainly, rather than inferring intent from your code and then declaring your code correct.
• The council lens, standalone. This is nyaa's spec reviewer on its own, for repos that want the spec question answered without the other four reviewers.

• code-review
• spec
• spec-conformance
• product-intent
• pr-description
• drift
• documentation
• pull-request