Step 5 of 7 · how deep it runs depends on how sure the change must be

review

about 11,400 tokens

review as it installs, each line coloured by where its words came from.

  • 7 files
  • 4 edits
  • 553 sentences left out
  • 5 sources
  • last changed 2026-10-19
  • step 5 of 7

Replaces delivery-review, review-lens and ponytail-review (retired 2026-10-08).

The text

SKILL.md

about 1,300 tokens
  • Jesse Vincent's Superpowers
  • pstack
  • greenline

---

name: "review"

description: "Review a change's commits for defects along two axes, Standards (the repository's documented standards, the smell baseline and the excess lens) and Spec (does the code do what its acceptance asked), by a reviewer briefed with the change record's front matter, its acceptance and its commits and never the builder's diagnosis, then judge every finding and act on it in the mode's fix round, at the depth the change's mode gives the review step. Use when the mode reaches review, or when the owner asks to review the branch, to review since X or a PR, or what can be deleted."

---

greenlineOpens review: two axes, when it runs, and its two halves

# Review

Review reads a change's commits for defects along two axes before the change is verified: Standards, how the code is written, and Spec, whether it does what was asked. It runs where the change's mode reaches the review step, at the depth the mode gives it, and alone when the owner asks for it by name: "review the branch", "review since X", a PR, or "what can we delete", which runs the excess lens alone. Asked for by name with no change open, the agent itself reviews the range the owner names, by the reviewer's brief, and the result stays in the reply: it starts no agent and writes no file. The skill has two halves, the reviewer's brief and the builder's half, each under its heading below. The reviewer never fixes what it finds, and the builder never edits a report.

greenlineNames the brief's own page, read whole by the reviewer

## The reviewer's brief

The reviewer's brief is a page of its own, `references/brief.md`: what the reviewer receives and never receives, the two axes, the rungs and its report. Who reads the brief depends on the depth: at the inline depth the builder reads it whole, reviewing its own commits; where fresh agents review, each fresh reviewer reads it whole and the builder never reads it, nor a brief file, which the builder never opens. The reviewer needs nothing else on this page.

greenlineOpens the builder's half, the session holding the change, with its intent

## The builder's half

This part is the builder's, the session holding the change, which writes its record.

### State the intent

In this half the user is the owner of the request.

pstackinterrogate/SKILL.md

Before spawning reviewers, state the intent explicitly. Derive this from:

- The user's message

- Commit messages

- PR description if one exists

- The code itself

Write one clear paragraph. If you're unsure about the intent, ask the user before proceeding.

greenlineLinks the reviewers' start right after the intent

Then, where fresh agents review, start the reviewers as [references/reviewers.md](references/reviewers.md) says.

greenlineReports keep findings as written; the builder judges every one

### Judge the findings

pstackinterrogate/references/lead-judgment.md

When the last report is in, judge every finding yourself. The reports keep each finding as its reviewer wrote it; the judgment is yours. Apply pragmatic engineering judgment. Don't aggregate. Filter, contextualize, and decide.

pstackinterrogate/SKILL.md

Categorize every finding, in the table, using these buckets:

- **Act on**. Real issues affecting correctness, security, or maintainability given the actual goals. These would block a real PR.

- **Consider**. Legitimate points, but you're not sure they outweigh the cost of addressing them right now. Worth the user's attention.

- **Noted**. Technically valid but not actionable. Context-dependent, premature optimization, or low-impact given the current stage.

- **Dismissed**. Wrong, nitpicky, or missing context. Brief explanation why.

pstackinterrogate/references/lead-judgment.md

The "Dismissed" bucket is not busywork. It's a trust mechanism. Showing the user what you rejected and why lets them override your judgment where they disagree. This is more valuable than hiding the rejected findings.

greenlineThe builder acts on judged findings in the mode's fix round

### Act on them

Act on the findings you judged act on, and on those under consider that you take up, in the fix round the mode gives. In what follows your human partner is the owner. The reviewer has finished when you act, so a question a report leaves open goes to the owner, and a pushback is written in the review section with its evidence.

Jesse Vincent's Superpowersreceiving-code-review/SKILL.md

```

WHEN receiving code review feedback:

1. READ: Complete feedback without reacting

2. UNDERSTAND: Restate requirement in own words (or ask)

3. VERIFY: Check against codebase reality

4. EVALUATE: Technically sound for THIS codebase?

5. RESPOND: Technical acknowledgment or reasoned pushback

6. IMPLEMENT: One item at a time, test each

```

Jesse Vincent's Superpowersreceiving-code-review/SKILL.md

```

IF any item is unclear:

STOP - do not implement anything yet

ASK for clarification on unclear items

WHY: Items may be related. Partial understanding = wrong implementation.

```

Jesse Vincent's Superpowersreceiving-code-review/SKILL.md

```

IF reviewer suggests "implementing properly":

grep codebase for actual usage

IF unused: "This endpoint isn't called. Remove it (YAGNI)?"

IF used: Then implement properly

```

Jesse Vincent's Superpowersreceiving-code-review/SKILL.md

```

FOR multi-item feedback:

1. Clarify anything unclear FIRST

2. Then implement in this order:

- Blocking issues (breaks, security)

- Simple fixes (typos, imports)

- Complex fixes (refactoring, logic)

3. Test each fix individually

4. Verify no regressions

```

Jesse Vincent's Superpowersreceiving-code-review/SKILL.md

Push back when:

- Suggestion breaks existing functionality

- Reviewer lacks full context

- Violates YAGNI (unused feature)

- Technically incorrect for this stack

- Legacy/compatibility reasons exist

- Conflicts with your human partner's architectural decisions

**How to push back:**

- Use technical reasoning, not defensiveness

- Ask specific questions

- Reference working tests/code

- Involve your human partner if architectural

greenlineCommit each fix with a test; a pushback keeps its evidence

Commit each fix, with a test where the fix changes behavior. A finding you push back on stays in the review section with your evidence.

greenlineThe handoff names review's outputs and the mode's next step

## Handoff

Consumes: the change record's front matter and its acceptance, the plan section's acceptance criteria, the ticket's entry in the plan directory's tickets.md, or the frame section where the mode skipped the plan; the change's commits by their trailer Produces: the review section of .greenline/ledger/<id>.md, one line at the inline depth, and at the independent depth the builder's judgment of every finding citing each reviewer's report .greenline/ledger/<id>/review-<n>.md; each fix as a commit carrying the trailer; the reply alone when asked for by name with no change open Next: the next step of the change's mode

SKILL.md as installed, byte for byte SHA-256 76c753de8f165a936745be92c9dae17c9f8072edaa518f01d4a9a714ea5749e0

The edits

Red is upstream's text; green is what greenline shipped in its place.

What the edit kinds mean
method
changes what the method does, under a recorded ruling
correction
fixes an error
scope
fits the text to this skill
pointer
re-points a reference
smaller edits
rename, relocate or adjust tool details

  1. Edit 3 method references/brief.md:22

    Upstream: A bad ref or empty diff should fail here, not inside two parallel sub-agents.

    Shipped: A bad ref or empty diff should fail here, not inside the review.

    A bad ref fails before the review; no parallel sub-agents run

    Full reason

    A bad ref fails before the review rather than inside two parallel sub-agents, which R20 declines; the reviewers run one after another.

    Ruling R4

  2. Edit 4 pointer references/brief.md:58

    Upstream: 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.

    Shipped: 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.

    A finding cites the decision or guidance unit it rests on

    Full reason

    The standards sources step 3 names include the recorded decisions and any guidance consulted, so a finding cites whichever it rests on.

2 smaller edits

Renames, locations and tool details, each with its reason.

  1. Edit 1 relocate SKILL.md:37

    Upstream: Categorize every finding using these buckets:

    Shipped: Categorize every finding, in the table, using these buckets:

    Each finding's bucket goes in the section's table

    Full reason

    The bucket is a column of the review section's table, so each finding is given its bucket there. Since J-93 S2 the table's form stands on the references page.

  2. Edit 2 relocate SKILL.md:44

    Upstream: The "Dismissed" section is not busywork.

    Shipped: The "Dismissed" bucket is not busywork.

    Dismissed findings are a bucket of the table, not a section

    Full reason

    With the bucket a column, the dismissed findings are a bucket of the table, not a section.

What greenline wrote

