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

build

about 2,500 tokens

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

  • 2 files
  • 2 edits
  • 234 sentences left out
  • 4 sources
  • last changed 2026-10-21
  • step 4 of 7

Replaces implement (retired 2026-10-08).

The text

SKILL.md

about 1,600 tokens
  • Addy Osmani's agent-skills
  • pstack
  • Jesse Vincent's Superpowers
  • greenline

---

name: "build"

description: "Turn a change's plan into working code one slice at a time, each slice tested, verified and committed with the change's trailer and the build green between slices, every command's output compared with what the plan expected and every deviation recorded, at the depth the change's mode gives the build step. Use when the mode reaches build, or when the owner asks to build a ready ticket or to make a small settled fix."

---

greenlineOpens build: one slice at a time; the builder runs every task

# Build

Build turns a change's plan into working code, one slice at a time, each slice tested, verified and committed before the next. It runs where the change's mode reaches the build step, at the depth the mode gives it, and alone when the owner asks to build a ready ticket, which opens its own change record under the mode approved with the ticket list, or to make a small settled fix, which opens its own change record under the mode the owner accepts. It reads the change record's plan section first, or its frame section where the mode skipped the plan, and for a ticket its entry in the plan directory's tickets file and the planning change's plan section. The builder runs every task itself, one after another, and no agent runs beside the conversation. A consequential choice the plan leaves open, a product or a contract choice, returns to the owner rather than being decided during the build. It never reviews its own result or verifies the change's claim: those are the review and verify steps'.

greenlineHeads the spine's increment cycle

## The slices

greenlineTies the sources' words once; a plan's step is not a mode's

In what follows a task is the plan's, a ticket's work or one task of a change's plan section; a slice, an increment or a unit is one tested and committed piece of a task; and a step is one of the task's steps as the plan lists them, not a step of the change's mode.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

Build in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

For each slice:

1. **Implement** the smallest complete piece of functionality

2. **Test** — run the test suite (or write a test if none exists)

3. **Verify** — confirm the slice works as expected (tests pass, build succeeds, manual check)

greenlineCommit each slice; its branch and trailer are the references page's

4. **Commit** -- save your progress with a descriptive message

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

5. **Move to the next slice** — carry forward, don't restart

greenlineKeeps implement's pointer to tdd, at the seams the plan agreed

Use tdd where possible, at pre-agreed seams.

pstackprinciple-sequence-verifiable-units/SKILL.md

**Execution.** In a sweep, migration, or any run of similar edits, verify each change before starting the next. Each unit is a before/after bracket: known-good state, one change, run the check, then proceed.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

## Implementation Rules

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

### Rule 0: Scope Discipline

Touch only what the task requires.

Do NOT:

- "Clean up" code adjacent to your change

- Refactor imports in files you're not modifying

- Remove comments you don't fully understand

- Add features not in the spec because they "seem useful"

- Modernize syntax in files you're only reading

If you notice something worth improving outside your task scope, note it — don't fix it, and list it in the build section.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

### Rule 1: One Thing at a Time

Each increment changes one logical thing. Don't mix concerns:

**Bad:** One commit that adds a new component, refactors an existing one, and updates the build config.

**Good:** Three separate commits — one for each change.

pstackprinciple-sequence-verifiable-units/SKILL.mdgreenlineBuild stacks commits; the pull request waits for close's landingpstackprinciple-sequence-verifiable-units/SKILL.md

**Delivery.** Stack commits in the order that proves the work. The canonical shape is the failing test first, then the fix on top. Other story orders are a subtraction before the reshape, a baseline capture before the treatment, the scaffold before the feature. Each commit lands on its own and the sequence reads as an argument.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

### Rule 2: Keep It Compilable

After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

## Increment Checklist

greenlineVerifies each increment with the repository's own commands, not an absent skill

After each increment, verify with the repository's own commands:

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

- [ ] The change does one thing and does it completely

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

