A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/code-review, MIT. 60 of 90 source lines differ (67%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11, series-s7-roster-2026-09-11, replay-s7-delivery-review-2026-09-11, ready-copies-2026-09-12, ready-review-role-2026-09-12, ready-review-bound-2026-09-12, ready-review-convention-2026-09-12, ready-review-installation-2026-09-12, vocabulary-owner-2026-09-12.
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: code-review
name: "delivery-review"
description: "Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\"."
description: "Review an explicit committed range for implemented work or a ticket already in reviewing, along two axes: Standards (the repo's documented standards and installed guideline skills) and Spec (does the code match what the spec asked?). Use for 'review the branch', 'review since X', or a PR."
---
---
scopechangedfold-2026-09-11
one opening paragraph in the skill's voice: reviews committed work (a ticket at implemented or a user-named range read-only); fires on 'review the branch', 'review since X', a PR and the handoff from implement; review-lens supplies finding discipline, ponytail-review the over-engineering pass, verify-this the proof; never implements fixes, never reviews uncommitted work, never extends a recorded range to a later HEAD
Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
This skill reviews committed work: a ticket at implemented with its recorded range and pinned implementation account, or a range the user names for a read-only report. It fires on "review the branch", "review since X", a PR, and the handoff from implement. Finding discipline and severity come from review-lens, which both child reviews are briefed to read; a pass for over-engineering is ponytail-review's; the proof of acceptance is verify-this's. This skill never implements the fixes it finds, never reviews uncommitted work, and never extends a recorded range to a later HEAD.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Two-axis review of a committed range: the ticket's recorded `base_commit..result_commit`, or, for a read-only request, the diff between `HEAD` and a fixed point the user supplies:
- **Standards**: does the code conform to this repo's documented coding standards?
- **Standards**: does the code conform to this repo's documented coding standards?
- **Spec**: does the code faithfully implement the originating issue / spec?
- **Spec**: does the code faithfully implement the originating issue / spec?
harnesschangedready-copies-2026-09-12
each review sub-agent starts fresh with only its brief: on Codex it is spawned without the parent's turns (never fork_turns: all), because a fork of the implementer's conversation is not the independent context the method asks for (the Hono replay's judge)
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings. Each sub-agent starts fresh with only its brief: on Codex, spawn it without the parent's turns (never `fork_turns: all`); a fork of the implementer's conversation is not an independent context.
dependencychangedbaseline-copies-2026-09-11
Green Line writes no docs/agents/issue-tracker.md, so the body's opening nudge sends the reviewer to configure a file workspace-setup never creates.
The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/setup-matt-pocock-skills`.
## Process
## Process
### 1. Pin the fixed point
### 1. Pin the fixed point
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
For a ticket, the fixed point is its recorded range: `base_commit` and `result_commit` from the ticket at implemented, both resolved to exact commits. For a read-only request without a ticket, whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
the independent context is defined by its mechanism: a spawned agent started fresh that inherits none of the implementer's conversation, never a fork of the implementer's turns (Codex fork_turns), so the durable review is independent by construction on both harnesses
Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
Taking a ticket for a durable review is a separate contribution in an independent context, one that inherits none of the implementer's conversation (a spawned agent started fresh, never a fork of the implementer's turns): read `.greenline/WORK.md` and `.greenline/ledger/README.md`, write the draft `.greenline/work/reviews/REV-NNN.md` naming the ticket, its `implementation_account` and this `range`, open the review-role account whose `reviews` pins the implementation account bytes examined at their accounting commit, then advance the ticket to reviewing. A read-only request produces the report without repository edits.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
Capture the diff command once: `git diff <base-commit> <result-commit>` for a recorded range, or `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base) for a user-supplied fixed point. Also note the list of commits via `git log <base-commit>..<result-commit> --oneline`. A later HEAD does not extend a recorded range, and the merge-base does not replace the recorded base.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Before going further, confirm both ends resolve (`git rev-parse <base-commit>`, `git rev-parse <result-commit>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
### 2. Identify the spec source
### 2. Identify the spec source
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Look for the originating spec, in this order:
The originating spec is the one the ticket's `consumes` pins: read the ticket and its consumed spec at that revision where one exists, and the consumed decisions when their rationale matters. For a compact ticket with no separate spec, its intent, scope and acceptance are the fidelity contract for the Spec axis. For a read-only request without a ticket, the spec is the path the user passed as an argument.
dependencychangedbaseline-copies-2026-09-11
Step 2's search order routes through an issue tracker Green Line does not keep and spec directories it does not use; the ticket's consumes chain is the only spec source here.
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.
2. A path the user passed as an argument.
3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
### 3. Identify the standards sources
### 3. Identify the standards sources
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`, together with the scoped repository decisions in `.greenline/DECISIONS.md` and the initiative's `decisions.md`, the actual configuration, the installed guideline skills whose methods apply, and, when guidance is configured, the language and shared guidance retrieved under this review's own request handle by the request loop in AGENTS.md. Derive the applicable obligations from the task, the diff and those sources, independently of the implementer's selections; an implementer's selected list, or a repository path to an absent guidance file, is not a source. A source's prestige or location gives it no authority.
On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below: a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below: a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
15 unchanged lines
- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
- **The repo overrides.** A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation. Like any standard here, skip anything tooling already enforces.
- **Always a judgement call.** Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation. Like any standard here, skip anything tooling already enforces.
Each smell reads *what it is* → *how to fix*; match it against the diff:
Each smell reads *what it is* → *how to fix*; match it against the diff:
- **Mysterious Name**: a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
- **Mysterious Name**: a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
- **Duplicated Code**: the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
- **Duplicated Code**: the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
- **Feature Envy**: a method that reaches into another object's data more than its own. → move the method onto the data it envies.
- **Feature Envy**: a method that reaches into another object's data more than its own. → move the method onto the data it envies.
- **Data Clumps**: the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
- **Data Clumps**: the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
- **Primitive Obsession**: a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
- **Primitive Obsession**: a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
- **Repeated Switches**: the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.
- **Repeated Switches**: the same `switch`/`if`-cascade on the same type recurs across the change. → replace with polymorphism, or one map both sites share.
- **Shotgun Surgery**: one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
- **Shotgun Surgery**: one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
- **Divergent Change**: one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
- **Divergent Change**: one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
- **Speculative Generality**: abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
- **Speculative Generality**: abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
- **Message Chains**: long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
- **Message Chains**: long `a.b().c().d()` navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
- **Middle Man**: a class or function that mostly just delegates onward. → cut it, call the real target direct.
- **Middle Man**: a class or function that mostly just delegates onward. → cut it, call the real target direct.
- **Refused Bequest**: a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
- **Refused Bequest**: a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
dependencychangedfold-2026-09-11
review-lens and its REGISTER.md are the roster's finding and severity discipline: both axes carry them, both briefs say to read them, refute each candidate and give each survivor its severity rung with the rule or acceptance criterion it cites; the reviewers' rungs stand and the aggregator adds none
Beside the smell baseline, both axes carry review-lens and its REGISTER.md: the stance, the reflex check, the catalog and register that raise candidates, and the severity rungs that place what survives.
### 4. Spawn both sub-agents in parallel
### 4. Spawn both sub-agents in parallel
**Standards sub-agent prompt** should include:
**Standards sub-agent prompt** should include:
harnesschangedready-review-role-2026-09-12
the standards sub-agent's retrieval access is named as the command it runs (greenline guidance read --read-only --from-request <handle> --role review), so each read leaves its advisory stub under the dispatching request and the ledger accounts for the reviewer's reads; the brief's content is otherwise unchanged
- The full diff command and commit list.
- The full diff command and commit list, with the exact ticket and range identities.
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it).
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it), the scoped decisions, and the retrieval access it needs for its own guidance reads under this review's request handle (`greenline guidance read <ids> --read-only --from-request <handle> --role review`, so each read leaves its advisory stub under the dispatching request).
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule, or the decision, or the guidance unit and its revision); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
**Spec sub-agent prompt** should include:
**Spec sub-agent prompt** should include:
scopechangedready-review-installation-2026-09-12
the spec brief gains (f): a change to a stored representation that an existing installation cannot take is in scope, quoted by the statement that creates the representation and the one that changes it, so refuting it needs evidence rather than the word speculation; (a) to (e) and the word limit are unchanged
- The diff command and commit list.
- The diff command and commit list, with the exact ticket and range identities.
- The path or fetched contents of the spec.
- The ticket's intent, scope and acceptance, and the path or fetched contents of the consumed spec at its pinned revision.
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong; (d) a state or transition a recorded decision forbids that the diff can reach, whether or not the ticket's acceptance names it; (e) a convention the diff introduces that other code must now follow and that no recorded decision names; (f) a change to a stored representation that an existing installation cannot take. Quote the spec line, the ticket's acceptance line, or the decision, for each finding; for (e), the hunk that sets the convention and the decision home it is absent from; for (f), the statement that creates the representation and the one that changes it. Under 400 words."
scopechangedready-review-bound-2026-09-12
the bounded first pass moves into the sentence both sub-agent briefs carry (read review-lens, refute each candidate, rung each finding, and keep the pass bounded to the change's seams: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery), so the reviewer receives the bound rather than the aggregator alone; the briefs' other content is unchanged
If the spec is missing, skip the Spec sub-agent and note this in the final report.
Both briefs also say: read review-lens and its REGISTER.md, refute each candidate before filing it, give each surviving finding its severity rung with the rule or acceptance criterion it cites, and keep the pass bounded to the change's own seams and its acceptance: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery; a limit the pass did not probe is reported as a limit, not explored. Each reviewer returns its own ranked findings.
scopechangedready-review-bound-2026-09-12
the bounded first pass moves into the sentence both sub-agent briefs carry (read review-lens, refute each candidate, rung each finding, and keep the pass bounded to the change's seams: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery), so the reviewer receives the bound rather than the aggregator alone; the briefs' other content is unchanged
A ticket always supplies the Spec contract, so the spec is missing only on a read-only request with no path; then skip the Spec sub-agent and note this in the final report as a limit, never as a pass. A contract that is present but ambiguous is reported as the concrete limit it is, with the missing intent obtained from the ticket's owner.
### 5. Aggregate
### 5. Aggregate
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_).
Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned, below the frontmatter of `.greenline/work/reviews/REV-NNN.md` for a durable review, or in the reply for a read-only request. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_); the reviewers' severity rungs stand, and the aggregator adds none.
End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes: that's the reranking the separation exists to prevent.
End with a one-line summary: total findings per axis, and the worst issue _within each axis_ (if any). Don't pick a single winner across axes: that's the reranking the separation exists to prevent.
scopechangedvocabulary-owner-2026-09-12
the durable review's transitions are unchanged (a finding needing code returns the ticket; a correction gets a new result and a second review waits for the word; a clean review moves the ticket to verifying; a missing prior account is a reviewLimit) and one sentence bounds what a finding may ask: repository furniture (a test lane, a script, a convention) is proposed to the operator, never assigned as rework, whatever standard names it (carried from series-s7-roster-2026-09-11; the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12))
For a durable review, the record is the account of what it saw. A standards finding cites the applicable decision, the exact guidance unit and revision, or the repository rule. A finding that needs a code change returns the ticket to implementing and its request holder; this review does not implement the fix in the review context. A finding that would add repository furniture, a test lane, a script, a convention, is written as a proposal for the owner, not as rework, whatever standard names it. A correction receives a new result, and a second review of it waits for the owner's word. A future-ticket issue can be linked as a bounded trap note with its triggering condition. A clean, supported review sets the review account's `resultCommit` to the implementation commit at the end of `range`, completes the REV artifact, and moves the ticket to verifying, where verify-this proves its acceptance. A missing prior implementation account is an explicit `reviewLimit`, never invented evidence. Respect read-only scope and any other stop boundary, and return the findings or the supported result to the same request holder so the authorized work continues.
## Why two axes
## Why two axes
A change can pass one axis and fail the other:
A change can pass one axis and fail the other:
2 unchanged lines
- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
Reporting them separately stops one axis from masking the other.
Reporting them separately stops one axis from masking the other.
lifecyclechangedfold-2026-09-11
the durable review's transitions: a finding needing code returns the ticket to implementing and its request owner without the reviewer fixing it, a correction gets a new result and a second review waits for the operator's word, a clean supported review sets the review account's resultCommit to the end of range, completes the REV artifact and moves the ticket to verifying for verify-this; a missing prior account is a reviewLimit; the Handoff section names consumes, produces and next
## Handoff
Consumes: the ticket at implemented, its consumed spec (pinned revision), base_commit..result_commit, the pinned implementation account
Produces: .greenline/work/reviews/REV-NNN.md naming ticket, implementation_account and range; a review-role account; status reviewing then verifying on a clean review, or implementing when findings return the ticket
Next: verify-this proves the acceptance at verifying
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Code Review"
short_description: "Review a diff on standards and spec"
The timeline
Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.
2026-09-11baseline-copies-2026-09-11
the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it
SKILL.md
harnesschangedbaseline-copies-2026-09-11
greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag
name: code-review
name: "delivery-review"
description: "Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to \"review since X\"."
description: "Review an explicit committed range for implemented work or a ticket already in reviewing, along two axes: Standards (the repo's documented standards and installed guideline skills) and Spec (does the code match what the spec asked?). Use for 'review the branch', 'review since X', or a PR."
lifecyclechangedbaseline-copies-2026-09-11
greenline prelude, to fold: review committed work only, on the recorded base..result range; the missing-spec skip is replaced; review-lens and the severity rungs are briefed into both child reviews
**greenline prelude: review committed work only.** Read `.greenline/WORK.md` and `.greenline/ledger/README.md`. Resolve the exact ticket, committed result range, and pinned implementation account. Use an independent context. When taking implemented work for a durable review, create its draft review record with that ticket, account, and range before advancing the ticket to reviewing. A read-only review request produces the report without repository edits.
**Replace the body's fixed-point/HEAD procedure in step 1 with the recorded
range.** Resolve both ends of `<base-commit>..<result-commit>` to exact commits;
use `git diff <base-commit> <result-commit>` and
`git log <base-commit>..<result-commit> --oneline`. Pass those exact commands and
identities to both reviewers. A later HEAD does not extend the review, and the
body's three-dot merge-base command does not replace the recorded base. Refuse
an unresolved or empty range before dispatch.
**Replace step 2 and step 4's missing-spec skip rule.** Read the ticket and its
consumed spec where one exists. For a compact ticket, give the Spec reviewer
its intent, scope, and acceptance as the fidelity contract. Run both axes even
without a separate spec. If that contract itself is missing or ambiguous,
report the concrete limit and obtain the missing intent; never declare the
Spec axis passed or silently skip it. Read consumed decisions when their
rationale matters.
For the Standards axis, independently derive applicable obligations from the task, diff, scoped repository decisions, and actual configuration. Follow the request loop in AGENTS.md to retrieve relevant language and shared guidance under this review's request handle. Use the installed guideline skills whose methods apply. Give each independent reviewer the exact work and retrieval identities it needs; a repository path to an absent guidance file or an implementer's selected list is not sufficient context. Before dispatch, add to both sub-agent briefs: read review-lens and its REGISTER.md, refute candidates, and assign each surviving finding its severity rung with its applicable rule or acceptance criterion. Each reviewer returns its own ranked findings. Step 5 preserves those rankings and the separate axes; the aggregator does not add or rerank severity afterwards. A source's prestige or location gives it no automatic authority.
dependencychangedbaseline-copies-2026-09-11
Green Line writes no docs/agents/issue-tracker.md, so the body's opening nudge sends the reviewer to configure a file workspace-setup never creates.
The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/setup-matt-pocock-skills`.
dependencychangedbaseline-copies-2026-09-11
Step 2's search order routes through an issue tracker Green Line does not keep and spec directories it does not use; the ticket's consumes chain is the only spec source here.
Look for the originating spec, in this order:
Look for the originating spec at a path the user passed as an argument.
dependencychangedbaseline-copies-2026-09-11
Step 2's search order routes through an issue tracker Green Line does not keep and spec directories it does not use; the ticket's consumes chain is the only spec source here.
1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.
2. A path the user passed as an argument.
3. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
lifecyclechangedbaseline-copies-2026-09-11
greenline completion, to fold: the REV-NNN.md contract: exact ticket, implementation_account, committed range; findings return to implementing, a clean review moves the ticket to verifying; one bounded review round
## greenline completion: the review artifact
A durable review uses `.greenline/work/reviews/REV-NNN.md` under the common work contract. It names the exact ticket, `implementation_account`, and committed `range`, with any artifact inputs actually consumed. Findings and semantic verdicts stay in the review artifact; this review's separate ledger pins the implementation records it examined and its own source reads. A standards finding cites the applicable decision and exact guidance unit/revision or repository rule.
Keep the review as the account of what it saw. Findings requiring code changes return the ticket to implementing and its request owner; the independent reviewer does not implement those fixes in the review context. Corrections receive a new result; a second review of it waits for the operator's word. A future-ticket issue can be linked as a bounded trap note with its triggering condition.
A clean, supported review moves the ticket to verifying, where verify-this proves its acceptance. A missing prior execution account is an explicit review limit, never invented evidence. Respect read-only scope and other stop boundaries. Return the findings or supported result to the same request owner so authorized work can continue without a manual skill relay.
agents/openai.yaml
harnessremoved filebaseline-copies-2026-09-11
the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected
interface:
display_name: "Code Review"
short_description: "Review a diff on standards and spec"
2026-09-11pull-2026-09-11
pin advance to 3cca18b: upstream moved with no change under the vendored paths
2026-09-11fold-2026-09-11
the fold (ADR 0039, S3): the prelude and completion are gone; the recorded range, the REV artifact, the ticket's consumed spec, greenline's standards homes, the review-lens brief and the ticket transitions sit in the process steps where the reviewer reaches them, with the Handoff section the skills-handoff gate parses
SKILL.md
scopechangedfold-2026-09-11
one opening paragraph in the skill's voice: reviews committed work (a ticket at implemented or a user-named range read-only); fires on 'review the branch', 'review since X', a PR and the handoff from implement; review-lens supplies finding discipline, ponytail-review the over-engineering pass, verify-this the proof; never implements fixes, never reviews uncommitted work, never extends a recorded range to a later HEAD
Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
This skill reviews committed work: a ticket at implemented with its recorded range and pinned implementation account, or a range the user names for a read-only report. It fires on "review the branch", "review since X", a PR, and the handoff from implement. Finding discipline and severity come from review-lens, which both child reviews are briefed to read; a pass for over-engineering is ponytail-review's; the proof of acceptance is verify-this's. This skill never implements the fixes it finds, never reviews uncommitted work, and never extends a recorded range to a later HEAD.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Two-axis review of a committed range: the ticket's recorded `base_commit..result_commit`, or, for a read-only request, the diff between `HEAD` and a fixed point the user supplies:
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
For a ticket, the fixed point is its recorded range: `base_commit` and `result_commit` from the ticket at implemented, both resolved to exact commits. For a read-only request without a ticket, whatever the user said is the fixed point (a commit SHA, branch name, tag, `main`, `HEAD~5`, etc.). If they didn't specify one, ask for it.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
Taking a ticket for a durable review is a separate contribution in an independent context: read `.greenline/WORK.md` and `.greenline/ledger/README.md`, write the draft `.greenline/work/reviews/REV-NNN.md` naming the ticket, its `implementation_account` and this `range`, open the review-role account whose `reviews` pins the implementation account bytes examined at their accounting commit, then advance the ticket to reviewing. A read-only request produces the report without repository edits.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Before going further, confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
Capture the diff command once: `git diff <base-commit> <result-commit>` for a recorded range, or `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base) for a user-supplied fixed point. Also note the list of commits via `git log <base-commit>..<result-commit> --oneline`. A later HEAD does not extend a recorded range, and the merge-base does not replace the recorded base.
lifecyclechangedfold-2026-09-11
the fixed point for a ticket is its recorded base_commit..result_commit, both ends resolved exactly (two-dot diff and log, rev-parse of both ends); upstream's fixed-point-to-HEAD procedure stays for a read-only request without a ticket; taking a ticket writes the draft REV-NNN.md with ticket, implementation_account and range, opens the review-role account pinning the implementation account bytes, and advances the ticket to reviewing
Before going further, confirm both ends resolve (`git rev-parse <base-commit>`, `git rev-parse <result-commit>`) and the diff is non-empty. A bad ref or empty diff should fail here, not inside two parallel sub-agents.
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Look for the originating spec, in this order:
The originating spec is the one the ticket's `consumes` pins: read the ticket and its consumed spec at that revision where one exists, and the consumed decisions when their rationale matters. For a compact ticket with no separate spec, its intent, scope and acceptance are the fidelity contract for the Spec axis. For a read-only request without a ticket, the spec is the path the user passed as an argument.
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`, together with the scoped repository decisions in `.greenline/DECISIONS.md` and the initiative's `decisions.md`, the actual configuration, the installed guideline skills whose methods apply, and, when guidance is configured, the language and shared guidance retrieved under this review's own request handle by the request loop in AGENTS.md. Derive the applicable obligations from the task, the diff and those sources, independently of the implementer's selections; an implementer's selected list, or a repository path to an absent guidance file, is not a source. A source's prestige or location gives it no authority.
dependencychangedfold-2026-09-11
review-lens and its REGISTER.md are the roster's finding and severity discipline: both axes carry them, both briefs say to read them, refute each candidate and give each survivor its severity rung with the rule or acceptance criterion it cites; the reviewers' rungs stand and the aggregator adds none
Beside the smell baseline, both axes carry review-lens and its REGISTER.md: the stance, the reflex check, the catalog and register that raise candidates, and the severity rungs that place what survives.
lifecyclechangedfold-2026-09-11
both briefs carry the exact ticket and range identities, the scoped decisions and the reviewer's own retrieval access, the ticket's intent, scope and acceptance with the consumed spec at its pinned revision, and cite a decision or guidance unit as a standard; a ticket always supplies the Spec contract, so upstream's missing-spec skip survives only for a read-only request without a path, noted as a limit and never a pass, and an ambiguous contract is reported as the limit it is
- The full diff command and commit list.
- The full diff command and commit list, with the exact ticket and range identities.
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it).
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it), the scoped decisions, and the retrieval access it needs for its own guidance reads under this review's request handle.
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule, or the decision, or the guidance unit and its revision); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
lifecyclechangedfold-2026-09-11
both briefs carry the exact ticket and range identities, the scoped decisions and the reviewer's own retrieval access, the ticket's intent, scope and acceptance with the consumed spec at its pinned revision, and cite a decision or guidance unit as a standard; a ticket always supplies the Spec contract, so upstream's missing-spec skip survives only for a read-only request without a path, noted as a limit and never a pass, and an ambiguous contract is reported as the limit it is
- The diff command and commit list.
- The diff command and commit list, with the exact ticket and range identities.
- The path or fetched contents of the spec.
- The ticket's intent, scope and acceptance, and the path or fetched contents of the consumed spec at its pinned revision.
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line, or the ticket's acceptance line, for each finding. Under 400 words."
dependencychangedfold-2026-09-11
review-lens and its REGISTER.md are the roster's finding and severity discipline: both axes carry them, both briefs say to read them, refute each candidate and give each survivor its severity rung with the rule or acceptance criterion it cites; the reviewers' rungs stand and the aggregator adds none
If the spec is missing, skip the Spec sub-agent and note this in the final report.
Both briefs also say: read review-lens and its REGISTER.md, refute each candidate before filing it, and give each surviving finding its severity rung with the rule or acceptance criterion it cites. Each reviewer returns its own ranked findings.
lifecyclechangedfold-2026-09-11
both briefs carry the exact ticket and range identities, the scoped decisions and the reviewer's own retrieval access, the ticket's intent, scope and acceptance with the consumed spec at its pinned revision, and cite a decision or guidance unit as a standard; a ticket always supplies the Spec contract, so upstream's missing-spec skip survives only for a read-only request without a path, noted as a limit and never a pass, and an ambiguous contract is reported as the limit it is
A ticket always supplies the Spec contract, so the spec is missing only on a read-only request with no path; then skip the Spec sub-agent and note this in the final report as a limit, never as a pass. A contract that is present but ambiguous is reported as the concrete limit it is, with the missing intent obtained from the ticket's owner.
locationchangedfold-2026-09-11
the originating spec is the one the ticket's consumes pins at its revision (a compact ticket's intent, scope and acceptance when there is none), with consumed decisions when their rationale matters; the standards sources add greenline's homes, the decisions book and the initiative's decisions.md, actual configuration, installed guideline skills and guidance retrieved under the review's own request handle, derived independently of the implementer's selections; the aggregate lands below the frontmatter of REV-NNN.md for a durable review
Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_).
Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned, below the frontmatter of `.greenline/work/reviews/REV-NNN.md` for a durable review, or in the reply for a read-only request. Do **not** merge or rerank findings, because the two axes are deliberately separate (see _Why two axes_); the reviewers' severity rungs stand, and the aggregator adds none.
lifecyclechangedfold-2026-09-11
the durable review's transitions: a finding needing code returns the ticket to implementing and its request owner without the reviewer fixing it, a correction gets a new result and a second review waits for the operator's word, a clean supported review sets the review account's resultCommit to the end of range, completes the REV artifact and moves the ticket to verifying for verify-this; a missing prior account is a reviewLimit; the Handoff section names consumes, produces and next
For a durable review, the record is the account of what it saw. A standards finding cites the applicable decision, the exact guidance unit and revision, or the repository rule. A finding that needs a code change returns the ticket to implementing and its request owner; this review does not implement the fix in the review context. A correction receives a new result, and a second review of it waits for the operator's word. A future-ticket issue can be linked as a bounded trap note with its triggering condition. A clean, supported review sets the review account's `resultCommit` to the implementation commit at the end of `range`, completes the REV artifact, and moves the ticket to verifying, where verify-this proves its acceptance. A missing prior implementation account is an explicit `reviewLimit`, never invented evidence. Respect read-only scope and any other stop boundary, and return the findings or the supported result to the same request owner so the authorized work continues.
lifecyclechangedfold-2026-09-11
the durable review's transitions: a finding needing code returns the ticket to implementing and its request owner without the reviewer fixing it, a correction gets a new result and a second review waits for the operator's word, a clean supported review sets the review account's resultCommit to the end of range, completes the REV artifact and moves the ticket to verifying for verify-this; a missing prior account is a reviewLimit; the Handoff section names consumes, produces and next
## Handoff
Consumes: the ticket at implemented, its consumed spec (pinned revision), base_commit..result_commit, the pinned implementation account
Produces: .greenline/work/reviews/REV-NNN.md naming ticket, implementation_account and range; a review-role account; status reviewing then verifying on a clean review, or implementing when findings return the ticket
Next: verify-this proves the acceptance at verifying
2026-09-11series-s7-roster-2026-09-11
The S7 series (Hono OSS Codex, the judge's owed finding): a finding that would add repository furniture is written as a proposal for the operator, not as rework, so the reviewer is bound by the same rule as the implementer.
SKILL.md
scopechangedseries-s7-roster-2026-09-11
the durable review's transitions are unchanged (a finding needing code returns the ticket; a correction gets a new result and a second review waits for the word; a clean review moves the ticket to verifying; a missing prior account is a reviewLimit) and one sentence bounds what a finding may ask: repository furniture (a test lane, a script, a convention) is proposed to the operator, never assigned as rework, whatever standard names it
For a durable review, the record is the account of what it saw. A standards finding cites the applicable decision, the exact guidance unit and revision, or the repository rule. A finding that needs a code change returns the ticket to implementing and its request owner; this review does not implement the fix in the review context. A finding that would add repository furniture, a test lane, a script, a convention, is written as a proposal for the operator, not as rework, whatever standard names it. A correction receives a new result, and a second review of it waits for the operator's word. A future-ticket issue can be linked as a bounded trap note with its triggering condition. A clean, supported review sets the review account's `resultCommit` to the implementation commit at the end of `range`, completes the REV artifact, and moves the ticket to verifying, where verify-this proves its acceptance. A missing prior implementation account is an explicit `reviewLimit`, never invented evidence. Respect read-only scope and any other stop boundary, and return the findings or the supported result to the same request owner so the authorized work continues.
2026-09-11replay-s7-delivery-review-2026-09-11
The S7 replay on the Hono fixture on Codex (the Claude judge): the reviewer ran as a full-history fork of the implementer, which is not the independent context the copy asks for; the copy now names the mechanism.
the independent context is defined by its mechanism: a spawned agent started fresh that inherits none of the implementer's conversation, never a fork of the implementer's turns (Codex fork_turns), so the durable review is independent by construction on both harnesses
Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
Taking a ticket for a durable review is a separate contribution in an independent context, one that inherits none of the implementer's conversation (a spawned agent started fresh, never a fork of the implementer's turns): read `.greenline/WORK.md` and `.greenline/ledger/README.md`, write the draft `.greenline/work/reviews/REV-NNN.md` naming the ticket, its `implementation_account` and this `range`, open the review-role account whose `reviews` pins the implementation account bytes examined at their accounting commit, then advance the ticket to reviewing. A read-only request produces the report without repository edits.
2026-09-11ready-copies-2026-09-12
The readiness plan R1 and R2 (docs/greenline-ready-plan.md): the reviewer starts fresh by mechanism, a state a recorded decision forbids is in the spec axis's scope, and the first pass is bounded to the change's seams.
SKILL.md
harnesschangedready-copies-2026-09-12
each review sub-agent starts fresh with only its brief: on Codex it is spawned without the parent's turns (never fork_turns: all), because a fork of the implementer's conversation is not the independent context the method asks for (the Hono replay's judge)
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings. Each sub-agent starts fresh with only its brief: on Codex, spawn it without the parent's turns (never `fork_turns: all`); a fork of the implementer's conversation is not an independent context.
scopechangedready-copies-2026-09-12
the spec brief gains (d): a state or transition a recorded decision forbids that the diff can reach is in scope whether or not the ticket's acceptance names it, so a recorded decision (D5 on the Hono fixture) binds the review as the acceptance does; the sub-agent prompt lists are otherwise unchanged
- The diff command and commit list.
- The diff command and commit list, with the exact ticket and range identities.
- The path or fetched contents of the spec.
- The ticket's intent, scope and acceptance, and the path or fetched contents of the consumed spec at its pinned revision.
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong; (d) a state or transition a recorded decision forbids that the diff can reach, whether or not the ticket's acceptance names it. Quote the spec line, the ticket's acceptance line, or the decision, for each finding. Under 400 words."
scopechangedready-copies-2026-09-12
the first pass is bounded to the change's own seams and its acceptance; broad mutation, load or multi-process experiments run only for a named risk the ticket or a recorded decision carries, never inside the first pass of a first delivery, and an unprobed limit is reported as a limit (the greenfield first turns ended at the wall budget inside such probes)
The first pass is bounded to the change's own seams and its acceptance. Broad mutation, load or multi-process experiments run only for a named risk the ticket or a recorded decision carries, never inside the first pass of a first delivery; a limit the pass did not probe is reported as a limit, not explored.
A ticket always supplies the Spec contract, so the spec is missing only on a read-only request with no path; then skip the Spec sub-agent and note this in the final report as a limit, never as a pass. A contract that is present but ambiguous is reported as the concrete limit it is, with the missing intent obtained from the ticket's owner.
2026-09-11ready-review-role-2026-09-12
The readiness plan R3.1: a reviewer's read-only reads leave advisory stubs under the dispatching request, and the standards brief names the command that does it.
SKILL.md
harnesschangedready-review-role-2026-09-12
the standards sub-agent's retrieval access is named as the command it runs (greenline guidance read --read-only --from-request <handle> --role review), so each read leaves its advisory stub under the dispatching request and the ledger accounts for the reviewer's reads; the brief's content is otherwise unchanged
- The full diff command and commit list.
- The full diff command and commit list, with the exact ticket and range identities.
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it).
- The list of standards-source files you found in step 3, **plus the smell baseline from step 3** pasted in full (the sub-agent has no other access to it), the scoped decisions, and the retrieval access it needs for its own guidance reads under this review's request handle (`greenline guidance read <ids> --read-only --from-request <handle> --role review`, so each read leaves its advisory stub under the dispatching request).
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
- The brief: "Report, per file/hunk where relevant, (a) every place the diff violates a documented standard: cite the standard (file + the rule, or the decision, or the guidance unit and its revision); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls: documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces. Under 400 words."
2026-09-11ready-review-bound-2026-09-12
The readiness series (greenfield on Claude Code): the bounded first pass sat after the briefs, and the reviewer sub-agent ran mutation and lifecycle probes; the bound now sits inside the sentence both briefs carry.
SKILL.md
scopechangedready-review-bound-2026-09-12
the bounded first pass moves into the sentence both sub-agent briefs carry (read review-lens, refute each candidate, rung each finding, and keep the pass bounded to the change's seams: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery), so the reviewer receives the bound rather than the aggregator alone; the briefs' other content is unchanged
If the spec is missing, skip the Spec sub-agent and note this in the final report.
Both briefs also say: read review-lens and its REGISTER.md, refute each candidate before filing it, give each surviving finding its severity rung with the rule or acceptance criterion it cites, and keep the pass bounded to the change's own seams and its acceptance: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery; a limit the pass did not probe is reported as a limit, not explored. Each reviewer returns its own ranked findings.
scopechangedready-review-bound-2026-09-12
the bounded first pass moves into the sentence both sub-agent briefs carry (read review-lens, refute each candidate, rung each finding, and keep the pass bounded to the change's seams: no mutation, load or multi-process experiment unless the ticket or a recorded decision names the risk, never in the first pass of a first delivery), so the reviewer receives the bound rather than the aggregator alone; the briefs' other content is unchanged
A ticket always supplies the Spec contract, so the spec is missing only on a read-only request with no path; then skip the Spec sub-agent and note this in the final report as a limit, never as a pass. A contract that is present but ambiguous is reported as the concrete limit it is, with the missing intent obtained from the ticket's owner.
2026-09-11ready-review-convention-2026-09-12
The readiness series: the decision trigger for a convention (atomic transitions with a new 409) fired in none of six Hono runs on either harness, so the review becomes the second chance; the operator's word of 2026-09-12 (the series report's proposal for E).
SKILL.md
scopechangedready-review-convention-2026-09-12
the spec brief gains (e): a convention the diff introduces that other code must now follow and that no recorded decision names is in scope, quoted by the hunk that sets it and the decision home it is absent from, so a convention that landed without a decision returns the ticket with 'record it' as a finding; (a) to (d) and the word limit are unchanged
- The diff command and commit list.
- The diff command and commit list, with the exact ticket and range identities.
- The path or fetched contents of the spec.
- The ticket's intent, scope and acceptance, and the path or fetched contents of the consumed spec at its pinned revision.
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong; (d) a state or transition a recorded decision forbids that the diff can reach, whether or not the ticket's acceptance names it; (e) a convention the diff introduces that other code must now follow and that no recorded decision names. Quote the spec line, the ticket's acceptance line, or the decision, for each finding; for (e), the hunk that sets the convention and the decision home it is absent from. Under 400 words."
2026-09-12ready-review-installation-2026-09-12
The proof run r13-hono-oss-codex: the spec axis refuted the deployed-schema break as 'migration speculation' and the same agent ranked it as its one blocker in the self-review two minutes later; the operator's word of 2026-09-12 to patch every open conduct item.
SKILL.md
scopechangedready-review-installation-2026-09-12
the spec brief gains (f): a change to a stored representation that an existing installation cannot take is in scope, quoted by the statement that creates the representation and the one that changes it, so refuting it needs evidence rather than the word speculation; (a) to (e) and the word limit are unchanged
- The diff command and commit list.
- The diff command and commit list, with the exact ticket and range identities.
- The path or fetched contents of the spec.
- The ticket's intent, scope and acceptance, and the path or fetched contents of the consumed spec at its pinned revision.
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
- The brief: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong; (d) a state or transition a recorded decision forbids that the diff can reach, whether or not the ticket's acceptance names it; (e) a convention the diff introduces that other code must now follow and that no recorded decision names; (f) a change to a stored representation that an existing installation cannot take. Quote the spec line, the ticket's acceptance line, or the decision, for each finding; for (e), the hunk that sets the convention and the decision home it is absent from; for (f), the statement that creates the representation and the one that changes it. Under 400 words."
2026-09-12vocabulary-owner-2026-09-12
The workspace's person is the owner: the word operator became owner where the copy names the workspace's person, and request owner became request holder (the internal refactor's step 1, ruling 10, 2026-09-12); every earlier claim on a re-measured hunk is carried forward under its own kind, with its authority where it had one.