The full reason for every passage greenline wrote, in the order of the text.

  1. SKILL.md:6 scope

    The title and the opening paragraph in the step skill's own voice: what review reads and when (where the mode reaches it, or asked for by name, the excess lens alone for what can be deleted), what it does with no change open, and the two halves, the reviewer's brief on a page of its own and the builder's acting half, with neither crossing into the other; it replaces delivery-review's scope paragraph and upstream's opening, whose parallel sub-agents R20 and R21 decline.

  2. SKILL.md:10 pointer

    The reviewer's brief moves to a page of its own, which the reviewer reads whole and the builder reads only at the inline depth, so the builder at the other depths no longer reads it and the reviewer's page holds only the reviewer's part; this heading says where it went. Who reads the brief at each depth is stated once, the builder only at inline and never a brief file it wrote, since in the QA runs builders read the reviewer's brief and printed their reviewers' brief files at the independent and looped depths (J-60, the third to fifth families). The brief file is the command's, never the builder's, since in the Linear clone's QA run the builder derived, diffed and printed the brief files it wrote for its reviewers (J-60 S3a, the three judgments). Since J-93 S2 the brief command is named on the references page. Since J-93 S2 no mode loops review, so the looped depth leaves this text.

  3. SKILL.md:14 scope

    The builder's acting half opens as its own part, beside the reviewer's brief, and the intent paragraph interrogate states before the brief comes first; the bridge names the user in upstream's sentences as the owner; the builder is the session holding the change, which writes its record, one session at a time as the ledger guide says, so a session that resumes the change is the builder.

  4. SKILL.md:31 pointer

    The builder's half reads in order: after the intent comes the step that starts the reviewers, which a reference page holds, so it is linked where a reader going top to bottom needs it. Since J-93 S2 no mode loops review, so the looped depth leaves this text.

  5. SKILL.md:33 method

    The reports keep each finding as written and the builder's judgment filters and decides (contradiction 6); the lead reviewer of interrogate is the builder, after the last report. Since J-93 S2 no mode loops review, so the looped depth leaves this text. R1

  6. SKILL.md:46 scope

    receiving-code-review is the builder's acting half, after the lead judgment, spent in the mode's fix round; the bridge names upstream's human partner as the owner.

  7. SKILL.md:102 method

    A fix is the builder's, committed and tested where it changes behavior, and a pushback stays in the review section with its evidence, as delivery-review held; the commit's trailer, the recorder and when a fix is reviewed again stand on the references page since J-93 S2. R2

  8. SKILL.md:104 pointer

    The step skill's handoff: what review consumes, the review section and the reports it produces at each depth, and the next step of the change's mode, never a fixed skill. Since J-93 S2 no mode loops review, so the looped depth leaves this text.

  9. references/brief.md:1 method

    The reviewer's brief opens its own page, which the fresh agent reads whole: the one brief every fresh agent gets (the front matter, the acceptance, the change's id, its report's path and this page) with review's extras (the intent paragraph and, at two agents, the axis), and what it never receives (the builder's sections, conversation and diagnosis, or another reviewer's findings first), as the plan's change record rules; it replaces the sub-agent prompt lists the builder used to assemble. The facts of the checks a reviewer runs through greenline check are written beside its report. The page's head says the builder reads it only at the inline depth (J-60, the third to fifth families). The reviewer's brief arrives as the file greenline brief writes from the record, its acceptance the plan section, the ticket's acceptance or the frame section. A fresh reviewer's brief names its own scratch folder, where its working files go and never the host's temporary directory, after a fresh verifier wrote /tmp/.none in the Linear clone (J-60 S3a, F4). Since J-93 S2 the brief's paths, its command and the recorder stand on review's references page, which this page names for the reviewer. Since J-93 S2 no mode loops review, so the looped depth leaves this text. R3

  10. references/brief.md:7 pointer

    The review reads the change's commits, found by their trailer, rather than the diff from a fixed point to HEAD, which stays for a range the owner names.

    Credits: Matt Pocock's skills

  11. references/brief.md:14 pointer

    A change's commits are a set found by their trailer and by the commits touching its record, which status lists, so the diff of the code is captured from that set, leaving out the record and the reports the reviewer never receives; upstream's fixed point stays for a range the owner names with no change open. Since J-93 S2 the listing command and the diff's exclusion stand on review's references page.

    Credits: Matt Pocock's skills

  12. references/brief.md:26 relocate

    The originating spec is the change's acceptance and, when the work splits, the plan directory's spec and decisions; upstream's search order, through an issue tracker greenline does not keep, stays only as a path the owner passes or a spec file matching the branch; a missing or ambiguous spec is a limit, never a pass, as delivery-review held.

    Credits: Matt Pocock's skills

  13. references/brief.md:30 relocate

    The standards sources add greenline's homes, the repository's decision home and the decisions book, with the actual configuration, the installed skills and any guidance consulted, derived independently of the builder's selections, as delivery-review held. Since J-93 S2 the decisions book's path stands on review's references page.

  14. references/brief.md:52 pointer

    review-lens's stance and reflexes are review's lens page, the register stays its own reference file, and ponytail-review is the excess lens the Standards axis runs beside the smell baseline; this passage names the three pages the reviewer reads before filing a finding.

    Credits: Matt Pocock's skills

  15. references/brief.md:54 method

    Upstream's step 4 spawns both sub-agents in parallel; the reviewer reads its axis's brief itself, one axis or both in one pass as the depth gives, the briefs taken as upstream wrote them. R4

  16. references/brief.md:60 scope

    The Spec brief keeps delivery-review's (d), (e) and (f), a forbidden state, an unrecorded convention and a stored representation an installation cannot take, each quoted by what proves it; (a) to (c) and the word limit are upstream's, and the acceptance stands for the ticket's.

    Credits: Matt Pocock's skills

  17. references/brief.md:64 method

    The bounded pass delivery-review's briefs carried, now addressed to the reviewer, wins over thermo-nuclear-review's demand to trace every side effect (contradiction 8); its last sentence bridges to the breakage criteria grafted below. R1

    Credits: Matt Pocock's skills

  18. references/brief.md:66 method

    thermo-nuclear-review's devex rule becomes a condition crediting it: a change to how developers run or build the code is a finding citing a reasonable developer's expectation, its rung taken from that citation, with upstream's cases kept as the list. R5

    Credits: Cursor's team kit

  19. references/brief.md:72 method

    thermo-nuclear-review's feature-leak and intended-breakage rules become conditions crediting it: a leak past a gate is a finding citing that gate, and an intended effect in a constrained change goes on the set-aside list, so nothing is left unreported. R5

    Credits: Cursor's team kit

  20. references/brief.md:74 method

    Reading other reviews only after one's own pass is thermo-nuclear-review's, restated for the change's own review reports in place of the PR discussion and BugBot, which R21's portable form drops. R1

    Credits: Cursor's team kit

  21. references/brief.md:76 method

    requesting-code-review's template becomes the reviewer's brief (R21): its spec-silence rule and its declined-to-judge list, written because upstream holds them indented inside the template's fence, where a taken segment would render as a code block; upstream's grading of such a finding by its effect loses to the rungs, which grade by citation (contradiction 7), and the issue with the plan itself is a finding at the advisory rung (contradiction 9). R6

    Credits: Jesse Vincent's Superpowers

  22. references/brief.md:80 method

    The template's read-only and no-subagents rules, restated as the reviewer's own: its worktree option is dropped (R20), and the review agents are the mode's. The facts of the checks a reviewer runs through greenline check are the one write it makes beside its report. The scratch folder its brief names is the reviewer's third write. Since J-93 S2 the recorder is named on review's references page. R7

    Credits: Jesse Vincent's Superpowers

  23. references/brief.md:82 method

    Reviewers ran the change's tests and behaviour probes outside the recorder, so the record held no fact of them (J-60, the third and fifth families): a reviewer's checks are recorded and a probe runs plainly; the recorder's command, its round and its scratch folder stand on review's references page since J-93 S2. R8

  24. references/brief.md:84 method

    review-lens's severity ladder, carried into the reviewer's brief as the rungs a finding is placed on, numbered as the brief's fifth step, its first sentence naming the language lenses review-lens's description defined as a language's own review lenses, its note on whose ground the ladder is left to the workshop; rung 1 and 2 are the blocking rungs the looped depth's clean counts. R9

  25. references/brief.md:108 relocate

    The reviewer writes its own report under the change's folder, which the record cites, both axes under their headings with the excess lens's cuts, the declined list and the limits; delivery-review's bound on furniture findings stands; upstream's aggregation by the parent gives way to the builder's judgment. Since J-93 S2 the report's path stands on review's references page.

  26. references/brief.md:115 scope

    The no-findings stop of interrogate's reviewer prompt and the excess lens's lean line each end the findings, not the report, whose declined list and limits the brief requires.

  27. references/lens.md:1 method

    review-lens's title and opening, carried whole: the reviewer's output is findings on a diff, and the stance, the instruments and the ladder decide them. R10

  28. references/lens.md:9 pointer

    The lens is review's reference page now, read beside its register, and its severity ladder stands in the reviewer's brief, a page beside it.

  29. references/lens.md:11 method

    review-lens's stance, carried whole: an antipattern is a defeasible rule, and what counts as a finding. R10

  30. references/lens.md:30 method

    review-lens's reflex check, carried whole: a reaction that arrives before the reasoning is checked before it becomes a finding. R10

  31. references/lens.md:65 method

    review-lens's two instruments, carried whole: when and in which order to run the register's catalog rows and red flags. R10

  32. references/lens.md:72 method

    review-lens's limits, carried whole: obligations come from the task, the diff and the repository's decisions, under AGENTS.md's authority. R10

  33. references/REGISTER.md:1 method

    The register's title and opening, carried whole from review-lens: the register of complexity symptoms and the catalog beside it are two instruments, kept apart. R10

  34. references/REGISTER.md:17 method

    The register's fourteen, carried whole from review-lens: the symptoms of excess complexity, each stated about interfaces and modules. R10

  35. references/REGISTER.md:122 method

    The catalog's seven, carried whole from review-lens: the cheap rows run before the red flags. R10

  36. references/excess.md:1 scope

    The excess lens opens in its own voice: ponytail-review run by the Standards reviewer, or alone when asked for by name, with correctness the axes' and test-suite cuts sweep-tests'; it reports and never applies, the builder judging each cut.

  37. references/excess.md:3 method

    The repository's documented standard overrides the excess lens as it does the smell baseline, so a comment or a shape the repository requires is never a cut. R11

  38. references/excess.md:32 method

    ponytail-audit's ranking, biggest cut first, enters the excess lens; its whole-tree scan does not, the lens reading the change's commits. R1

    Credits: Dietrich Gebert's Ponytail

  39. references/excess.md:64 method

    no-comments' agent file becomes a reference passage of the excess lens with no agent of its own and its persona voice dropped (R21): a comment is a cut unless an exception keeps it, reported in the lens's format. R1

    Credits: pstack

  40. references/excess.md:74 method

    The agent file's rules restated without its persona: the doubtful keep is a cut, an own-code surprise is reported with the MUST KILL reshape flag, rung 3 unless it cites a rule, a suppression is read against its rule, a protective note is scent read against the code; report only, its fixes the builder's in the fix round, its pointers to how, why and architect dropped. R6

    Credits: pstack

  41. references/reviewers.md:1 method

    Starting the reviewers is a references page of review since J-93 S2, greenline's mechanics alone, read at the independent depth: its title and opening line say when the builder reads it. R12

  42. references/reviewers.md:5 method

    The reviewers are the review step's own agents, run one after another through the harness's delegation, each given the one brief every fresh agent gets, pointing at the reviewer's brief page, with review's extras and its brief written to the change's working files, each report named for the step and its number, none delegating, never a fork of the builder's turns; it replaces interrogate's single-message dispatch, its model table and model diversity, and requesting-code-review's dispatch syntax. The builder writes no reviewer's brief: greenline brief writes each one from the record into the change's folder and prints its path, which alone starts the reviewer, and the builder never opens, copies, diffs or derives a brief file, since in the Linear clone's QA run the builder derived, diffed and printed the brief files it wrote for its reviewers (J-60 S3a, the three judgments). R13

  43. references/greenline.md:1 method

    Review's references page opens: review at each mode's depth, fresh agents and the reviewer's mechanics, which the block's sentences and, since J-93 S2, the front's depth bullets, its judgment's table and its brief's paths moved here. R14

  44. references/greenline.md:5 method

    Review's depths at each mode: none at quick, one fresh reviewer at regular and two at careful, the Standards axis first and the Spec second, the builder reading the reviewers page and never the brief, inline where no agent can be started, review's own fix pass; moved from the front's depth bullets by J-93 S2. R15

  45. references/greenline.md:15 method

    The lead judgment is written in the change record's review section as one table, the ledger guide's finding, severity and what was done with the bucket a column, citing each report; moved from the front by J-93 S2, it replaces interrogate's verdict format, its reviewer labels and its agreement map. R12

  46. references/greenline.md:19 method

    A fix is committed with the change's trailer and a reviewer's and the fixing builder's checks are recorded, a second review of a fix waiting for the owner's word, as delivery-review held (J-60, the third and fifth families); moved from the front by J-93 S2. R2

  47. references/greenline.md:23 method

    Review's references page: one fresh agent at a time, briefed once, delegating nothing. The block's sentences on it move here whole, so the block carries the loop, the promises, the modes and the situation index, and no promise leaves the installation. R16

  48. references/greenline.md:27 method

    What a fresh reviewer needs beside its brief: the brief file, its report's and scratch folder's paths, the command that lists the change's commits and the diff's exclusion, the decisions book's path, and its checks through greenline check with its round; moved from the reviewer's brief page by J-93 S2. R8