- [ ] All existing tests still pass (the repository's test command: `npm test`, `./gradlew test`, `pytest`, ...)

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

- [ ] The build succeeds (the repository's build command)

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

- [ ] Type checking passes, where the stack has one (`npx tsc --noEmit`, `mypy`, ...)

Addy Osmani's agent-skillsincremental-implementation/SKILL.md

- [ ] Linting passes (the repository's lint command)

- [ ] The new functionality works as expected

- [ ] The change is committed with a descriptive message

**Note:** Run each verification command after a change that could affect it. After a successful run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no information.

greenlineCompares step output with the plan; the spec is spec.md or frame

## Against the plan

In what follows the spec is the plan directory's spec, or, for a change that stands alone, its frame section with its acceptance criteria. Where the plan states what a step's command should show, run the command, read its output, and compare. Three outcomes:

Jesse Vincent's Superpowersexecuting-plans/SKILL.md

- **Matches.** Next step.

- **The code is wrong.** Find the cause; never patch the symptom to make the step's output match.

Jesse Vincent's Superpowersexecuting-plans/SKILL.mdgreenlineThe builder rules only spec-settled defects; other choices return to the owner

- **The plan is wrong** — a step contradicts the spec, an interface from an earlier task doesn't match what this task consumes, a command that cannot work. Rule on the smallest change that satisfies the spec, record it in the build section as a deviation, with what you decided and why, and continue; a choice the spec does not settle, a product or a contract choice, returns to the owner instead. The ruling is carried, not remembered: later tasks that touch the same interface read it from the build section.

greenlineDone means tests read, the final run recorded, deviations recorded

## The completion contract

Before a task is called done, all of the following are true, with evidence in this session, not inferred from the diff looking right:

- Every test the task names exists and ran in this task, and you read the output.

- The final test run for the task passed, recorded as a check of the change, as build's references page says.

- Every result the plan said a step's command should show was compared against real output.

- Every deviation from the plan is in the build section, with what you decided and why.

Jesse Vincent's Superpowersexecuting-plans/SKILL.md

If any item is missing, the task is not complete: finish it.

greenlineThe handoff lists the build's outputs and names the mode's next step

## Handoff

Consumes: the change record's plan section in .greenline/ledger/<id>.md, or its frame section where the mode skipped the plan; for a ticket, its entry in the plan directory's tickets.md and the planning change's plan section Produces: the commits on the change's branch, each carrying the trailer Greenline-Change: <id>; the checks greenline check records under .greenline/ledger/<id>/checks/; the build section of .greenline/ledger/<id>.md, one line at the inline depth, and at the written depth what was built with the deviations from the plan, the approaches tried and dropped, and what was noticed and left alone Next: the next step of the change's mode

SKILL.md as installed, byte for byte SHA-256 57bce6a58326f2adab398ffc36fd799d0c2904575c245ad5f67438e99e8d556a

references/greenline.md

about 920 tokens
  • greenline
greenlineOpens build's mechanics page: its depths, checks and commits

# Build: the practice's mechanics

This page holds build at each mode's depth and where its work lands: the section, the checks it runs, the commits it makes and the files it writes on the way. Read it with `SKILL.md` when the mode reaches build, and when AGENTS.md's index sends you here.

greenlineQuick writes one line; written records slices, deviations and dropped approaches

## The depths

- **Inline, at quick.** Build the change by `SKILL.md`'s slices, and write the change record's build section, in `.greenline/ledger/<id>.md`, as one line: what was built and the check that shows it, with any deviation from the plan.

- **Written, at regular and careful.** Build the change by `SKILL.md`'s slices, and write the build section: what was built, slice by slice; each deviation from the plan, with what you decided and why; each approach tried and dropped, with what dropped it; and what was noticed outside the task and left alone.

greenlineEvery check recorded through greenline check; only a probe runs plainly

## Checks

Every check runs through `greenline check`, its red runs included; a probe, a run whose green the change never claims, runs outside it, as the verify skill says. A recorded check fact is never removed or edited: a rerun records a new one, and a probe recorded by mistake is marked with `greenline check --change <id> --probe <fact>`. Every file written on the way and not part of the change, a probe, a scratch script or a before-and-after copy, yours or a fresh agent's, goes under `.greenline/tmp/<id>/`, never the host's temporary directory, and a check's facts cite paths inside the repository.

Run each of `SKILL.md`'s increment checks, and the completion contract's final test run, through `greenline check -- <command>`, its red runs included, so the change's checks record it: the short form takes the open change and the step its record is in, and names that step beside the facts, so give `--change <id> --step <step>` where it names another. A run of the change's code you make only to read, a failing test's detail or a quick look after an edit, is a check too: `greenline check -- node --test --test-name-pattern=<name> <file>` records it, and its output shows as it runs, so read the detail there. Each such command is a check of its own: once its cause is fixed, run it again green, since `done` waits on the latest run of every check. The one run left plain is a probe, a run whose green the change never claims: a baseline at an earlier commit, a mutation run, a negative control. `greenline status --change <id>` counts the commits since the last recorded check, and a count above zero is code committed since that no recorded check saw.

greenlineCommits on the change's branch, each with its trailer, never rewritten

## Commits

Each slice's commit goes on the change's branch, the one its proposal named or, for a ticket, the planning change's, never another change's, and the change's first commit carries its record, `.greenline/ledger/<id>.md`, since `greenline status` reads history only from the commit where the first change record entered. Every commit carries the trailer `Greenline-Change: <id>` from the moment it is made, as the last line of the message's last paragraph, one block with any trailer the harness adds there, such as `Co-Authored-By`; no commit, an unpushed one included, is reset, amended, rebuilt or rewritten with `filter-branch` to move it. A trailer-shaped line of another key, such as `Related-Change: <id>`, put in a message after a hook refuses it is not an answer to the refusal: report the refusal to the owner and ask. Generated code follows its generator; vendored contributions follow their upstream's contract.

greenlineA secret is checked for presence, never printed

## Secrets and guidance

Protect secrets and keep guidance bodies in tool output, never in a local library or task compilation; a key or a variable that may hold one is checked for presence, never printed, even while diagnosing.

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 1 scope SKILL.md:30

    Upstream: ### Rule 0.5: Scope Discipline

    Shipped: ### Rule 0: Scope Discipline

    Rule 0 is ponytail's now, so the next rule takes its number

    Full reason

    Rule 0, simplicity first, is the ponytail habit's and leaves, so scope discipline is the first rule this skill keeps.

1 smaller edit

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

  1. Edit 2 relocate SKILL.md:41

    Upstream: If you notice something worth improving outside your task scope, note it — don't fix it:

    Shipped: If you notice something worth improving outside your task scope, note it — don't fix it, and list it in the build section.

    What was noticed and left alone is listed in the build section

    Full reason

    What was noticed and not touched is listed in the change record's build section, in place of upstream's example note.

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 build produces, where it runs (the step of the change's mode, at that mode's depth) and the direct ask it keeps from implement, a ready ticket, what it reads first, that the builder runs every task itself, that an open product or contract choice returns to the owner as implement said, and that review and verification are other steps'; it replaces implement's scope paragraph and the overviews of the three sources. Since J-93 S2 it names the tickets file by its noun.

  2. SKILL.md:10 scope

    The heading of the spine's increment cycle, over its overview and its numbered cycle.

  3. SKILL.md:12 rename

    The spine says slice and increment, principle-sequence-verifiable-units unit and executing-plans task and step for the plan's own parts; this line ties the words once rather than editing every sentence (C13), and keeps the plan's step apart from a step of the mode.

  4. SKILL.md:21 pointer

    Upstream's commit step without its pointer to a git workflow skill no install carries; where each commit goes and what it carries stand on build's references page since J-93 S2.

    Credits: Addy Osmani's agent-skills

  5. SKILL.md:24 rename

    implement's pointer to the tdd skill, kept as greenline's line under R22, its bare roster name in prose as implement had it; the seams are the ones the plan agreed.

    Credits: Matt Pocock's skills

  6. SKILL.md:51 method

    Build stacks commits only: the pull request is the landing the close step offers once, on the owner's word, never one opened per piece during the build; upstream's sentence also stacked pull requests. R1

    Credits: pstack

  7. SKILL.md:59 pointer

    Upstream's pointer to a test-driven-development skill's section names a skill no install carries; the repository's own commands are the ones the checklist names.

    Credits: Addy Osmani's agent-skills

  8. SKILL.md:71 relocate

    The bridge into executing-plans' three outcomes: its plan's Expected lines become what the plan states a step's command should show, and its spec is the plan directory's or, for a change that stands alone, the frame section with its acceptance criteria. Since J-93 S2 it names the spec by its noun.

    Credits: Jesse Vincent's Superpowers

  9. SKILL.md:80 method

    executing-plans rules every plan defect itself and keeps the ruling in its ledger; the build section holds it, and only a defect the spec already settles is the builder's, a product or contract choice returning to the owner as implement said (contradiction 5). R2

    Credits: Jesse Vincent's Superpowers

  10. SKILL.md:82 method

    executing-plans' completion contract, its brief, ledger line and task-done script named for greenline's homes: the task's tests, the final run recorded as a check of the change, the plan's expected results, and every deviation in the build section; its pointer to a verification skill no install carries leaves, the verify step being the claim's. The recorder's command stands on the references page since J-93 S2. R3

    Credits: Jesse Vincent's Superpowers

  11. SKILL.md:93 method

    implement's handoff lines kept as greenline's under R22, naming what the build reads and writes in the change record and the branch its commits go to; a step skill's Next names the next step of the change's mode, never a fixed skill, where implement named delivery-review and record-architecture-decisions. R4

  12. references/greenline.md:1 method

    Build's references page opens: build at each mode's depth and where its work lands, which the block's sentences and, since J-93 S2, the front's depth bullets, its commit step's homes and its checklist's recorder moved here. R5

  13. references/greenline.md:5 method

    Build's depths at each mode and what its section holds: quick's one line of what was built and its check, the written section's slices, deviations, dropped approaches and what was left alone; moved from the front's depth bullets by J-93 S2. R6

  14. references/greenline.md:10 method

    Build's references page: every check recorded through greenline check, the short form and its flags, a run made to read named a check, the plain run a probe alone, and status's count of commits since the last recorded check; scratch under the change's working folder. The checklist's recorder moved here from the front by J-93 S2. The probe's mark and the fact never edited are stated once. R7

  15. references/greenline.md:16 method

    Build's references page: each slice's commit on the change's branch with its trailer, the first carrying the record, and the trailer on every commit, never moved by a rewrite. The commit step's homes moved here from the front by J-93 S2. The trailer is stated once. J-102 S2: a trailer-shaped line of another key after a refusal is no answer to it; the refusal goes to the owner. R8

  16. references/greenline.md:20 method

    Build's references page: a secret is checked for presence, never printed. 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. R5

What it left out

Addy Osmani's agent-skills

Addy Osmani's agent-skills, incremental-implementation/SKILL.md: 85 of 121 sentences left out
  1. # Incremental Implementation left out: The title gives way to the step's own. replaced by line 6 of SKILL.md
  2. ## Overview left out: The overview heading gives way to the heading of the slices, over the same sentences. replaced by line 10 of SKILL.md
  3. 3 sentences taken
  4. This is the execution discipline that makes large features manageable. left out: The overview's last sentence only names the discipline; the scope paragraph says what the step does. replaced by line 6 of SKILL.md
  5. ## When to Use
  6. Implementing any multi-file change
  7. Building a new feature from a task breakdown
  8. Refactoring existing code
  9. Any time you're tempted to write more than ~100 lines before testing
  10. **When NOT to use:** Single-file, single-function changes where the scope is already minimal. 6 sentences left out: When to build in slices is the mode's: the step runs where the mode reaches it, and a change of one function is one slice. replaced by line 5 of references/greenline.md
  11. ## The Increment Cycle left out: The increment cycle's heading gives way to the heading of the slices. replaced by line 10 of SKILL.md
  12. ``` ┌──────────────────────────────────────┐ │ │ │ Implement ──→ Test ──→ Verify ──┐ │ │ ▲ │ │ │ └───── Commit ◄─────────────┘ │ │ │ │ │ ▼ │ │ Next slice │ │ │ └──────────────────────────────────────┘ ``` left out: The diagram draws the numbered cycle that follows it. replaced by line 16 of SKILL.md
  13. 4 sentences taken
  14. **Commit** -- save your progress with a descriptive message (see `git-workflow-and-versioning` for atomic commit guidance) left out: A commit per slice is allowed, each carrying the change's trailer (contradiction 4); the pointer to a git workflow skill no install carries leaves. R2 replaced by line 21 of SKILL.md
  15. 1 sentence taken
  16. ## Slicing Strategies
  17. ### Vertical Slices (Preferred)
  18. Build one complete path through the stack:
  19. ``` Slice 1: Create a task (DB + API + basic UI) → Tests pass, user can create a task via the UI Slice 2: List tasks (query + API + UI) → Tests pass, user can see their tasks Slice 3: Edit a task (update + API + UI) → Tests pass, user can modify tasks Slice 4: Delete a task (delete + API + UI + confirmation) → Tests pass, full CRUD complete ```
  20. Each slice delivers working end-to-end functionality. 5 sentences left out: Cutting the work into vertical slices is the plan step's, whose tickets are tracer-bullet slices; the build takes them in the plan's order.
  21. ### Contract-First Slicing
  22. When backend and frontend need to develop in parallel:
  23. ``` Slice 0: Define the API contract (types, interfaces, OpenAPI spec) Slice 1a: Implement backend against the contract + API tests Slice 1b: Implement frontend against mock data matching the contract Slice 2: Integrate and test end-to-end ``` 3 sentences left out: Contract-first slicing builds the backend and the frontend in parallel; greenline builds one slice after another, never in parallel. R9
  24. ### Risk-First Slicing
  25. Tackle the riskiest or most uncertain piece first:
  26. ``` Slice 1: Prove the WebSocket connection works (highest risk) Slice 2: Build real-time task updates on the proven connection Slice 3: Add offline support and reconnection ```
  27. If Slice 1 fails, you discover it before investing in Slices 2 and 3. 4 sentences left out: Putting the riskiest slice first is the plan step's ordering rule, high-risk tasks early; the build takes the plan's order.
  28. 1 sentence taken
  29. ### Rule 0: Simplicity First
  30. Before writing any code, ask: "What is the simplest thing that could work?"
  31. After writing code, review it against these checks:
  32. Can this be done in fewer lines?
  33. Are these abstractions earning their complexity?
  34. Would a staff engineer look at this and say "why didn't you just..."?
  35. Am I building for hypothetical future requirements, or the current task?
  36. ``` SIMPLICITY CHECK: ✗ Generic EventBus with middleware pipeline for one notification ✓ Simple function call ✗ Abstract factory pattern for two similar components ✓ Two straightforward components with shared utilities ✗ Config-driven form builder for three forms ✓ Three form components ```
  37. Three similar lines of code is better than a premature abstraction.
  38. Implement the naive, obviously-correct version first.
  39. Optimize only after correctness is proven with tests. 11 sentences left out: Simplicity first, whether the code needs to exist and how little of it will do, is the ponytail habit's, which loads when code is about to be written.
  40. 9 sentences taken
  41. ``` NOTICED BUT NOT TOUCHING: - src/utils/format.ts has an unused import (unrelated to this task) - The auth middleware could use better error messages (separate task) → Want me to create tasks for these? ``` left out: The example note of what was noticed and not touched gives way to the build section, which lists it. replaced by line 43 of SKILL.md
  42. 8 sentences taken
  43. ### Rule 3: Feature Flags for Incomplete Features
  44. If a feature isn't ready for users but you need to merge increments:
  45. ```typescript // Feature flag for work-in-progress const ENABLE_TASK_SHARING = process.env.FEATURE_TASK_SHARING === 'true'; if (ENABLE_TASK_SHARING) { // New sharing UI } ```
  46. This lets you merge small increments to the main branch without exposing incomplete work.
  47. ### Rule 4: Safe Defaults
  48. New code should default to safe, conservative behavior:
  49. ```typescript // Safe: disabled by default, opt-in export function createTask(data: TaskInput, options?: { notify?: boolean }) { const shouldNotify = options?.notify ?? false; // ... } ```
  50. ### Rule 5: Rollback-Friendly
  51. Each increment should be independently revertable:
  52. Additive changes (new files, new functions) are easy to revert
  53. Modifications to existing code should be minimal and focused
  54. Database migrations should have corresponding rollback migrations
  55. Avoid deleting something in one commit and replacing it in the same commit — separate them 13 sentences left out: Feature flags, safe defaults and rollback-friendly increments are knowledge for an engineering choice, handed to garden's maintainer as ruled. R2
  56. ## Working with Agents
  57. When directing an agent to implement incrementally:
  58. ``` "Let's implement Task 3 from the plan. Start with just the database schema change and the API endpoint. Don't touch the UI yet — we'll do that in the next increment. After implementing, run the repository's test and build commands to verify nothing is broken." ```
  59. Be explicit about what's in scope and what's NOT in scope for each increment. 4 sentences left out: Directing an agent to build incrementally is addressed to the person who directs it; the builder here follows the slices itself.
  60. 1 sentence taken
  61. After each increment, verify with the repository's own commands (see the test-driven-development skill's Discover the Stack First section): left out: The pointer to a test-driven-development skill's section names a skill no install carries. replaced by line 59 of SKILL.md
  62. 9 sentences taken
  63. ## Common Rationalizations
  64. | Rationalization | Reality |
  65. |---|---|
  66. | "I'll test it all at the end" | Bugs compound. A bug in Slice 1 makes Slices 2-5 wrong. Test each slice. |
  67. | "It's faster to do it all at once" | It *feels* faster until something breaks and you can't find which of 500 changed lines caused it. |
  68. | "These changes are too small to commit separately" | Small commits are free. Large commits hide bugs and make rollbacks painful. |
  69. | "I'll add the feature flag later" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |
  70. | "This refactor is small enough to include" | Refactors mixed with features make both harder to review and debug. Separate them. |
  71. | "Let me run the build command again just to be sure" | After a successful run, repeating the same command adds nothing unless the code has changed since. Run it again after subsequent edits, not as reassurance. | 9 sentences left out: The rationalizations argue for the method, a form this skill does not carry, and one argues for the feature flags handed to garden's maintainer.
  72. ## Red Flags
  73. More than 100 lines of code written without running tests
  74. Multiple unrelated changes in a single increment
  75. "Let me just quickly add this too" scope expansion
  76. Skipping the test/verify step to move faster
  77. Build or tests broken between increments
  78. Large uncommitted changes accumulating
  79. Building abstractions before the third use case demands it
  80. Touching files outside the task scope "while I'm here"
  81. Creating new utility files for one-time operations
  82. Running the same build/test command twice in a row without any intervening code change 11 sentences left out: The red flags repeat the cycle, the scope rule, the one-thing rule, the build kept green and the checklist's note on repeated runs.
  83. ## Verification
  84. After completing all increments for a task:
  85. [ ] Each increment was individually tested and committed
  86. [ ] The full test suite passes
  87. [ ] The build is clean
  88. [ ] The feature works end-to-end as specified
  89. [ ] No uncommitted changes remain 7 sentences left out: The verification after all increments repeats the cycle and the checklist; the completion contract says when a task is done. replaced by line 80 of SKILL.md
  90. ## See Also
  91. Per-increment verification is the local check.
  92. Before declaring a task done, apply the project-wide Definition of Done as the final gate, the standing bar every increment clears regardless of the task.
  93. See `../../references/definition-of-done.md`. 4 sentences left out: The definition of done points at a reference file no install carries; the completion contract is the step's bar.

pstack

pstack, principle-sequence-verifiable-units/SKILL.md: 10 of 17 sentences left out
  1. # Sequence work into verifiable units left out: The title gives way to the step's own. replaced by line 6 of SKILL.md
  2. Order work as a sequence of small units, each ending in a state you can check, and don't advance until the current one is green. left out: Small units each ending in a checkable state, the next not started until the current one is green, is the spine's overview, which stands. replaced by line 14 of SKILL.md
  3. **Why:** A break caught at the unit that caused it is cheap to localize.
  4. A break caught after a batch is buried, and you have already built further on a broken base.
  5. Sequencing those same units into a delivery a reviewer can replay turns "trust me" into "watch it go red, then green." 3 sentences left out: The why argues for the method; the bracket and the delivery order are taken.
  6. 3 sentences taken
  7. Rebase onto clean trunk first so every check measures against the real baseline. left out: Rebasing onto trunk before the units rewrites the history of the owner's branch, which is the owner's to integrate; only the bracket and the delivery order enter from this source, and the bracket's known-good state is what the build keeps. R2
  8. When a lever does the edits, the per-unit check is nearly free.
  9. Run it anyway. 2 sentences left out: A lever that does the edits names a pstack principle no install carries; the bracket's check runs at every unit, as the sentences taken say.
  10. 1 sentence taken
  11. Stack commits and PRs in the order that proves the work. left out: Build stacks commits only: the pull request is the landing the close step offers once, on the owner's word, never one opened per piece during the build; upstream's sentence also stacked pull requests. R1 replaced by line 51 of SKILL.md
  12. 3 sentences taken
  13. The sequencing complement to the **prove-it-works** principle skill, which keeps each check real, and the **build-the-lever** principle skill, which makes the per-unit check cheap. left out: The two principle skills it names are not installed.

Jesse Vincent's Superpowers

Jesse Vincent's Superpowers, executing-plans/SKILL.md: 139 of 146 sentences left out
  1. # Executing Plans left out: The title gives way to the step's own. replaced by line 6 of SKILL.md
  2. Execute the plan yourself, task by task, in this session: no implementer subagent per task, no reviewer per task.
  3. One fresh-context review of the whole branch at the end.
  4. **Why inline:** Subagent-driven development pays for a fresh implementer and a fresh reviewer on every task, each re-reading the codebase from zero.
  5. Inline execution pays for one context (yours) plus one reviewer at the end.
  6. What it gives up is a fresh context per task and a second pair of eyes per task.
  7. This skill keeps what those two things bought, by other means: the brief is the spec, the ledger is your memory, TDD is the per-task gate, and the final reviewer is the second pair of eyes. 6 sentences left out: Inline execution against a subagent per task, with one fresh reviewer at the end, is a choice between orchestrations; the builder runs every task itself and the review is the review step's. R10 replaced by line 6 of SKILL.md
  8. **Core principle:** The plan already did the thinking.
  9. Execute it exactly, prove each step with a test you watched fail and then pass, and leave a record that survives your own forgetting. 2 sentences left out: The core principle restates the cycle and the completion contract that are taken. replaced by line 80 of SKILL.md
  10. **Narration:** between tool calls, narrate at most one short line — the ledger and the tool results carry the record. left out: Narration between tool calls is a harness-wide manner, not a step of the build.
  11. **Continuous execution:** Do not pause to check in with your human partner between tasks.
  12. They chose inline execution to spend less, not to answer "should I continue?"
  13. after every task.
  14. Execute all tasks from the plan without stopping. 4 sentences left out: Whether the build pauses between tasks is the change's mode and its waits, which the plan step states.
  15. **Rulings, not stalls.**
  16. Conflicts, ambiguities, plan defects — decide them.
  17. The spec is the binding authority, the plan is its argument, and your judgment settles what neither answers.
  18. Record every decision in the ledger as `Ruling: <what you decided> — <why> — <what it costs if wrong>`, and keep going.
  19. Deviating from the plan without a ledgered ruling is a decision made in secret. 5 sentences left out: Ruling on every conflict and ambiguity alone is narrowed: a defect the spec already settles is the builder's, a product or contract choice returns to the owner (contradiction 5). R2 replaced by line 76 of SKILL.md
  20. Four things stop you, and only these: an irreversible or destructive operation; a security-sensitive action; a side effect outside this worktree that norms say you ask about first (a merge, a push to a shared branch, a publish); and a plan so broken that every path forward is a guess.
  21. For those, stop and ask. 2 sentences left out: What stops the agent, a destructive act, a security-sensitive one, an outside side effect, is the workspace's standing rules, which every step keeps; a broken plan is a defect ruled below.
  22. ## When to Use
  23. You have a plan from superpowers:writing-plans and your human partner chose inline execution at the handoff.
  24. Your harness has no subagent tool (see the per-platform references in `../using-superpowers/references/`).
  25. Never fabricate a dispatch; run the plan here.
  26. Tasks are mostly independent — the same precondition as superpowers:subagent-driven-development.
  27. A fully specified plan makes inline execution transcription plus testing: it runs well on a mid-tier session model, and the one place the most capable model earns its cost is the final review, which this skill dispatches separately.
  28. Tell your human partner so when they choose inline.
  29. Prefer superpowers:subagent-driven-development when your human partner wants a review gate on every task, or when the plan is long enough that its later tasks would run on a compacted context.
  30. Inline execution over a long plan still works — the ledger is what makes it recoverable — but the last tasks get the least of you. 9 sentences left out: When to choose inline execution over a subagent per task, with the harness's subagent references, is a choice between orchestrations; the builder runs every task itself. R10
  31. ## The Process
  32. ```dot digraph process { rankdir=TB; subgraph cluster_per_task { label="Per Task"; "task-start: brief + BASE; read the brief" [shape=box]; "Work the steps in order: TDD, run every verification, read every output" [shape=box]; "Step output matches plan's Expected?" [shape=diamond]; "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" [shape=box]; "Commit as the plan's commit steps say" [shape=box]; "Completion contract met?" [shape=diamond]; "task-done: run tests, ledger the result; mark todo complete" [shape=box]; } "Setup: worktree, workspace + ledger, read plan + spec, pre-flight scan" [shape=box]; "More tasks remain?" [shape=diamond]; "Final whole-branch review (fresh reviewer if you have one)" [shape=box]; "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger" [shape=box]; "Final review clean: delete this plan's workspace" [shape=box]; "Use superpowers:finishing-a-development-branch" [shape=box style=filled fillcolor=lightgreen]; "Setup: worktree, workspace + ledger, read plan + spec, pre-flight scan" -> "task-start: brief + BASE; read the brief"; "task-start: brief + BASE; read the brief" -> "Work the steps in order: TDD, run every verification, read every output"; "Work the steps in order: TDD, run every verification, read every output" -> "Step output matches plan's Expected?"; "Step output matches plan's Expected?" -> "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" [label="no"]; "Plan wrong? Rule and ledger. Code wrong? systematic-debugging" -> "Work the steps in order: TDD, run every verification, read every output"; "Step output matches plan's Expected?" -> "Commit as the plan's commit steps say" [label="yes, last step"]; "Commit as the plan's commit steps say" -> "Completion contract met?"; "Completion contract met?" -> "Work the steps in order: TDD, run every verification, read every output" [label="no - finish the task"]; "Completion contract met?" -> "task-done: run tests, ledger the result; mark todo complete" [label="yes"]; "task-done: run tests, ledger the result; mark todo complete" -> "More tasks remain?"; "More tasks remain?" -> "task-start: brief + BASE; read the brief" [label="yes"]; "More tasks remain?" -> "Final whole-branch review (fresh reviewer if you have one)" [label="no"]; "Final whole-branch review (fresh reviewer if you have one)" -> "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger"; "Re-grade, then: Critical/Important → ONE fix pass, each fix RED→GREEN + green suite; Minor → ledger" -> "Final review clean: delete this plan's workspace"; "Final review clean: delete this plan's workspace" -> "Use superpowers:finishing-a-development-branch"; } ``` 2 sentences left out: The process graph draws the task loop, its scripts and its final review, which are not taken.
  33. ## Setup
  34. Ensure the work happens in an isolated workspace: use superpowers:using-git-worktrees to create one or verify the existing one.
  35. Never start implementation on a main/master branch without your human partner's explicit consent. 3 sentences left out: The isolated workspace in a worktree is declined: greenline uses no worktrees; the branch is the owner's choice. R9
  36. Conversation memory does not survive compaction.
  37. An inline executor that loses its place re-implements tasks whose commits already exist — the same failure as a controller re-dispatching them, paid for in your own context.
  38. Track progress in a ledger file, not only in todos.
  39. Harness todos are a live view; the ledger is the record.
  40. The workspace and ledger are shared with superpowers:subagent-driven-development — same directory, same format — so a plan can change executors mid-flight and the new one resumes from the same ledger.
  41. Each plan owns a workspace: at skill start, run `../subagent-driven-development/scripts/sdd-workspace PLAN_FILE` — it prints the plan's git-ignored directory (`<repo-root>/.superpowers/sdd/<plan-basename>/`), home to every artifact for THIS plan: ledger, briefs, review packages.
  42. Another plan's directory is never yours to read or write.
  43. Check for this plan's ledger at `<workspace>/progress.md`.
  44. If its first line names your plan file, tasks with a `Task <N>: complete` line are DONE — do not redo them; resume at the first task without one.
  45. Their commits exist in git even when your context no longer remembers making them: after compaction, trust the ledger and `git log` over your own recollection.
  46. A ledger whose first line names a different plan file is another plan's progress: leave it and start your own, fresh.
  47. Create the ledger with its identity as the first line: `# SDD ledger — plan: <plan file path>`.
  48. `git clean -fdx` will destroy the workspace (it's git-ignored scratch); if that happens, recover from `git log`. 13 sentences left out: The ledger file and the per-plan workspace its scripts create are the change record's: the build section and the change's commits hold what they held, and the record alone resumes a change. replaced by line 5 of references/greenline.md
  49. Read the plan once, note its context and Global Constraints, and create a todo per task.
  50. If the plan names a Spec, read that too: the spec is the authority the plan argues from, and conflicts inside the plan resolve against it.
  51. A plan with no reachable spec gets a ledger note saying so — rulings made without one are provisional. 3 sentences left out: Reading the plan and its spec first is what the scope paragraph says build reads. replaced by line 6 of SKILL.md
  52. **REQUIRED SUB-SKILL:** load superpowers:test-driven-development now, before Task 1.
  53. It governs every step of every task below; a plan whose steps already say "write the failing test first" does not exempt you from reading it. 2 sentences left out: The required sub-skill names a superpowers skill; the tdd habit and the pointer to it stand. replaced by line 24 of SKILL.md
  54. Before Task 1, scan the plan for conflicts between tasks.
  55. The plan's Interfaces blocks tell you where to look: for every task that consumes what an earlier task produces, one ledger row — the two tasks, what one produces against what the other consumes, and what you found.
  56. Tasks that share nothing get no row; a plan whose tasks share nothing gets the single line `Pre-flight: no shared interfaces`.
  57. Rule on each conflict a row surfaces with the spec as the binding authority, record the ruling beside its row, and start Task 1.
  58. Each task's own text is checked when you read its brief, not here. 5 sentences left out: The pre-flight scan for conflicting interfaces is the plan's self-review, which checks the types and names across tasks.
  59. ## The Task Loop
  60. Everything you print, and every tool result, stays resident in your context for the rest of the session.
  61. Redirect long test output to a file in the workspace and read its tail; read a brief, not the whole plan. 3 sentences left out: Keeping long output out of the context is a harness-wide manner, not a step of the build.
  62. ### 1. Take the task
  63. Run this skill's `scripts/task-start PLAN_FILE N`.
  64. It prints the brief path and BASE (the commit the task's range is cut from) in one call.
  65. Read the brief for every task, including ones you remember from setup: what you remember is a summary, the brief has the exact values, signatures, and test cases.
  66. Mark the task's todo in_progress.
  67. Every tool call is a turn that re-reads your whole context.
  68. Bookkeeping rides along with work — a ledger append in the same call as the commit, never in a call of its own. 7 sentences left out: Taking a task through its start script and marking a todo are the scripts' and the harness's; the task is the plan's or the ticket's.
  69. ### 2. Work the steps
  70. The plan's steps are already in RED-GREEN order; follow them in that order under superpowers:test-driven-development, loaded at setup.
  71. A test step's code is written first and run first.
  72. Watching it fail is a step, not a formality — a test that passes before the implementation exists is a finding about the test. 4 sentences left out: Red before green under a test-driven skill is the tdd habit's, which the pointer names. replaced by line 24 of SKILL.md
  73. Every step that runs a command has an `Expected:` line.
  74. Run the command, read its output, and compare. 2 sentences left out: The Expected lines of upstream's plan become what the plan states a step's command should show. replaced by line 10 of references/greenline.md
  75. 4 sentences taken
  76. Use superpowers:systematic-debugging. left out: The debugging skill it names is a superpowers skill; finding the cause, the sentence after it, stands.
  77. 2 sentences taken
  78. Rule on the smallest change that satisfies the spec, ledger it as `Task <N>: Ruling: <finding> — <what you decided and why>`, and continue.
  79. The ruling is carried, not remembered: later tasks that touch the same interface read it from the ledger. 2 sentences left out: The ruling and its ledger line become a deviation in the build section, the builder's only for a defect the spec settles (contradiction 5). R2 replaced by line 76 of SKILL.md
  80. Commit as the plan's commit steps say.
  81. A task that spans several commits is fine; BASE is what the review range is cut from, never `HEAD~1`. 2 sentences left out: Committing is the cycle's, and the review range cut from BASE gives way to the change's commits found by their trailer.
  82. ### 3. The completion contract
  83. Before a task's ledger line, all of the following are true, with evidence in this session — not inferred from the diff looking right:
  84. Every test the brief names exists and ran in this task, and you read the output.
  85. The final test run for the task passed — `task-done` is that run, and it writes the command and result into the ledger line.
  86. Every `Expected:` line in the brief was compared against real output.
  87. Every deviation from the brief has a `Ruling:` line in the ledger. 6 sentences left out: The completion contract's ledger line, brief and task-done script are named for greenline's homes. replaced by line 80 of SKILL.md
  88. **REQUIRED SUB-SKILL:** superpowers:verification-before-completion governs the claim. left out: The required sub-skill names a superpowers verification skill; the claim of the change is the verify step's.
  89. 1 sentence taken
  90. ### 4. Complete the task
  91. Run this skill's `scripts/task-done PLAN_FILE N BASE -- <test command>` with the test command the brief names for the whole task.
  92. It runs the tests, keeps the full output in the workspace, prints the tail, and — only if they pass — appends the completion line to the ledger:
  93. `Task <N>: complete (commits <base7>..<head7>, tests: <command> → <result>)`
  94. A failing run records nothing; the task is not complete.
  95. When it records, mark the todo complete and take the next task. 6 sentences left out: Completing a task through its done script and ledger line is the scripts'; the completion contract and the change's checks say when a task is done. replaced by line 80 of SKILL.md
  96. ## Final Review
  97. Run `../subagent-driven-development/scripts/review-package PLAN_FILE MERGE_BASE HEAD` (MERGE_BASE = the commit the branch started from, e.g. `git merge-base main HEAD`) and review from the file it prints.
  98. **With a subagent tool:** dispatch the reviewer on the most capable available model — the whole-branch review is a judgment task — using superpowers:requesting-code-review's [code-reviewer.md](../requesting-code-review/code-reviewer.md), with the package path, the plan and spec paths, the plan's Review Focus section verbatim if it has one (the input classes and failure modes the plan's tests do not exercise — the reviewer checks each deliberately), and a pointer to the ledger's `Ruling:` lines so it can weigh the calls you made.
  99. Specify the model explicitly; an omitted model inherits the session's, which may not be the most capable.
  100. This is the one fresh context the whole run buys.
  101. Do not skip it, and do not replace it with your own read of the diff.
  102. **Without a subagent tool:** read code-reviewer.md and perform that review yourself against the package, as a separate pass after the last task's ledger line.
  103. Write `Final review: self-review (no subagent tool)` to the ledger, and say so in your final message: a self-review by the author is weaker than a fresh reviewer, and your human partner decides whether that is enough before merge.
  104. Sort the findings before you act on any of them.
  105. The reviewer's severity labels are advice; the gate is yours.
  106. Its "Declined to judge" list is yours too: every line there is a ruling you make and ledger, exactly like a plan conflict — `Final: Ruling: <behavior the reviewer set aside> — <what a reasonable person using this software gets, and why that stands or why it is now a finding> — <cost if wrong>`.
  107. Re-grade first, by effect: the spec is a vision document, and a finding's grade is what a reasonable person using this software gets if it ships, not whether the spec names the input that triggers it — a reviewer who set a finding at Minor because the spec was silent has graded the spec, not the effect.
  108. Then:
  109. **Critical and Important** enter the fix pass.
  110. **Minor** goes to the ledger as `Final: minor (deferred): <one-liner>` and to your final message under "Deferred minors".
  111. Minors never enter the fix pass, and never become rulings — a ruling is a decision about a conflict, not a note that you declined a polish suggestion.
  112. Fix the Critical and Important findings yourself — you are the implementer here — in ONE pass.
  113. Each fix is verified by TDD, not by a second reviewer: write the test that reproduces the finding, watch it fail, make it pass, then run the whole suite.
  114. Record each in the ledger as `Final: fixed <finding> — <test name> RED→GREEN, suite <N>/<N>`.
  115. A fix without a test that failed first is not verified; a suite that is not green after the pass means the pass is not over.
  116. Do not dispatch a re-review: it would re-read a diff whose covering tests already answer "addressed" and whose suite run already answers "broke nothing".
  117. A finding you decide not to fix is a ruling — `Final: Ruling: <finding> — <why the code stands> — <cost if wrong>` — and reaches your human partner in the rulings list.
  118. There is no second fix pass. 23 sentences left out: The final review of the whole branch, by a dispatched subagent on the most capable model or by the author, is the review step's, which runs at the depth the mode gives it. R10
  119. ## Finish
  120. Before you delete anything, collect every ledger line containing `Ruling:` into your final message under "Rulings I made", in the order you made them, each with what it costs if wrong, and every `minor (deferred)` line under "Deferred minors".
  121. Both lists are exhaustive.
  122. Your final message is the only place the decisions you took on your human partner's behalf — and the findings you chose not to act on — reach them.
  123. When the final review is clean and its fixes are committed, delete this plan's workspace directory — the git history is the record now.
  124. Sibling directories belong to other plans; leave them alone.
  125. Use superpowers:finishing-a-development-branch. 7 sentences left out: Gathering the rulings into the final message and finishing the branch are the close step's, which audits the record and writes its close section.
  126. ## Common Rationalizations
  127. | Excuse | Reality |
  128. |--------|---------|
  129. | "I remember what Task N says" | You remember a summary. The brief has the exact values. Read it. |
  130. | "The plan's code is right, skip watching the test fail" | A test you never saw fail proves nothing. It is one step. Run it. |
  131. | "I'll run the full suite at the end instead of per step" | Per-step runs are how you learn which step broke it. The end-of-task run is the contract, not a substitute. |
  132. | "The plan is wrong here, I'll just do the right thing" | Do the right thing and ledger the ruling. Unledgered deviation is a decision made in secret. |
  133. | "I'll write the ledger lines after a few tasks" | Compaction does not wait for a convenient moment. One line per task, in the same message as the commit. |
  134. | "Let me check in before the next task" | They chose inline to spend less. Progress prompts spend their time instead. Only the four stops stop you. |
  135. | "I read my own diff carefully; the final reviewer is redundant" | Same author, same blind spots. The reviewer is the only fresh context this run buys. |
  136. | "Tests should pass, the change was trivial" | "Should" is not evidence. The contract requires the command and its output. |
  137. | "Subagents are slow and expensive, I'll skip the final review too" | Inline already removed the per-task reviewers. One review of the whole branch is the floor, not the ceiling. |
  138. | "The reviewer said Minor, so it's Minor" | The label graded the spec's silence. Grade what the person gets. Re-grade, then gate. |
  139. | "The fix is obvious, no need for a failing test first" | The failing test is the only proof the finding was real and is now gone. Without it you have a diff and a hope. |
  140. | "I'll fix the minors too while I'm in there" | Every minor you fix is a test, a fix, and a suite run your partner did not ask for. Ledger them; your partner decides. | 15 sentences left out: The rationalizations argue for the method, a form this skill does not carry, and several argue for the ledger and the final review, which are not taken.
  141. ## Example Workflow
  142. ``` You: I'm using the executing-plans skill to implement this plan inline. [Setup: worktree verified] [Read plan once: docs/superpowers/plans/feature-plan.md; spec read] [Resolve workspace: sdd-workspace docs/superpowers/plans/feature-plan.md — no ledger inside, fresh start] [Pre-flight scan: 2 shared-interface rows, 4 self-consistency rows, clean; written to ledger] [Create todos for all tasks] Task 1: Hook installation script [task-start plan 1 → brief read; BASE a1b2c3d] [Step 1: write failing test — written] [Step 2: run it — FAIL: install_hook not defined. Matches Expected.] [Step 3: implement — written] [Step 4: run it — PASS 1/1. Matches Expected.] [Step 5: commit — d4e5f6a] [Contract: tests ran, output read, no deviations] [task-done plan 1 a1b2c3d -- npm test -- hooks → ledger: Task 1: complete (commits a1b2c3d..d4e5f6a, tests: npm test -- hooks → 1/1 pass)] Task 2: Recovery modes [task-start plan 2 → brief read; BASE d4e5f6a] [Step 2: run failing test — FAIL, but on an import error: Task 1 exported installHook, brief consumes install_hook] [Ruling: brief's consumer name is a typo against Task 1's Produces block; use installHook — Ledger: Task 2: Ruling: install_hook → installHook — matches Task 1 Produces — cost if wrong: one rename] [Steps 2-5 as planned; commit b7c8d9e] [task-done plan 2 d4e5f6a -- npm test -- recovery → ledger: Task 2: complete (commits d4e5f6a..b7c8d9e, tests: npm test -- recovery → 8/8 pass)] ... [After all tasks: review-package plan MERGE_BASE HEAD; dispatch code-reviewer, most capable model] Reviewer: One Important finding — progress reporting interval hardcoded. Two Minor. [Re-grade: Important stands; minors → ledger as deferred] [Fix pass: test_progress_interval_configurable RED → extract PROGRESS_INTERVAL → GREEN; suite 12/12; commit] [Ledger: Final: fixed hardcoded interval — test_progress_interval_configurable RED→GREEN, suite 12/12] Rulings I made: - Task 2: install_hook → installHook (brief typo; cost if wrong: one rename) Deferred minors: - README lacks a usage example - recovery.js could split verify/repair into two files [Delete this plan's workspace — the record now lives in git] Using superpowers:finishing-a-development-branch. ``` 2 sentences left out: The example workflow walks the scripts, the worktree and the final review, which are not taken.

The ledger entry

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

2026-10-21 2026-10-21-build-no-lookalike-trailer

A look-alike trailer after a refusal is no answer to it

A trailer-shaped line of another key, such as Related-Change, put in a message after a hook's refusal is no answer to it: the refusal is reported and the owner asked (J-102 S2).

Authorised by
2026-10-21 The operator's cards of 2026-10-21, "Fix first, then ship (Recommended)" and the scope card naming 1 to 7 (docs/DECISIONS.md, the rows of 2026-10-21): 0.1.0 ships with its hooks whole, and frame, groundwork and build say what the owner's yes is, that the setup record precedes the setup commit, that a trailer-shaped line of another key after a refusal is no answer to it, and that scratch goes under the change's own id
Pages it touched
references/greenline.md
Rulings, R1 to R19
  1. The operator's cards of 2026-10-14 on part 4 of the-whole-change, each "Rule as proposed", under N-49's root card that the owner chooses where the change's checkout lives: the proposal names where the change's commits will go, read from local facts with no network command, the current branch when it is not the default branch or there is no remote and a new branch greenline/<id> otherwise, the owner's answer final; a worktree holds the change's checkout only on the owner's request and only where the harness runs the session in it, and no fresh agent runs in one of its own; the close step offers the landing in one line by the setup, a push and a pull request where the remote is a forge, a local merge where there is no remote, or the branch left, each only on the owner's word, the push and pull-request rule moving into the block and the close step while pr-writing keeps the writing method; and a plan's tickets share the planning change's branch, each ticket's commits carrying its own trailer, and the planning change's close offers the landing for the whole
  2. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): incremental-implementation, principle-sequence-verifiable-units and executing-plans combine into build, with incremental-implementation's feature flags, safe defaults and rollback handed to garden's maintainer and only principle-sequence-verifiable-units' known-good bracket and failing-test-first delivery order entering from it, and the contradictions stand as recommended: a commit per slice is allowed, each carrying the change's trailer (contradiction 4), and a plan defect the spec already settles is the builder's to rule while a product or contract choice returns to the owner (contradiction 5)
  3. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): incremental-implementation, principle-sequence-verifiable-units and executing-plans combine into build, with incremental-implementation's feature flags, safe defaults and rollback handed to garden's maintainer and only principle-sequence-verifiable-units' known-good bracket and failing-test-first delivery order entering from it, and the contradictions stand as recommended: a commit per slice is allowed, each carrying the change's trailer (contradiction 4), and a plan defect the spec already settles is the builder's to rule while a product or contract choice returns to the owner (contradiction 5); 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, and looped an independent pass repeated until clean up to the mode's rounds, and a step's handoff names the next step of the change's mode; 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 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, and looped an independent pass repeated until clean up to the mode's rounds, and a step's handoff names the next step of the change's mode; The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": build's spine is incremental-implementation, implement being a stub, anticipate ships as a trial on the trial step, and domain-modeling splits, its questioning into frame and its glossary into close; The operator's cards of 2026-10-14 on part 4 of the-whole-change, each "Rule as proposed", under N-49's root card that the owner chooses where the change's checkout lives: the proposal names where the change's commits will go, read from local facts with no network command, the current branch when it is not the default branch or there is no remote and a new branch greenline/<id> otherwise, the owner's answer final; a worktree holds the change's checkout only on the owner's request and only where the harness runs the session in it, and no fresh agent runs in one of its own; the close step offers the landing in one line by the setup, a push and a pull request where the remote is a forge, a local merge where there is no remote, or the branch left, each only on the owner's word, the push and pull-request rule moving into the block and the close step while pr-writing keeps the writing method; and a plan's tickets share the planning change's branch, each ticket's commits carrying its own trailer, and the planning change's close offers the landing for the whole
  5. 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
  6. 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, and looped an independent pass repeated until clean up to the mode's rounds, and a step's handoff names the next step of the change's mode; The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": build's spine is incremental-implementation, implement being a stub, anticipate ships as a trial on the trial step, and domain-modeling splits, its questioning into frame and its glossary into close; 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)
  7. 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 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: every check of a change's code on a long build runs through greenline check, whose short form greenline check -- <command> takes the open change and the step its record is in; the one run left plain is a probe, one recorded by mistake being marked with greenline check --probe; and greenline status counts the commits since the last recorded check, a nudge and never a finding, while the close sets done only on green recorded checks of the final code; 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 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 rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): incremental-implementation, principle-sequence-verifiable-units and executing-plans combine into build, with incremental-implementation's feature flags, safe defaults and rollback handed to garden's maintainer and only principle-sequence-verifiable-units' known-good bracket and failing-test-first delivery order entering from it, and the contradictions stand as recommended: a commit per slice is allowed, each carrying the change's trailer (contradiction 4), and a plan defect the spec already settles is the builder's to rule while a product or contract choice returns to the owner (contradiction 5); The operator's cards of 2026-10-14 on part 4 of the-whole-change, each "Rule as proposed", under N-49's root card that the owner chooses where the change's checkout lives: the proposal names where the change's commits will go, read from local facts with no network command, the current branch when it is not the default branch or there is no remote and a new branch greenline/<id> otherwise, the owner's answer final; a worktree holds the change's checkout only on the owner's request and only where the harness runs the session in it, and no fresh agent runs in one of its own; the close step offers the landing in one line by the setup, a push and a pull request where the remote is a forge, a local merge where there is no remote, or the branch left, each only on the owner's word, the push and pull-request rule moving into the block and the close step while pr-writing keeps the writing method; and a plan's tickets share the planning change's branch, each ticket's commits carrying its own trailer, and the planning change's close offers the landing for the whole; The operator's cards of 2026-10-14 on part 5 of the-whole-change, the walk's cures: "A branch of its own", a change's commits never going to another change's branch, the new change taking greenline/<id> from the default branch where a remote exists and the default branch itself where there is none; "At the proposal", the change's id chosen when the proposal is written, its branch, working folder and record taking the same id; "Yes, every stop commits", every stop committing the record with the change's trailer, so a stopped change is found from any branch and after a clone and resumes on the branch that commit sits on; "Not counted", an agent a step's method starts named in that step's section and counted nowhere; "The one brief, the method's extras", that agent getting the one brief with the extras the page that starts it names; and "Settle in S6" for the orientation's edges and the setup's, the default branch being origin/HEAD, else init.defaultBranch, else the branch HEAD names, and a remote that is no forge offering the local merge or the branch left, never a pull request; 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); The operator's cards of 2026-10-21, "Fix first, then ship (Recommended)" and the scope card naming 1 to 7 (docs/DECISIONS.md, the rows of 2026-10-21): 0.1.0 ships with its hooks whole, and frame, groundwork and build say what the owner's yes is, that the setup record precedes the setup commit, that a trailer-shaped line of another key after a refusal is no answer to it, and that scratch goes under the change's own id
  9. 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
  10. 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: the builder runs every task itself; doubt-driven-development's doubt pass is one delegated agent per round only where anticipate is looped, and the self-questioning form, recorded as degraded, at the inline and written depths and where the harness has no delegation; its cross-model escalation to outside tools is dropped; show-me-your-work's audit reads the change's commits and checks, never a transcript, and its cross-model reviewer is dropped
  11. The operator's ruling R22 of 2026-10-08 on the re-cut brief, "yes amend, with one change": build's spine is incremental-implementation, implement being a stub, anticipate ships as a trial on the trial step, and domain-modeling splits, its questioning into frame and its glossary into close
  12. The operator's rulings of 2026-10-08 on the intake R3 ("yes go ahead" and "everything is good"): incremental-implementation, principle-sequence-verifiable-units and executing-plans combine into build, with incremental-implementation's feature flags, safe defaults and rollback handed to garden's maintainer and only principle-sequence-verifiable-units' known-good bracket and failing-test-first delivery order entering from it, and the contradictions stand as recommended: a commit per slice is allowed, each carrying the change's trailer (contradiction 4), and a plan defect the spec already settles is the builder's to rule while a product or contract choice returns to the owner (contradiction 5), so the drop of its rebase onto trunk follows from that ruling, the sequence-verifiable-units proposal having named the bracket and the delivery order as what enters
  13. 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, and looped an independent pass repeated until clean up to the mode's rounds, and a step's handoff names the next step of the change's mode
  14. 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
  15. The operator's cards of 2026-10-14 on part 5 of the-whole-change, the walk's cures: "A branch of its own", a change's commits never going to another change's branch, the new change taking greenline/<id> from the default branch where a remote exists and the default branch itself where there is none; "At the proposal", the change's id chosen when the proposal is written, its branch, working folder and record taking the same id; "Yes, every stop commits", every stop committing the record with the change's trailer, so a stopped change is found from any branch and after a clone and resumes on the branch that commit sits on; "Not counted", an agent a step's method starts named in that step's section and counted nowhere; "The one brief, the method's extras", that agent getting the one brief with the extras the page that starts it names; and "Settle in S6" for the orientation's edges and the setup's, the default branch being origin/HEAD, else init.defaultBranch, else the branch HEAD names, and a remote that is no forge offering the local merge or the branch left, never a pull request
  16. 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
  17. 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: every check of a change's code on a long build runs through greenline check, whose short form greenline check -- <command> takes the open change and the step its record is in; the one run left plain is a probe, one recorded by mistake being marked with greenline check --probe; and greenline status counts the commits since the last recorded check, a nudge and never a finding, while the close sets done only on green recorded checks of the final code
  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
  19. The operator's cards of 2026-10-21, "Fix first, then ship (Recommended)" and the scope card naming 1 to 7 (docs/DECISIONS.md, the rows of 2026-10-21): 0.1.0 ships with its hooks whole, and frame, groundwork and build say what the owner's yes is, that the setup record precedes the setup commit, that a trailer-shaped line of another key after a refusal is no answer to it, and that scratch goes under the change's own id
9 earlier entries

  1. 2026-10-19 2026-10-19-build-split-review-fixes

    Build's references page states probes, facts and the trailer once

  2. 2026-10-19 2026-10-19-build-front-and-references

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

  3. 2026-10-19 2026-10-19-build-references

    Build's mechanics move from the block to its references page

    Pages it touched: references/greenline.md

  4. 2026-10-18 2026-10-18-build-checks-in-the-short-form

    Every check, a rerun to read a red included, recorded

    Pages it touched: SKILL.md

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

    Increments' checks run through greenline check; the first commit carries the record

    Pages it touched: SKILL.md

  6. 2026-10-14 2026-10-14-build-never-another-branch

    A slice never commits on another change's branch

    Pages it touched: SKILL.md

  7. 2026-10-14 2026-10-14-build-names-the-branch

    Build commits on the change's branch, a ticket on its plan's

    Pages it touched: SKILL.md

  8. 2026-10-09 2026-10-09-build-gists

    Every account gets a short gist for the website

  9. 2026-10-08 2026-10-08-build-recipe

    Build is made on incremental-implementation, one slice at a time

    Pages it touched: SKILL.md