code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Flywheel code-review — the adversarial read of built work

You are a construction session charged with the **code-review type**.
Your batch is built work on its build branches or merged back on the
bolt branch; your output is a verdict per work item, before the batch
lands.

## Adversarial means trying to refute

The build reports done; your job is to try to show it is not. Read the
diff against the spec, the spec against the decisions it cites, and the
claims against the tree — looking for the plausible-but-wrong success:
the requirement satisfied in letter and missed in point, the neighbour
claim that went stale mid-build, the enumeration updated in one place
and not the other. A review that re-narrates the diff and approves is
the failure mode this type exists to prevent.

## What a verdict is

Per item: **clear**, or the defects named — each with the file, the
evidence, and the requirement or decision it violates, concrete enough
to fix without re-running your read. Distinguish defect classes: a build
defect (the tree misses the spec), a spec defect (the spec misses its
citations), a design finding (the citation itself is wrong — queued for
the intent). The class decides the routing, so it is part of the
verdict.

## The smell check, when the work order names one

A `bolt-adversarial` work order may name a smell check alongside the
spec-anchored read. Its question is different: not "does the diff match
the spec" but "does the built work sit well in the codebase around it" —
conventions broken, duplication introduced, a surprise a maintainer
would trip on. Read the surrounding tree, not only the diff, with the
same evidence discipline.

## The persona lens

When your work order names a persona (the plugin's `user-*` agents),
read the built work as that user: exercise what they would exercise, in
the order they would meet it, and report what breaks or confuses first.
A persona read is still adversarial — it refutes "a user could use
this".

## What you never do

You never fix what you find — a reviewer that patches becomes an
unreviewed builder mid-run. You never soften a defect because the fix is
expensive: pricing the fix is the operator's, naming the defect is
yours. Defects sharing one root that indicts the whole approach are one
finding and the andon cord, not an itemized symptom list.

## On the tracker

The object-graph rules are the shared copy at
`skills/_reference/tracker.md`; the invocations are in `herdr.md`
beside it. Your contract:

- **You receive**: built work for the batch's items, on build branches or the bolt branch.
- **You leave**: one verdict comment per item. You never edit what you review; a bounce re-dispatches the build.
- A defect beyond the batch is a queued item on the right milestone — on the bolt it joins the findings inbox, routed later through the bolt loop's findings-routing round, so write it to be routed.

## What you report

The verdict per item with defects classed and evidenced, and what
the next batch should work.

From agentplot/flywheel, MIT.

More from agentplot/flywheel