What it left out

pstack

pstack, interrogate/SKILL.md: 76 of 97 sentences left out
  1. # Interrogate left out: The title gives way to the step's own.
  2. Spawn one reviewer per configured model to adversarially review code changes.
  3. Each model gets the same prompt and rubric.
  4. The adversarial signal comes from model diversity, not assigned personas. 3 sentences left out: One reviewer per configured model and the signal of model diversity are dropped, not held: the harness chooses the model, and the reviewers are the step's own agents. R4 replaced by line 5 of references/reviewers.md
  5. The deliverable is a synthesized verdict.
  6. Do NOT auto-apply changes. 2 sentences left out: That the review applies nothing is the scope paragraph's: the reviewer never fixes, and the builder acts in the fix round. replaced by line 6 of SKILL.md
  7. ## Step 1, Determine Scope
  8. Identify what to review from context:
  9. If the user points at specific files or a diff, use that
  10. If on a feature branch, run `git diff main...HEAD` (or the appropriate base branch) for the full changeset
  11. If the user's message references recent work, gather the relevant files
  12. Package the diff (or file contents) plus any surrounding context files the reviewers need to understand the code. 6 sentences left out: The scope is the change's commits, which the brief's first step pins. replaced by line 14 of references/brief.md
  13. ## Step 2, State the Intent left out: The step heading gives way to the builder's half's heading. replaced by line 14 of SKILL.md
  14. 8 sentences taken
  15. ## Step 3, Spawn Reviewers
  16. Launch all reviewers in a single message using the Task tool.
  17. Use the `interrogate reviewers` line in `~/.cursor/rules/pstack-models.mdc`, one reviewer per entry, extending or shrinking the Reviewer A/B labels below to the configured entry count.
  18. If the rule or that line is missing, use the table defaults.
  19. | Subagent | Default model |
  20. |----------|---------------|
  21. | Reviewer A | `claude-opus-5-5-xhigh` |
  22. | Reviewer B | `grok-4.7-xhigh-fast` |
  23. For each reviewer:
  24. `subagent_type`: `generalPurpose`
  25. `model`: the configured `interrogate reviewers` entry, or the table default with no configured line.
  26. For an `auto` or `inherit-parent` entry, omit `model` so that reviewer runs on the parent model.
  27. `readonly`: `true`
  28. If the Task tool rejects a configured entry, run that reviewer on the table default of its family and say so.
  29. Families go by prefix: `claude-*` and `grok-*`.
  30. With no family match, use Reviewer A's default.
  31. If it rejects a table default, check the valid slugs in the Task tool's error message, pick the closest equivalent (prefer the same family and reasoning tier), spawn with it, and open a separate PR to update the default table.
  32. Do not block the review on the slug issue.
  33. Never treat an alias entry as a rejected slug or apply either fallback to it.
  34. Read `references/reviewer-prompt.md` and fill in the template with:
  35. The stated intent
  36. The diff or file contents
  37. The review rubric from `references/rubric.md`
  38. The code-quality lens from `references/code-quality-review.md`
  39. The same filled template goes to all reviewers, so every model applies the code-quality lens. 25 sentences left out: Launching all reviewers in a single message, the model table, the Task tool's settings and its fallbacks, and the filled template with the rubric and the code-quality lens give way to the reviewers started one after another with the reviewer's brief; the rubric's security list is garden's and the code-quality lens a duplicate of the declined thermo-nuclear-code-quality-review. R17 replaced by line 5 of references/reviewers.md
  40. ## Step 4, Synthesize
  41. As results come back, build a unified picture:
  42. **Parse all findings** from the reviewers
  43. **Identify consensus**.
  44. Findings raised by 2+ models independently are highest signal.
  45. **Identify lone-model findings**.
  46. Still worth reading, but weight accordingly.
  47. **Deduplicate**.
  48. Different models may describe the same issue differently.
  49. Merge these and note which models raised it.
  50. **Note disagreements**.
  51. If one model flags something and another explicitly says the opposite, that's useful context for the verdict. 12 sentences left out: Synthesizing consensus across models goes with model diversity; the reports keep each finding as written (contradiction 6). R1 replaced by line 33 of SKILL.md
  52. ## Step 5, Lead Judgment
  53. You are the lead reviewer, a pragmatic senior engineer, not a neutral aggregator.
  54. Read `references/lead-judgment.md` for the full framework. 3 sentences left out: The lead reviewer is the builder, judging after the last report; the full framework's taken lines follow the buckets. replaced by line 33 of SKILL.md
  55. 13 sentences taken
  56. For each finding, include:
  57. Which model(s) raised it
  58. The category (act on / consider / noted / dismissed)
  59. A one-line rationale for the categorization
  60. ## Output Format
  61. Present the verdict in this structure:
  62. ### Intent
  63. [The stated intent paragraph from Step 2]
  64. ### Reviewers
  65. Reviewer [label]: [model name], [N findings] (one bullet per reviewer)
  66. ### Act On
  67. [Findings that should be addressed.
  68. For each: description, which models raised it, why it matters.]
  69. ### Consider
  70. [Findings worth thinking about.
  71. For each: description, which models raised it, tradeoff involved.]
  72. ### Noted
  73. [Valid but low-priority.
  74. Brief list.]
  75. ### Dismissed
  76. [Rejected findings with brief rationale.]
  77. ### Agreement Map
  78. [Where did models agree, where did they diverge, and what does the pattern of agreement/disagreement tell us?] 23 sentences left out: The verdict's format, its reviewer labels and its agreement map give way to the review section's judgment, which cites each report. replaced by line 15 of references/greenline.md
pstack, interrogate/references/lead-judgment.md: 57 of 64 sentences left out
  1. # Lead Judgment Framework
  2. You are the lead reviewer.
  3. The configured reviewers have produced their findings. 3 sentences left out: The framework's title and its configured reviewers give way to the judge heading. replaced by line 33 of SKILL.md
  4. 3 sentences taken
  5. ## Why This Step Matters
  6. Adversarial reviewers are useful because they're aggressive.
  7. But aggression without context produces noise.
  8. The reviewers only saw a slice of the codebase and a one-paragraph intent statement.
  9. They don't know:
  10. What was already tried and rejected
  11. What constraints exist outside the code (timeline, dependencies, migration plans)
  12. Which parts of the code are temporary scaffolding vs. permanent architecture
  13. What the next PR in the stack will address
  14. You have the full conversation context.
  15. Use it. 11 sentences left out: Why the step matters argues for the judgment the buckets carry; the builder's context is the change record.
  16. ## Filtering Principles
  17. ### Nitpick Gravity
  18. Reviewers, especially adversarial ones, tend to fill their review.
  19. If they don't find critical issues, they'll inflate nits to fill the space.
  20. If a reviewer's findings are all nits and style preferences, the code is probably fine.
  21. Say so.
  22. ### Hypothetical vs. Actual
  23. "What if someone passes null here?"
  24. is only a finding if the caller can actually pass null.
  25. Trace the call site.
  26. If the input is validated upstream or the type system prevents it, dismiss the finding.
  27. Reviewers working from a diff can't always see the full call chain.
  28. You can.
  29. ### Premature Abstraction Warnings
  30. Reviewers often suggest extracting functions, adding interfaces, or creating abstractions.
  31. Does this code need to change in a second way?
  32. If not, the abstraction is premature.
  33. Simple inline code that works beats a clean abstraction that's overkill for the current scope.
  34. ### "I Would Have Done It Differently"
  35. This is the most common false positive in code review.
  36. A finding that amounts to "I prefer a different approach" is not a bug, not a design flaw, and not actionable unless the reviewer shows a concrete problem with the current approach.
  37. Dismiss these, and say why.
  38. ### Missing Context Signals
  39. Watch for findings that reveal the reviewer didn't understand the context:
  40. Suggesting changes to code the author didn't write or modify
  41. Flagging patterns that are consistent with the rest of the codebase (the reviewer just doesn't know that)
  42. Recommending approaches that conflict with constraints you know about
  43. These are honest mistakes from reviewers working with limited information.
  44. Dismiss them gracefully. 29 sentences left out: The filtering principles duplicate the lens: a hypothetical is killed by reachability, an abstraction warning by premature abstraction being worse than duplication, and a different preference is not evidence (references/lens.md).
  45. ## When Reviewers Are Right
  46. Don't dismiss findings just because they're uncomfortable.
  47. The whole point of adversarial review is to catch things you'd miss.
  48. Signs a finding deserves attention:
  49. Multiple models flag the same issue independently (consensus signal)
  50. The finding identifies a concrete execution path, not a hypothetical
  51. The finding reveals a gap in your mental model of the code
  52. You read the finding and think "...yeah, actually"
  53. Be especially careful about dismissing security findings and correctness bugs.
  54. These deserve more scrutiny even when they come from a single model.
  55. ## Verdict Calibration
  56. A good verdict is useful, not comprehensive.
  57. The user should be able to read the "Act On" section, fix those issues, and ship with confidence.
  58. If your "Act On" list has more than 5 items, you're probably not filtering hard enough. 14 sentences left out: When reviewers are right and the calibration of the act-on list restate the buckets; consensus across models goes with model diversity.
pstack, interrogate/references/reviewer-prompt.md: 46 of 50 sentences left out
  1. # Reviewer Prompt Template
  2. Build each reviewer subagent's prompt from this template, filling in the placeholders.
  3. You are an adversarial code reviewer.
  4. Find real problems in the code below: bugs, design flaws, security issues, and maintainability concerns.
  5. You are not here to be helpful or encouraging.
  6. You are here to stress-test.
  7. ## Intent
  8. The author's stated intent for this change:
  9. {INTENT}
  10. You are reviewing whether the code achieves this intent well.
  11. Do NOT question the intent itself.
  12. Assume the goal is correct and challenge the execution.
  13. ## Code Under Review
  14. {DIFF_OR_FILES}
  15. ## Review Rubric
  16. {RUBRIC_CONTENTS}
  17. ## Code Quality Lens
  18. {CODE_QUALITY_CONTENTS} 18 sentences left out: The reviewer prompt template gives way to requesting-code-review's as the reviewer's brief; not questioning the intent loses to reporting an issue with the plan at the advisory rung (contradiction 9). R1 replaced by line 1 of references/brief.md
  19. ## Instructions
  20. Review the code through every lens in the rubric and the code-quality lens above that you find relevant.
  21. Do not force lenses that don't apply.
  22. A simple bug fix does not need paragraphs about architectural integrity.
  23. For each finding, provide:
  24. **Severity**: `critical` | `warning` | `nit`
  25. `critical`: Would cause bugs, data loss, security issues, or fundamentally broken behavior
  26. `warning`: Design concern, maintainability risk, or correctness issue that isn't immediately broken but will cause pain
  27. `nit`: Style, naming, minor improvement.
  28. **Finding**: What the problem is, in concrete terms.
  29. Reference specific lines/functions.
  30. **Evidence**: Why you believe this is a problem.
  31. Show your reasoning.
  32. Don't just assert.
  33. **Suggestion** (optional): What you'd do instead, if you have a concrete alternative.
  34. Skip this if you don't have a clear fix. 16 sentences left out: Severity by critical, warning and nit loses to the lens's rungs (contradiction 7), and the finding's parts are the report's. R1 replaced by line 82 of references/brief.md
  35. ## What Makes a Good Finding
  36. It references specific code, not vague concerns ("this could be better")
  37. It explains WHY something is a problem, not just THAT it is
  38. It distinguishes between "this is broken" and "I would have done this differently"
  39. It considers the stated intent.
  40. A finding that ignores the context of what's being built is a bad finding
  41. ## What to Avoid 7 sentences left out: What makes a good finding duplicates the lens's stance and the report's parts. replaced by line 84 of references/brief.md
  42. 4 sentences taken
  43. ## Output
  44. Return your findings as a structured list.
  45. If you have zero findings, say so.
  46. An empty review is a valid outcome.
  47. ``` ## Findings ### 1. [Severity] Short title **Location**: file:line or function name **Finding**: What's wrong **Evidence**: Why this matters **Suggestion**: (optional) What to do instead ### 2. [Severity] Short title ... ``` 5 sentences left out: The output format gives way to the report step; an empty review is a result, as the lens says.
pstack, comment-sicko/SKILL.md: 37 of 43 sentences left out
  1. # Comment Sicko
  2. My first output when spawned is exactly this.
  3. Yes...
  4. Ha ha ha...
  5. Yes!
  6. I hate comments.
  7. Feed me the parent scoped files or diff.
  8. If none exists, feed me the current diff against `main`.
  9. Narration, banners, commented-out corpses, workaround sermons.
  10. I want them all.
  11. Only these exceptions get to crawl away. 11 sentences left out: The agent's persona, its spawn greeting and its feeding are dropped with its agent (R21); the exceptions follow the comments heading. R1 replaced by line 64 of references/excess.md
  12. 2 sentences taken
  13. Surprises in our own code are meat.
  14. Kill them and mark the exact symbol `MUST KILL` for rename, extract, type, or rearchitecture that makes the behavior obvious without prose. 2 sentences left out: An own-code surprise is reported with its MUST KILL reshape flag, report only, in place of the persona's kill. R1 replaced by line 74 of references/excess.md
  15. 4 sentences taken
  16. That list is my only leash.
  17. When I am not sure a keep clause applies, the comment dies.
  18. Everything else is meat.
  19. `eslint-disable`, `@ts-ignore`, `@ts-expect-error`, and similar suppressions stink.
  20. Look up the rule.
  21. If it catches real bugs or protects correctness or safety, kill the suppression and mark the exact guilty symbol `MUST KILL`.
  22. `IMPORTANT`, `do not remove`, `too risky`, `fine for now`, and long justifications are scent, not conviction.
  23. Before judging, I read nearby code.
  24. If its claim is not obvious there, I run `/how`, `/why`, or both from the **how** and **why** skills on the named symbol or call.
  25. Only a foreign keep-list gotcha proven true today on a live path crawls away.
  26. Our-code surprises die with the reshape flag above.
  27. Doubt after the hunt is meat.
  28. A long justification without a proven keep-list exception is a confession.
  29. Kill it.
  30. Never polish meat into a shorter alibi.
  31. Mark the exact guilty symbol `MUST KILL`.
  32. My kill ends there.
  33. I do not touch the code.
  34. Every flag names code inside the scope and tells the truth.
  35. I invent nothing.
  36. I touch comments and identify refactor targets.
  37. I never write application code.
  38. Report only.
  39. Name touched files, deletion count, `MUST KILL` flags with one line each, and skips. 24 sentences left out: The doubtful keep, the suppressions, the protective notes and report only are restated without the persona; the pointers to the how, why and architect skills leave, the roster having none, and the agent's own comment edits give way to report only. R1 replaced by line 74 of references/excess.md

Jesse Vincent's Superpowers

Jesse Vincent's Superpowers, receiving-code-review/SKILL.md: 72 of 88 sentences left out
  1. # Code Review Reception
  2. ## Overview
  3. Code review requires technical evaluation, not emotional performance.
  4. **Core principle:** Verify before implementing.
  5. Ask before assuming.
  6. Technical correctness over social comfort.
  7. ## The Response Pattern 7 sentences left out: The title, the overview and the response pattern's heading give way to the acting half's heading; the pattern itself is taken. replaced by line 46 of SKILL.md
  8. 1 sentence taken
  9. ## Forbidden Responses
  10. **NEVER:**
  11. "You're absolutely right!"
  12. (explicit instruction-file violation)
  13. "Great point!"
  14. / "Excellent feedback!"
  15. (performative)
  16. "Let me implement that now" (before verification)
  17. **INSTEAD:**
  18. Restate the technical requirement
  19. Ask clarifying questions
  20. Push back with technical reasoning if wrong
  21. Just start working (actions > words) 13 sentences left out: The forbidden responses are tone rules for a reply to a person; the builder's answer to a finding is its judgment and its fix.
  22. ## Handling Unclear Feedback left out: The heading gives way to the run of the acting half's rules.
  23. 1 sentence taken
  24. **Example:**
  25. ``` your human partner: "Fix 1-6" You understand 1,2,3,6. Unclear on 4,5. ❌ WRONG: Implement 1,2,3,6 now, ask about 4,5 later ✅ RIGHT: "I understand items 1,2,3,6. Need clarification on 4 and 5 before proceeding." ``` 2 sentences left out: The example illustrates the rule on unclear items, which is taken.
  26. ## Source-Specific Handling
  27. ### From your human partner
  28. **Trusted** - implement after understanding
  29. **Still ask** if scope unclear
  30. **No performative agreement**
  31. **Skip to action** or technical acknowledgment
  32. ### From External Reviewers 7 sentences left out: Feedback from the owner is the owner's word, which any step follows; the heading of the external reviewer's checks gives way to the run of rules.
  33. ``` BEFORE implementing: 1. Check: Technically correct for THIS codebase? 2. Check: Breaks existing functionality? 3. Check: Reason for current implementation? 4. Check: Works on all platforms/versions? 5. Check: Does reviewer understand full context? IF suggestion seems wrong: Push back with technical reasoning IF can't easily verify: Say so: "I can't verify this without [X]. Should I [investigate/ask/proceed]?" IF conflicts with your human partner's prior decisions: Stop and discuss with your human partner first ``` left out: The external reviewer's checks duplicate the response pattern's verify and evaluate and the list of when to push back, which are taken. replaced by line 88 of SKILL.md
  34. **your human partner's rule:** "External feedback - be skeptical, but check carefully"
  35. ## YAGNI Check for "Professional" Features 2 sentences left out: The owner's rule restates the external checks; the YAGNI heading gives way to the run of rules.
  36. 1 sentence taken
  37. **your human partner's rule:** "You and reviewer both report to me.
  38. If we don't need this feature, don't add it."
  39. ## Implementation Order 3 sentences left out: The owner's rule restates the YAGNI check; the order's heading gives way to the run of rules.
  40. 1 sentence taken
  41. ## When To Push Back left out: The push-back heading gives way to the run of rules.
  42. 12 sentences taken
  43. **If you're uncomfortable pushing back out loud:** Name that tension, then tell your partner about the issue you've seen.
  44. They'll appreciate your honesty.
  45. ## Acknowledging Correct Feedback
  46. When feedback IS correct:
  47. ``` ✅ "Fixed. [Brief description of what changed]" ✅ "Good catch - [specific issue]. Fixed in [location]." ✅ [Just fix it and show in the code] ❌ "You're absolutely right!" ❌ "Great point!" ❌ "Thanks for catching that!" ❌ "Thanks for [anything]" ❌ ANY gratitude expression ```
  48. **Why no thanks:** Actions speak.
  49. Just fix it.
  50. The code itself shows you heard the feedback.
  51. **If you catch yourself about to write "Thanks":** DELETE IT.
  52. State the fix instead.
  53. ## Gracefully Correcting Your Pushback
  54. If you pushed back and were wrong:
  55. ``` ✅ "You were right - I checked [X] and it does [Y]. Implementing now." ✅ "Verified this and you're correct. My initial understanding was wrong because [reason]. Fixing." ❌ Long apology ❌ Defending why you pushed back ❌ Over-explaining ```
  56. State the correction factually and move on. 14 sentences left out: Voicing discomfort, acknowledging correct feedback and correcting one's pushback are tone rules for a reply to a person, which a fix and the review section carry.
  57. ## Common Mistakes
  58. | Mistake | Fix |
  59. |---------|-----|
  60. | Performative agreement | State requirement or just act |
  61. | Blind implementation | Verify against codebase first |
  62. | Batch without testing | One at a time, test each |
  63. | Assuming reviewer is right | Check if breaks things |
  64. | Avoiding pushback | Technical correctness > comfort |
  65. | Partial implementation | Clarify all items first |
  66. | Can't verify, proceed anyway | State limitation, ask for direction |
  67. ## Real Examples
  68. **Performative Agreement (Bad):**
  69. ``` Reviewer: "Remove legacy code" ❌ "You're absolutely right! Let me remove that..." ```
  70. **Technical Verification (Good):**
  71. ``` Reviewer: "Remove legacy code" ✅ "Checking... build target is 10.15+, this API needs 13+. Need legacy for backward compat. Current impl has wrong bundle ID - fix it or drop pre-13 support?" ```
  72. **YAGNI (Good):**
  73. ``` Reviewer: "Implement proper metrics tracking with database, date filters, CSV export" ✅ "Grepped codebase - nothing calls this endpoint. Remove it (YAGNI)? Or is there usage I'm missing?" ```
  74. **Unclear Item (Good):**
  75. ``` your human partner: "Fix items 1-6" You understand 1,2,3,6. Unclear on 4,5. ✅ "Understand 1,2,3,6. Need clarification on 4 and 5 before implementing." ``` 19 sentences left out: The common mistakes and the real examples restate the pattern, the checks and the YAGNI rule taken.
  76. ## GitHub Thread Replies
  77. When replying to inline review comments on GitHub, reply in the comment thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level PR comment. 2 sentences left out: Replying in a GitHub comment thread through gh is vendor tooling; the builder's answer is its judgment in the review section.
Jesse Vincent's Superpowers, requesting-code-review/SKILL.md: all left out
  1. # Requesting Code Review
  2. Dispatch a code reviewer subagent to catch issues before they cascade.
  3. The reviewer gets precisely crafted context for evaluation — never your session's history.
  4. **Core principle:** Review early, review often. 4 sentences left out: Dispatching a reviewer subagent with crafted context and never the session's history is the depths' fresh agent and the brief's never-receives, one after another (R21). R4 replaced by line 5 of references/reviewers.md
  5. ## When to Request Review
  6. **Mandatory:**
  7. After each task in subagent-driven development
  8. After completing major feature
  9. Before merge to main
  10. **Optional but valuable:**
  11. When stuck (fresh perspective)
  12. Before refactoring (baseline check)
  13. After fixing complex bug 9 sentences left out: When to request a review is the change's mode, which reaches the review step.
  14. ## How to Request
  15. **1.
  16. Get git SHAs:**
  17. ```bash BASE_SHA=$(git rev-parse HEAD~1) # or: git merge-base origin/main HEAD HEAD_SHA=$(git rev-parse HEAD) ```
  18. **2.
  19. Dispatch code reviewer subagent:**
  20. Dispatch a `general-purpose` subagent, filling the template at [code-reviewer.md](code-reviewer.md)
  21. **Placeholders:**
  22. `{DESCRIPTION}` - Brief summary of what you built
  23. `{PLAN_OR_REQUIREMENTS}` - What it should do
  24. `{BASE_SHA}` - Starting commit
  25. `{HEAD_SHA}` - Ending commit 12 sentences left out: The SHAs and the general-purpose subagent with its placeholders give way to the change's commits by their trailer and to what the builder gives each reviewer. replaced by line 5 of references/reviewers.md
  26. **3.
  27. Act on feedback:**
  28. Fix Critical issues immediately
  29. Fix Important issues before proceeding
  30. Note Minor issues for later
  31. Push back if reviewer is wrong (with reasoning) 6 sentences left out: Acting on Critical, Important and Minor issues gives way to the lead judgment's buckets over the lens's rungs (contradiction 7) and to the acting half. R1 replaced by line 33 of SKILL.md
  32. ## Example
  33. ``` [Just completed Task 2: Add verification function] You: Let me request code review before proceeding. BASE_SHA=$(git log --oneline | grep "Task 1" | head -1 | awk '{print $1}') HEAD_SHA=$(git rev-parse HEAD) [Dispatch code reviewer subagent] DESCRIPTION: Added verifyIndex() and repairIndex() with 4 issue types PLAN_OR_REQUIREMENTS: Task 2 from docs/superpowers/plans/deployment-plan.md BASE_SHA: a7981ec HEAD_SHA: 3df7661 [Subagent returns]: Strengths: Clean architecture, real tests Issues: Important: Missing progress indicators Minor: Magic number (100) for reporting interval Assessment: Ready to proceed You: [Fix progress indicators] [Continue to Task 3] ```
  34. ## Common Rationalizations
  35. | Excuse | Reality |
  36. |--------|---------|
  37. | "I'll just review the diff myself instead of dispatching a reviewer" | You're the coordinator — reviewing the diff inline burns the context window you need to keep driving the work. Dispatch a reviewer subagent: the diff and the evaluation live in its context, and only the findings come back to you. |
  38. | "The reviewer needs my whole session history to understand the change" | Hand it precisely crafted context, never your session's history. That keeps the reviewer on the work product, not your thought process. | 7 sentences left out: The example and the rationalizations argue for dispatching a reviewer, which the depths decide.
  39. ## Red Flags
  40. **Never:**
  41. Skip review because "it's simple"
  42. Ignore Critical issues
  43. Proceed with unfixed Important issues
  44. Argue with valid technical feedback
  45. **If reviewer wrong:**
  46. Push back with technical reasoning
  47. Show code/tests that prove it works
  48. Request clarification
  49. See template at: [code-reviewer.md](code-reviewer.md) 11 sentences left out: The red flags repeat the acting half's push back with evidence, and skipping a review is the mode's.
Jesse Vincent's Superpowers, requesting-code-review/code-reviewer.md: all left out
  1. # Code Reviewer Prompt Template
  2. Use this template when dispatching a code reviewer subagent.
  3. **Purpose:** Review completed work against requirements and code quality standards before it cascades into more work.
  4. ``` Subagent (general-purpose): description: "Review code changes" prompt: | You are a Senior Code Reviewer with expertise in software architecture, design patterns, and best practices. Your job is to review completed work against its plan or requirements and identify issues before they cascade. ## What Was Implemented [DESCRIPTION] ## Requirements / Plan [PLAN_OR_REQUIREMENTS] ## Git Range to Review **Base:** [BASE_SHA] **Head:** [HEAD_SHA] ```bash git diff --stat [BASE_SHA]..[HEAD_SHA] git diff [BASE_SHA]..[HEAD_SHA] ``` 4 sentences left out: The template's dispatch header and its senior-reviewer persona give way to the reviewer's brief, which tells the reviewer what it receives (R21). R4 replaced by line 1 of references/brief.md
  5. ## The spec is a vision document
  6. The spec says what the software must do.
  7. It does not enumerate every input, environment, or condition the software will meet.
  8. For behavior the spec is silent on, judge by what a reasonable person using this software would expect: a reasonable person's expectation is a requirement, and a spec's silence is not permission. 4 sentences left out: The spec as a vision document is restated in the reviewer's brief, since upstream holds it indented inside the template's fence. replaced by line 76 of references/brief.md
  9. Grade such findings by their effect on that person, not by whether the spec mentions the trigger. left out: Grading a spec-silence finding by its effect on the person loses to the rungs, which grade by citation (contradiction 7); the brief places such a finding by the expectation it cites. R1 replaced by line 76 of references/brief.md
  10. ## Declined to judge
  11. Before your verdict, list every behavior you considered and set aside as outside the plan or spec, one line each, with the reason.
  12. The executor rules on each line; nothing you set aside is dropped silently.
  13. An empty list means you set nothing aside. 4 sentences left out: The declined-to-judge list is restated in the reviewer's brief, since upstream holds it indented inside the template's fence. replaced by line 76 of references/brief.md
  14. ## Read-Only Review
  15. Your review is read-only on this checkout.
  16. Do not mutate the working tree, the index, HEAD, or branch state in any way.
  17. Use tools like `git show`, `git diff`, and `git log` to inspect history. 4 sentences left out: The read-only review is restated in the reviewer's brief. replaced by line 80 of references/brief.md
  18. If you need a working copy of a different revision, check it out into a separate temporary directory (e.g. `git worktree add /tmp/review-[SHA] [SHA]`) — never move HEAD on this checkout. left out: A working copy in a separate worktree is declined (R20); the review reads history with git show, diff and log. R4 replaced by line 80 of references/brief.md
  19. ## You Do Not Dispatch Subagents
  20. Do all of this review yourself.
  21. Never spawn a subagent to review part of the diff, and never spawn another reviewer for a second opinion.
  22. This process already provides every review seat the work gets; a reviewer you spawn duplicates one of them at full cost, and its verdict counts for nothing.
  23. If the diff feels too large for one pass, review it in passes yourself and say so in your report. 5 sentences left out: The rule that the reviewer dispatches no subagents is restated in the reviewer's brief. replaced by line 80 of references/brief.md
  24. ## What to Check
  25. **Plan alignment:**
  26. Does the implementation match the plan / requirements?
  27. Are deviations justified improvements, or problematic departures?
  28. Is all planned functionality present?
  29. **Code quality:**
  30. Clean separation of concerns?
  31. Proper error handling?
  32. Type safety where applicable?
  33. DRY without premature abstraction?
  34. Edge cases handled?
  35. **Architecture:**
  36. Sound design decisions?
  37. Reasonable scalability and performance?
  38. Security concerns?
  39. Integrates cleanly with surrounding code?
  40. **Testing:**
  41. Tests verify real behavior, not mocks?
  42. Edge cases covered?
  43. Integration tests where they matter?
  44. All tests passing?
  45. **Production readiness:**
  46. Migration strategy if schema changed?
  47. Backward compatibility considered?
  48. Documentation complete?
  49. No obvious bugs? 26 sentences left out: What to check duplicates the two axes, the smell baseline, the breakage criteria and the Spec brief's (a) to (f); its security and performance prompts are garden's knowledge.
  50. ## Calibration
  51. Categorize issues by actual severity.
  52. Not everything is Critical.
  53. Acknowledge what was done well before listing issues — accurate praise helps the implementer trust the rest of the feedback.
  54. If you find significant deviations from the plan, flag them specifically so the implementer can confirm whether the deviation was intentional. 5 sentences left out: Severity categories lose to the lens's rungs (contradiction 7) and the praise before issues to no praise (contradiction 10); deviations from the plan are the Spec brief's. R1 replaced by line 82 of references/brief.md
  55. If you find issues with the plan itself rather than the implementation, say so. left out: An issue with the plan itself is a finding at the advisory rung (contradiction 9). R1 replaced by line 76 of references/brief.md
  56. ## Output Format
  57. ### Strengths
  58. [What's well done?
  59. Be specific.]
  60. ### Issues
  61. #### Critical (Must Fix)
  62. [Bugs, security issues, data loss risks, broken functionality]
  63. #### Important (Should Fix)
  64. [Architecture problems, missing features, poor error handling, test gaps]
  65. #### Minor (Nice to Have)
  66. [Code style, optimization opportunities, documentation polish]
  67. For each issue:
  68. File:line reference
  69. What's wrong
  70. Why it matters
  71. How to fix (if not obvious)
  72. ### Recommendations
  73. [Improvements for code quality, architecture, or process]
  74. ### Assessment
  75. **Ready to merge?**
  76. [Yes | No | With fixes]
  77. **Reasoning:** [1-2 sentence technical assessment]
  78. ## Critical Rules
  79. **DO:**
  80. Categorize by actual severity
  81. Be specific (file:line, not vague)
  82. Explain WHY each issue matters
  83. Acknowledge strengths
  84. Give a clear verdict
  85. **DON'T:**
  86. Say "looks good" without checking
  87. Mark nitpicks as Critical
  88. Give feedback on code you didn't actually read
  89. Be vague ("improve error handling")
  90. Avoid giving a clear verdict 35 sentences left out: The output's strengths, its Critical, Important and Minor issues and its merge verdict give way to the report step, the rungs and no praise (contradictions 7 and 10). R1 replaced by line 84 of references/brief.md
  91. ``` **Placeholders:** - `[DESCRIPTION]` — brief summary of what was built - `[PLAN_OR_REQUIREMENTS]` — what it should do (plan file path, task text, or requirements) - `[BASE_SHA]` — starting commit - `[HEAD_SHA]` — ending commit **Reviewer returns:** Strengths, Issues (Critical / Important / Minor), Recommendations, Assessment ## Example Output ```
  92. ### Strengths
  93. Clean database schema with proper migrations (db.ts:15-42)
  94. Comprehensive test coverage (18 tests, all edge cases)
  95. Good error handling with fallbacks (summarizer.ts:85-92)
  96. ### Issues
  97. #### Important
  98. **Missing help text in CLI wrapper**
  99. File: index-conversations:1-31
  100. Issue: No --help flag, users won't discover --concurrency
  101. Fix: Add --help case with usage examples
  102. **Date validation missing**
  103. File: search.ts:25-27
  104. Issue: Invalid dates silently return no results
  105. Fix: Validate ISO format, throw error with example
  106. #### Minor
  107. **Progress indicators**
  108. File: indexer.ts:130
  109. Issue: No "X of Y" counter for long operations
  110. Impact: Users don't know how long to wait
  111. ### Recommendations
  112. Add progress reporting for user experience
  113. Consider config file for excluded projects (portability)
  114. ### Assessment
  115. **Ready to merge: With fixes**
  116. **Reasoning:** Core implementation is solid with good architecture and tests.
  117. Important issues (help text, date validation) are easily fixed and don't affect core functionality.
  118. ``` 28 sentences left out: The placeholders and the example output belong to the dispatch the brief replaces.

Matt Pocock's skills

Matt Pocock's skills, code-review/SKILL.md: 24 of 80 sentences left out
  1. Two-axis review of the diff between `HEAD` and a fixed point the user supplies: left out: The review reads the change's commits found by their trailer; the fixed point to HEAD stays for a range the owner names. replaced by line 7 of references/brief.md
  2. 2 sentences taken
  3. Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings. left out: Both axes as parallel sub-agents give way to the depths: one agent reading both axes, or two one after another, never in parallel. R4 replaced by line 5 of references/greenline.md
  4. The issue tracker should have been provided to you.
  5. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/setup-matt-pocock-skills`. 2 sentences left out: greenline writes no issue-tracker page and installs no setup skill, so the nudge to configure one leaves.
  6. 1 sentence taken
  7. ### 1. Pin the fixed point left out: The first step pins the change's commits, the fixed point staying for a range the owner names. replaced by line 14 of references/brief.md
  8. 7 sentences taken
  9. Look for the originating spec, in this order:
  10. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.), fetched via the workflow in `docs/agents/issue-tracker.md`.
  11. A path the user passed as an argument.
  12. A spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
  13. If nothing is found, ask the user where the spec is.
  14. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available". 6 sentences left out: The spec is the change's acceptance and, when the work splits, its plan directory; the search through an issue tracker and spec directories greenline does not keep stays only as the owner's path or a spec file matching the branch. replaced by line 26 of references/brief.md
  15. 34 sentences taken
  16. ### 4. Spawn both sub-agents in parallel
  17. **Standards sub-agent prompt** should include:
  18. The full diff command and commit list.
  19. 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). 4 sentences left out: Spawning both sub-agents in parallel, and the prompt lists the parent assembled for them, give way to the reviewer reading its own brief after gathering the sources itself in steps 1 to 3. R4 replaced by line 54 of references/brief.md
  20. 4 sentences taken
  21. **Spec sub-agent prompt** should include:
  22. The diff command and commit list.
  23. The path or fetched contents of the spec.
  24. 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.
  25. Quote the spec line for each finding.
  26. Under 400 words." 6 sentences left out: The Spec sub-agent's prompt becomes the Spec brief, with delivery-review's (d), (e) and (f). replaced by line 60 of references/brief.md
  27. If the spec is missing, skip the Spec sub-agent and note this in the final report. left out: A missing spec skips the Spec axis as a limit, never a pass, as the spec step says. replaced by line 26 of references/brief.md
  28. ### 5. Aggregate
  29. Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. 2 sentences left out: The aggregation by the parent gives way to each reviewer's own report under the change's folder, both axes under their headings, and to the builder's judgment. replaced by line 84 of references/brief.md

Cursor's team kit

Cursor's team kit, thermo-nuclear-review/SKILL.md: 46 of 53 sentences left out
  1. # Thermo Nuclear Review
  2. Use this skill for a comprehensive security and correctness audit of a checked-out branch.
  3. ## Prompt
  4. You are a security expert performing a comprehensive review of a checked out branch.
  5. Audit this branch and its changes extremely thoroughly for bugs, changes that break existing features/functionality, and security vulnerabilities.
  6. Be EXTREMELY thorough, rigorous, careful, ambitious, and attentive.
  7. NOTHING can slip through. 7 sentences left out: The title, the security-expert framing and the demand that nothing slip through give way to the bounded pass (contradiction 8); the framing carries no security knowledge. R1 replaced by line 64 of references/brief.md
  8. # Scope
  9. ONLY report issues related to code that is being ADDED or MODIFIED in this PR.
  10. Focus on changes in the diff.
  11. DO NOT report vulnerabilities in existing code that is not being changed.
  12. # Guidelines
  13. ## Breaking Functionality Guidelines 6 sentences left out: Reporting only on added or modified code is the change's commits and the bounded pass; the headings give way to the breakage criteria taken. replaced by line 64 of references/brief.md
  14. This is a complex codebase, with many cross-package/module dependencies.
  15. Often simple code changes in one place have subtle interactions that break functionality elsewhere. 2 sentences left out: The claim that every codebase is complex, with many cross-package dependencies, leaves: it is untrue of a small repository, and the bounded pass already reads what the change breaks outside its own lines.
  16. You MUST be extremely thorough in tracing through possible side effects of the changes. left out: Tracing every side effect loses to the bounded pass, a limit reported rather than explored (contradiction 8). R1 replaced by line 64 of references/brief.md
  17. ## Breaking Devex Guidelines left out: The devex heading gives way to the run of breakage criteria.
  18. It can be easy to break developers' ability to run / build the code locally.
  19. You MUST catch changes that will impact users' developer experience.
  20. Some examples (not exhaustive): 3 sentences left out: The devex rule's MUST and its open-ended examples give way to a condition: a change to how developers run or build the code is a finding citing what a reasonable developer expects, the cases kept as the list. R5 replaced by line 66 of references/brief.md
  21. 7 sentences taken
  22. ## Feature Leak Guidelines left out: The feature-leak heading gives way to the run of breakage criteria.
  23. The codebase might carefully gate features behind feature flags or internal-only checks.
  24. You MUST NOT allow any features that are meant to be behind a feature gate leak.
  25. These leaks are often subtle. 3 sentences left out: The feature-gate MUST becomes a condition: a leak past a gate is a finding citing that gate. R5 replaced by line 72 of references/brief.md
  26. Be VERY careful and thorough. left out: Being very careful and thorough loses to the bounded pass (contradiction 8). R1 replaced by line 64 of references/brief.md
  27. ## Intended Breakage Guidelines left out: The intended-breakage heading gives way to the run of breakage criteria.
  28. If you identify a high risk finding, but the intent of the branch is to introduce that finding – e.g. break some functionality, remove a feature flag, remove a safeguard – AND the scope of the change is well constrained, you SHOULD NOT waste the author's time by reporting the issue to them.
  29. However, if you believe it is likely that they are not aware of the full implications of their change, or you are worried that they are under-weighting the negative impacts (extreme example: a developer pushes a PR titled "Delete the database"), or you are worried that the change is actually malicious, you should still report the finding. 2 sentences left out: An intended effect in a constrained change goes on the set-aside list with its reason rather than unreported, so nothing is set aside silently; an unaware or malicious change is still filed. R5 replaced by line 72 of references/brief.md
  30. ## Over-reporting Guidelines
  31. If you report issues as High priority when they are not in fact high priority / meaningful issues, devs will lose trust in you and stop listening to you over time.
  32. NEVER misreport the priority / importance of issues.
  33. Be extremely thorough in tracing issues end-to-end to gain complete, and total confidence before reporting. 4 sentences left out: Misreporting priority is the lens's rung discipline, the number being citation strength; end-to-end tracing loses to the bounded pass. replaced by line 82 of references/brief.md
  34. # Final Response
  35. IF you have medium-to-high priority / risk findings, and there is a PR for this branch, then check the PR/MR discussion using gh/glab cli to see if there are comments from BugBot or others present.
  36. If so, take their findings into account.
  37. If they found issues you missed, evaluate them to determine if they are valid and include them in your report.
  38. If they found some of the same issues you did, see if there is anything from their findings that are worth incorporating into your response.
  39. Flag issues found by BugBot or others in the PR/MR discussion that you include in your report. 6 sentences left out: Reading BugBot's comments in the PR discussion through gh or glab is dropped (R21); the change's own review reports are what a reviewer reads after its pass. R1 replaced by line 74 of references/brief.md
  40. # Critical Rules
  41. NEVER present issues with unfinished research.
  42. E.g. Never say something like, "The client has issue X, but if handled in the backend then this is ok."
  43. if you have access to the backend code and can check for yourself. 4 sentences left out: Finishing the research before reporting is refuting before filing, which the bounded pass names. replaced by line 64 of references/brief.md
  44. You MUST wait to check the PR/MR discussion until AFTER you have performed your audit.
  45. This way you have fresh eyes while you review. 2 sentences left out: Waiting for one's own pass before reading other findings is restated for the change's review reports in place of the PR discussion. R1 replaced by line 74 of references/brief.md
  46. Be EXTREMELY thorough, rigorous, careful, ambitious, and attentive.
  47. NOTHING can slip through. 2 sentences left out: The repeated demand that nothing slip through loses to the bounded pass (contradiction 8). R1 replaced by line 64 of references/brief.md

Dietrich Gebert's Ponytail

Dietrich Gebert's Ponytail, ponytail-review/SKILL.md: 2 of 37 sentences left out
  1. Route them to a normal review pass, not this one. left out: Correctness, security and performance are the two axes', as the lens's opening says. replaced by line 1 of references/excess.md
  2. 2 sentences taken
  3. "stop ponytail-review" or "normal mode": revert to verbose review style. left out: greenline has no verbose review mode to revert to.
Dietrich Gebert's Ponytail, ponytail-audit/SKILL.md: 26 of 29 sentences left out
  1. ponytail-review, repo-wide.
  2. Scan the whole tree instead of a diff. 2 sentences left out: The audit's whole-tree scan does not enter: the excess lens reads the change's commits; its hunt and its ranking do.
  3. Rank findings biggest cut first. left out: The ranking, biggest cut first, is written after the hunt. replaced by line 32 of references/excess.md
  4. ## Tags
  5. Same as ponytail-review:
  6. `delete:` dead code, unused flexibility, speculative feature.
  7. Replacement: nothing.
  8. `stdlib:` hand-rolled thing the standard library ships.
  9. Name the function.
  10. `native:` dependency or code doing what the platform already does.
  11. Name the feature.
  12. `reuse:` equivalent helper, util, or pattern already in this repo.
  13. Name the path.
  14. `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
  15. `shrink:` same logic, fewer lines.
  16. Show the shorter form. 13 sentences left out: The tags duplicate ponytail-review's, which are taken.
  17. 3 sentences taken
  18. ## Output
  19. One line per finding, numbered and ranked: `<N>. <tag> <what to cut>. <replacement>. [path]`, so the user can say "fix 2 and 5".
  20. End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.` 3 sentences left out: The output duplicates ponytail-review's format and scoring, with the ranking written after the hunt. replaced by line 32 of references/excess.md
  21. ## Boundaries
  22. Scope: over-engineering and complexity only.
  23. Correctness bugs, security holes, and performance are explicitly out of scope.
  24. Route them to a normal review pass.
  25. Lists findings, applies nothing.
  26. One-shot.
  27. "stop ponytail-audit" or "normal mode" to revert. 7 sentences left out: The boundaries duplicate ponytail-review's, and greenline has no audit mode to revert from.

The ledger entry

greenline's ledger logs how each skill was made and changed, with a reason for each entry.

2026-10-19 2026-10-19-review-front-and-references

Review's depths and mechanics move from its front to its references

The front keeps the upstream prose; its depth bullets, now naming the three modes, and its paths, commands and record forms move to references/greenline.md (J-93 S2).

Authorised by
2026-10-18 The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours"; and J-93 S2's finalise words of 2026-10-19, "Fast route, merged slices, parallel jobs (Recommended)": a skill's front is the upstream prose its recipe cuts, and its mechanics, where its work lands, its section's form, its depths at each mode and its commands, stand on its references page
Pages it touched
SKILL.md, references/brief.md, references/greenline.md, references/reviewers.md
Rulings, R1 to R31
  1. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's; The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's
  2. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's; The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's rulings of 2026-10-04, "cool then lock everything in": a step runs at the depth the change's mode gives it, inline being one line of its section, written a section the builder writes, independent a fresh agent's report the record cites and looped that pass repeated until clean up to the mode's rounds, clean for review meaning no finding at a blocking rung and for verify every item verified, and a step's handoff names the next step of the change's mode; The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", with the delegation of 2026-10-16 whose words finalise the fix job's slices: every check of a change's code, a reviewer's and a verifier's included, runs through greenline check, a plain test command proving nothing to the record; a recorded check fact is never removed or edited, a probe recorded by mistake being marked with greenline check --probe; the close writes its terms and decisions before the checks' last run and ends with greenline tidy in every mode; the change's first commit carries its record; and verify's baseline runs on a copy, never over the change's working tree; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  3. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's rulings of 2026-10-04, "cool then lock everything in": a step runs at the depth the change's mode gives it, inline being one line of its section, written a section the builder writes, independent a fresh agent's report the record cites and looped that pass repeated until clean up to the mode's rounds, clean for review meaning no finding at a blocking rung and for verify every item verified, and a step's handoff names the next step of the change's mode; The operator's cards of 2026-10-14 on part 3 of the-whole-change, each "Rule as proposed": one agent at a time through the harness's delegation, in the change's one checkout and never a worktree; one brief for every fresh agent, the change's front matter, its acceptance, its id, the path of its report and the skill it works by, then the step's extras, and no fresh agent delegates; every fresh agent's report is <step>-<n>.md in the change's folder; the fix rounds are per step, and a fix after verify is not reviewed again outside a loop without the owner's word; verify's verdicts stand as the agent gave them; and where the harness has no delegation the block's fallback runs every depth above written; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link; The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", with the delegation of 2026-10-16 whose words finalise the fix job's slices: every check of a change's code, a reviewer's and a verifier's included, runs through greenline check, a plain test command proving nothing to the record; a recorded check fact is never removed or edited, a probe recorded by mistake being marked with greenline check --probe; the close writes its terms and decisions before the checks' last run and ends with greenline tidy in every mode; the change's first commit carries its record; and verify's baseline runs on a copy, never over the change's working tree; The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", and the card of that day, "Words at the list edit the entry; at a ticket's open they override", with the delegation of 2026-10-16 whose words finalise the fix job's slices: a request that names a mode is taken as chosen and goes on with no yes awaited, a question asked only for a choice it leaves open; the record names every floor found and, where the owner names a mode below one, says so with choice owner and the floor's reason; a mode named at the ticket list edits the entry and one named at a ticket's open overrides it; the builder reads the reviewer's brief at the inline depth only; and at the written frame depth every open behaviour goes to the owner through the interview, an inline frame line crediting the owner only with the owner's answers; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices, with the ruling of 2026-10-18 that the close is a skill step: a reviewer's or verifier's brief is written by greenline brief from the record into the change's folder, its first line the command's mark, and never by the builder, which starts the agent with its path and never opens, copies, diffs or derives a brief file; status reports a brief file the command did not write; and the close cites each brief the command wrote, from the status listing; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices: a fresh agent's brief names the agent's own scratch folder by its absolute path and says the host's temporary directory is never used, a working file there a finding, and greenline check run with the brief's --step and --round sets TMPDIR to that folder for the command it records; the record names each fresh agent started with its step and number, a restart one more line and one more count, and greenline status reports a cost below the starts the record names as a finding the close clears before done; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  4. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's ruling R20 of 2026-10-07, "greenline should not support parralel subs right now at all .. only linear sub flow ..and not worktrees also": a method about parallel dispatch or worktree isolation is declined
  5. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link
  6. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's; The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link
  7. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's ruling R20 of 2026-10-07, "greenline should not support parralel subs right now at all .. only linear sub flow ..and not worktrees also": a method about parallel dispatch or worktree isolation is declined; The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", with the delegation of 2026-10-16 whose words finalise the fix job's slices: every check of a change's code, a reviewer's and a verifier's included, runs through greenline check, a plain test command proving nothing to the record; a recorded check fact is never removed or edited, a probe recorded by mistake being marked with greenline check --probe; the close writes its terms and decisions before the checks' last run and ends with greenline tidy in every mode; the change's first commit carries its record; and verify's baseline runs on a copy, never over the change's working tree; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices: a fresh agent's brief names the agent's own scratch folder by its absolute path and says the host's temporary directory is never used, a working file there a finding, and greenline check run with the brief's --step and --round sets TMPDIR to that folder for the command it records; the record names each fresh agent started with its step and number, a restart one more line and one more count, and greenline status reports a cost below the starts the record names as a finding the close clears before done; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  8. The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", with the delegation of 2026-10-16 whose words finalise the fix job's slices: every check of a change's code, a reviewer's and a verifier's included, runs through greenline check, a plain test command proving nothing to the record; a recorded check fact is never removed or edited, a probe recorded by mistake being marked with greenline check --probe; the close writes its terms and decisions before the checks' last run and ends with greenline tidy in every mode; the change's first commit carries its record; and verify's baseline runs on a copy, never over the change's working tree; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices: a fresh agent's brief names the agent's own scratch folder by its absolute path and says the host's temporary directory is never used, a working file there a finding, and greenline check run with the brief's --step and --round sets TMPDIR to that folder for the command it records; the record names each fresh agent started with its step and number, a restart one more line and one more count, and greenline status reports a cost below the starts the record names as a finding the close clears before done; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  9. practice-without-guidance-2026-09-26, the old chain's native entry written for the split of 2026-09-26, under docs/DECISIONS.md's row of 2026-09-26, the operator's word of the decoupling: the guidance and its publication are garden's, reached only through the optional garden connector; The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": the roster table's names stand, review and verify among them, and control-cli and control-ui become reference files of verify; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link
  10. practice-without-guidance-2026-09-26, the old chain's native entry written for the split of 2026-09-26, under docs/DECISIONS.md's row of 2026-09-26, the operator's word of the decoupling: the guidance and its publication are garden's, reached only through the optional garden connector; The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": the roster table's names stand, review and verify among them, and control-cli and control-ui become reference files of verify
  11. The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link
  12. The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  13. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's ruling R20 of 2026-10-07, "greenline should not support parralel subs right now at all .. only linear sub flow ..and not worktrees also": a method about parallel dispatch or worktree isolation is declined; The operator's cards of 2026-10-14 on part 3 of the-whole-change, each "Rule as proposed": one agent at a time through the harness's delegation, in the change's one checkout and never a worktree; one brief for every fresh agent, the change's front matter, its acceptance, its id, the path of its report and the skill it works by, then the step's extras, and no fresh agent delegates; every fresh agent's report is <step>-<n>.md in the change's folder; the fix rounds are per step, and a fix after verify is not reviewed again outside a loop without the owner's word; verify's verdicts stand as the agent gave them; and where the harness has no delegation the block's fallback runs every depth above written; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices, with the ruling of 2026-10-18 that the close is a skill step: a reviewer's or verifier's brief is written by greenline brief from the record into the change's folder, its first line the command's mark, and never by the builder, which starts the agent with its path and never opens, copies, diffs or derives a brief file; status reports a brief file the command did not write; and the close cites each brief the command wrote, from the status listing; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  14. The operator's words of 2026-10-18 on the redesign (N-56), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and "we need only three modes I guess, quick, regular, careful ... Either way it needs to maintain artefacts for audit .. but we can change the spine for each"; and J-93's finalise words of 2026-10-18, "Finalise all six now; S1 opens after J-92 (Recommended); quick, regular, careful (Recommended); The builder's written verify, no fresh verifier (Recommended)": a step's mechanics, where its work lands, its section's form and its commands, live in its references page, each sentence moved from the block under the ruling that first placed it there; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  15. The operator's words of 2026-10-18 on the redesign (N-56), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and "we need only three modes I guess, quick, regular, careful ... Either way it needs to maintain artefacts for audit .. but we can change the spine for each"; and J-93's finalise words of 2026-10-18, "Finalise all six now; S1 opens after J-92 (Recommended); quick, regular, careful (Recommended); The builder's written verify, no fresh verifier (Recommended)": a step's mechanics, where its work lands, its section's form and its commands, live in its references page, each sentence moved from the block under the ruling that first placed it there; The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": the roster table's names stand, review and verify among them, and control-cli and control-ui become reference files of verify; The operator's rulings of 2026-10-04, "cool then lock everything in": a step runs at the depth the change's mode gives it, inline being one line of its section, written a section the builder writes, independent a fresh agent's report the record cites and looped that pass repeated until clean up to the mode's rounds, clean for review meaning no finding at a blocking rung and for verify every item verified, and a step's handoff names the next step of the change's mode; The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's cards of 2026-10-14 on part 3 of the-whole-change, each "Rule as proposed": one agent at a time through the harness's delegation, in the change's one checkout and never a worktree; one brief for every fresh agent, the change's front matter, its acceptance, its id, the path of its report and the skill it works by, then the step's extras, and no fresh agent delegates; every fresh agent's report is <step>-<n>.md in the change's folder; the fix rounds are per step, and a fix after verify is not reviewed again outside a loop without the owner's word; verify's verdicts stand as the agent gave them; and where the harness has no delegation the block's fallback runs every depth above written; The operator's card answers of 2026-10-12 on the first evaluation's brief, "The roster after the cut": review's reviewer's brief is a page of its own, references/brief.md, read whole by the reviewer and by the builder only at the inline depth; the brief's imported breakage block becomes conditions, its claim about every codebase dropped and an intended effect put on the set-aside list rather than left unreported; the workshop's notes leave the installed lens; the repository overrides the excess lens, and a MUST KILL that cites no rule is rung 3; the review section is a table with the bucket a column; and the reviewers page loses its leftovers and gains the builder's link; The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", and the card of that day, "Words at the list edit the entry; at a ticket's open they override", with the delegation of 2026-10-16 whose words finalise the fix job's slices: a request that names a mode is taken as chosen and goes on with no yes awaited, a question asked only for a choice it leaves open; the record names every floor found and, where the owner names a mode below one, says so with choice owner and the floor's reason; a mode named at the ticket list edits the entry and one named at a ticket's open overrides it; the builder reads the reviewer's brief at the inline depth only; and at the written frame depth every open behaviour goes to the owner through the interview, an inline frame line crediting the owner only with the owner's answers; The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices, with the ruling of 2026-10-18 that the close is a skill step: a reviewer's or verifier's brief is written by greenline brief from the record into the change's folder, its first line the command's mark, and never by the builder, which starts the agent with its path and never opens, copies, diffs or derives a brief file; status reports a brief file the command did not write; and the close cites each brief the command wrote, from the status listing; The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours": a skill's front is the upstream prose its recipe cuts, and greenline's mechanics, where the step's work lands, its section's form, its commands and its depths at each mode, stand on its references page (J-93 S2)
  16. The operator's words of 2026-10-18 on the redesign (N-56), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and "we need only three modes I guess, quick, regular, careful ... Either way it needs to maintain artefacts for audit .. but we can change the spine for each"; and J-93's finalise words of 2026-10-18, "Finalise all six now; S1 opens after J-92 (Recommended); quick, regular, careful (Recommended); The builder's written verify, no fresh verifier (Recommended)": a step's mechanics, where its work lands, its section's form and its commands, live in its references page, each sentence moved from the block under the ruling that first placed it there
  17. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's; The operator's ruling R20 of 2026-10-07, "greenline should not support parralel subs right now at all .. only linear sub flow ..and not worktrees also": a method about parallel dispatch or worktree isolation is declined; The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's
  18. The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": the roster table's names stand, review and verify among them, and control-cli and control-ui become reference files of verify
  19. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): interrogate, thermo-nuclear-review, requesting-code-review, receiving-code-review, ponytail-audit and no-comments combine into review, and the contradictions stand as recommended: the reports keep each finding as written and the builder's judgment filters and decides (contradiction 6), severity is review-lens's rungs (7), the pass stays bounded (8), an issue with the plan itself is a finding at the advisory rung (9) and the reviewer does not praise the code (10); within pstack, premature abstraction being worse than duplication wins over its helper-extraction line; ponytail-audit's whole-tree grep enters the excess lens as a default correction of grep every caller; thermo-nuclear-code-quality-review, review-and-ship and deslop stay declined, and code-review-and-quality is garden's
  20. The operator's ruling R21 of 2026-10-08 on orchestration ("orchestration related skills ... have be re thought in to being usable on all harnesses") and the R3 ruling of that day, "yes go ahead", on the portable forms: review's independent reviewers run one after another, each a fresh agent started through the harness's delegation where the mode spends one, inline by the builder at fast, with no parallel axes and no forked turns; interrogate's single-message dispatch, model table and model diversity are dropped; thermo-nuclear-review's BugBot step is dropped, the change's own review reports being what a reviewer reads after its own pass; requesting-code-review's template becomes the brief the review step's agent reads, its dispatch syntax and worktree option dropped; no-comments' agent file becomes a reference passage the excess lens reads, with no agent of its own and its persona voice dropped; browser-testing-with-devtools' security core is restated for any browser an agent drives, its DevTools setup garden's
  21. The operator's ruling R20 of 2026-10-07, "greenline should not support parralel subs right now at all .. only linear sub flow ..and not worktrees also": a method about parallel dispatch or worktree isolation is declined
  22. The operator's rulings of 2026-10-04, "cool then lock everything in": a step runs at the depth the change's mode gives it, inline being one line of its section, written a section the builder writes, independent a fresh agent's report the record cites and looped that pass repeated until clean up to the mode's rounds, clean for review meaning no finding at a blocking rung and for verify every item verified, and a step's handoff names the next step of the change's mode
  23. practice-without-guidance-2026-09-26, the old chain's native entry written for the split of 2026-09-26, under docs/DECISIONS.md's row of 2026-09-26, the operator's word of the decoupling: the guidance and its publication are garden's, reached only through the optional garden connector
  24. J-59, on the operator's words of 2026-10-09 ('okay then implement all of this'): a gist of at most twelve words on every account whose reason is stated; no text, measure or method changes
  25. R44 of 2026-10-11, "S6, right after S5, same worker, normal route", and the ruling made that day under the operator's delegation ("i want you to finish implementing them from here and out"): review's "Start the reviewers" moves to references/reviewers.md, its "Judge the findings" staying because "Act on them" names its buckets at any depth with a fix round
  26. The operator's cards of 2026-10-14 on part 3 of the-whole-change, each "Rule as proposed": one agent at a time through the harness's delegation, in the change's one checkout and never a worktree; one brief for every fresh agent, the change's front matter, its acceptance, its id, the path of its report and the skill it works by, then the step's extras, and no fresh agent delegates; every fresh agent's report is <step>-<n>.md in the change's folder; the fix rounds are per step, and a fix after verify is not reviewed again outside a loop without the owner's word; verify's verdicts stand as the agent gave them; and where the harness has no delegation the block's fallback runs every depth above written
  27. The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", with the delegation of 2026-10-16 whose words finalise the fix job's slices: every check of a change's code, a reviewer's and a verifier's included, runs through greenline check, a plain test command proving nothing to the record; a recorded check fact is never removed or edited, a probe recorded by mistake being marked with greenline check --probe; the close writes its terms and decisions before the checks' last run and ends with greenline tidy in every mode; the change's first commit carries its record; and verify's baseline runs on a copy, never over the change's working tree
  28. The operator's card of 2026-10-15 on the QA series, "One fix job after the fifth family", and the card of that day, "Words at the list edit the entry; at a ticket's open they override", with the delegation of 2026-10-16 whose words finalise the fix job's slices: a request that names a mode is taken as chosen and goes on with no yes awaited, a question asked only for a choice it leaves open; the record names every floor found and, where the owner names a mode below one, says so with choice owner and the floor's reason; a mode named at the ticket list edits the entry and one named at a ticket's open overrides it; the builder reads the reviewer's brief at the inline depth only; and at the written frame depth every open behaviour goes to the owner through the interview, an inline frame line crediting the owner only with the owner's answers
  29. The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices, with the ruling of 2026-10-18 that the close is a skill step: a reviewer's or verifier's brief is written by greenline brief from the record into the change's folder, its first line the command's mark, and never by the builder, which starts the agent with its path and never opens, copies, diffs or derives a brief file; status reports a brief file the command did not write; and the close cites each brief the command wrote, from the status listing
  30. The operator's delegation of 2026-10-16, renewed on 2026-10-18 for the fix job after the Linear clone, whose words finalise its slices: a fresh agent's brief names the agent's own scratch folder by its absolute path and says the host's temporary directory is never used, a working file there a finding, and greenline check run with the brief's --step and --round sets TMPDIR to that folder for the command it records; the record names each fresh agent started with its step and number, a restart one more line and one more count, and greenline status reports a cost below the starts the record names as a finding the close clears before done
  31. The operator's words of 2026-10-18 on the redesign (N-56, items 2 and 7), "we need the upstream prose upfront and references hold how to work meaning the artefacts etc" and, on the ingest procedures, "we wanna have there prose .. what we don't wanna have is there artefact system and fit them to use ours"; and J-93 S2's finalise words of 2026-10-19, "Fast route, merged slices, parallel jobs (Recommended)": a skill's front is the upstream prose its recipe cuts, and its mechanics, where its work lands, its section's form, its depths at each mode and its commands, stand on its references page
11 earlier entries

  1. 2026-10-19 2026-10-19-review-references

    Review's mechanics, fresh agents included, move to its references page

    Pages it touched: references/greenline.md

  2. 2026-10-18 2026-10-18-review-names-the-scratch-folder

    A fresh reviewer works in its own scratch folder

    Pages it touched: references/brief.md

  3. 2026-10-18 2026-10-18-review-brief-written-by-the-command

    Each reviewer's brief is a file greenline brief writes, never the builder

    Pages it touched: SKILL.md, references/brief.md, references/reviewers.md

  4. 2026-10-17 2026-10-17-review-brief-read-at-inline-only

    The builder reads the reviewer's brief only at the inline depth

    Pages it touched: SKILL.md, references/brief.md

  5. 2026-10-17 2026-10-17-review-checks-through-greenline-check

    A reviewer's checks run through greenline check; probes run plainly

    Pages it touched: SKILL.md, references/brief.md

  6. 2026-10-14 2026-10-14-review-brief-on-its-own-page

    The reviewer's brief gets its own page; review's leftovers cured

    Pages it touched: SKILL.md, references/brief.md, references/excess.md, references/lens.md, references/reviewers.md

  7. 2026-10-14 2026-10-14-review-one-brief

    Each reviewer gets the one brief and its numbered report

    Pages it touched: SKILL.md, references/reviewers.md

  8. 2026-10-11 2026-10-11-review-reviewers

    Starting the reviewers moves to a page the deeper depths read

    Pages it touched: SKILL.md, references/reviewers.md

  9. 2026-10-09 2026-10-09-review-gists

    Every account gets a short gist for the website

  10. 2026-10-09 2026-10-09-review-session-writer

    The builder is the session holding the change

    Pages it touched: SKILL.md

  11. 2026-10-08 2026-10-08-review-recipe

    Review is made on delivery-review's two axes, reviewers one at a time

    Pages it touched: SKILL.md, references/REGISTER.md, references/excess.md, references/lens.md