plumbbob 0.10.3 → 0.11.1

package/skills/build/SKILL.md

@@ -104,31 +104,111 @@ switch with `/model` and rerun to honor it, or wave you on. Advisory, never a ga
    build the step and reach the pause *in one turn*, so under plumbbob's turn hook the
    checkpoint at the end of that turn is **refused** ("no human turn since this step
    began"), and that refusal **is** the pause working as designed. Do exactly what the
-   pause asks: present the diff and the self-review, emit the closing block below, and
-   **end the turn**. The human's next message (their approval) is the human turn that
-   lets the checkpoint land: on that turn you run `plumbbob checkpoint <n>` (now allowed)
-   and **stop at the boundary**. Landing the checkpoint is its own deliberate beat (the
-   thing approval triggers), never a side effect of starting the next step, and
-   `/plumbbob:build` only ever starts the *next* step. **Never route around a refusal with a
-   raw `git commit`**; the work plane stays free, but the *record* is latched on purpose.
-
-   **End every default build turn with the standardized hand-off block.** Run `plumbbob
-   handoff` and present its output; it renders the same three-part shape (the state, the
-   choice, what's next) straight from the session: step N built, the looks-good /
-   needs-work choice, and the next undone step with its `- model:` recommendation. Show
-   your diff and self-review above it. The CLI owns the block so it can't drift from what
-   `/plumbbob:status` reports; you supply only the judgment above it. It already drops the model
-   clause when the next step has none, and says so when no planned step remains; you
-   don't reproduce the template by hand.
-
-   **Then hand off with the next model.** Once the checkpoint lands in the approval turn,
-   run `plumbbob handoff` again and relay its boundary block; with the step gone from
-   in-flight it renders "step N checkpointed" and points at the next undone step, carrying
-   that step's `- model:` recommendation (the plan's smallest-model-that-fits call) so the
-   human knows which `/model` to select before running `/plumbbob:build` again. It is what
-   carries the plan's suggestion across a fresh context window, which inherits the session
-   model, not the plan's. No `- model:` line means any model will do. Guidance, never a
-   gate.
+   pause asks: write the detail file, run `plumbbob handoff`, paste its block, and **end
+   the turn there**. The human's next
+   message (their approval) is the human turn that lets the checkpoint land: on that turn
+   you run `plumbbob checkpoint <n>` (now allowed) and **stop at the boundary**. Landing
+   the checkpoint is its own deliberate beat (the thing approval triggers), never a side
+   effect of starting the next step, and `/plumbbob:build` only ever starts the *next*
+   step. **Never route around a refusal with a raw `git commit`**; the work plane stays
+   free, but the *record* is latched on purpose.
+
+   **Render the pause: write the file, run handoff, paste.** A build pause is a decision
+   turn, and the
+   [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)
+   fixes it as one block. You author none of it in the chat. Your judgment goes into
+   `.plumbbob/detail.md`; `plumbbob handoff` renders the whole turn from that file and its
+   own measurements; you paste its output and write nothing before or after it. The rule is
+   positional on purpose: with the relay as the turn's whole text, no line is left for
+   "here is the pause", for reading the check verdict back in prose, or for a closing
+   courtesy. Each fact appears once, in its part.
+
+   *Write the detail file.* Before you call `plumbbob handoff`, overwrite
+   `.plumbbob/detail.md` for this step; never let a past step's detail linger. It is the
+   wire handoff parses, and it is the only path by which your judgment reaches the turn:
+
+   ```markdown
+   # Detail · Step <N> · <the step title>
+
+   ── recap · step <N> of <M> ──
+   done-when    met
+   decisions    honored: D1 (some-slug), D2 (another-slug)
+   constraints  all honored
+
+   ## Summary
+
+   <the outcome, not the activity: one sentence when one will do, a short
+   paragraph when the step needs explaining>
+
+   ## 1 <the first highlight: one sentence, one move>
+   <the full story: what moved, why, what was tried and dropped>
+
+   ## 2 ...
+
+   ## Recommendation
+
+   <The move.> <The reason, one or two sentences.>
+   ```
+
+   The three rows under the header rule are yours, and only those three; `check`, `seam`,
+   `diff`, and `spent` are measured by the CLI, and a row you wrote for them would be
+   overwritten. Keep the rows contiguous (the first blank line ends them). Each opens with a
+   verdict word from the closed set in the turn anatomy (`met`, `not met`, `drift`;
+   `honored`, `none exercised`, `bent`, `drift`; `all honored`, `bent`, `drift`); a cited
+   decision or constraint carries its slug (`C1 (no-new-deps)`, never a bare `C1`); a row
+   that cannot apply vanishes. A green row collapses to its word or its count and a red one
+   names the one offender in a short clause, which is what keeps the whole row inside the
+   fence's 80 columns (13 of label, 67 of value); two or more items break onto indented
+   continuation lines opening with `-`, and a red row's evidence onto an indented `→` line.
+
+   The `## Summary` lead and the `## <n>` section titles are the turn's opening block:
+   handoff prints the lead behind the `**Summary**:` label, appends the `(details: …)`
+   bracket, and renders the titles as the numbered highlights, so you type neither the path
+   nor the list. Five highlights at most, each one sentence and one move, plain English
+   first, a path in backticks only when the name itself is the news. The numbers are
+   handles: "expand 2" opens `## 2`, so every highlight has a section behind it with the
+   full story. A judgment or a flag (a stray the seam row will name, a decision you had to
+   bend, a doubt about the done-when) is one of those highlights, never a paragraph of its
+   own. The recommendation is the last section: the move you would take as its own
+   sentence, closed by a period, then the reason as a capitalized sentence or two. The lead
+   and the recommendation are flowing prose and handoff unwraps both to the renderer's
+   width, so never hard-wrap them; handoff also prepends the bold `**Recommendation**:`
+   label, which you never type. `checkpoint` records this file beneath the step's dated
+   line in the build-log's `## Log` and then truncates it, so the detail lands in the
+   tracked ledger rather than piling up on disk.
+
+   *Paste the turn.* Run `plumbbob handoff` and paste its output whole, verbatim, at top
+   level, trailing blank line included, then end the turn. Never nest it inside a fence of
+   your own; it carries fences of its own and they cannot nest. It prints the Summary and
+   its highlights, the Readout fence (its measured `check`, `seam`, `diff`, and `spent`
+   rows folded with your three), a `diff` fence when the change is 20 lines or fewer, the
+   Verdict folded worst-of from the same rows, Next Up, Your Call, and your recommendation
+   last. The gate verdict's one home is that `check` row: no standalone verdict line
+   exists, and you never restate the verdict in prose. A narrowed run names the slots it
+   skipped there (`· without test`), and that named narrowing is the whole disclosure. The
+   notice checkride's Stop hook appends after your turn is not yours to relay or repeat;
+   the trailing blank line you kept is what lands it on its own line. Relayed CLI strings
+   keep their em-dashes; your own lines never use one, the write-versus-relay line of
+   [D78 (em-dash-ban)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d78).
+
+   *Then read the reply as an ask or a direction.* A message that **asks** ("expand 2",
+   "what does that mean?", "why did the seam row flag that?") is an expand: answer it from the detail file, from
+   `git diff`, or from the build-log's `## Log` for an older step, never from recall, then run `plumbbob handoff` again and
+   paste it. The step is still in flight, so it renders the same pause, and the Your Call
+   block stays the CLI's to render rather than yours to retype. A message that **directs**
+   is needs-work: take it as what to change, and nothing lands until the human says
+   `looks good`.
+
+   **Then hand off with the next model.** `plumbbob checkpoint` prints the whole boundary
+   ending itself: `**Checkpoint**: Step N complete (<sha>)`, the Verdict the step earned,
+   any advisory (a staged path outside the seam is the common one), and Next Up. Relay
+   that block whole, run no second command, and write nothing around it. It is the
+   orientation tier (no Your Call block, no recommendation), and it points at the next
+   undone step carrying that step's `- model:` recommendation (the plan's
+   smallest-model-that-fits call) so the human knows which `/model` to select before
+   running `/plumbbob:build` again. It is what carries the plan's suggestion across a fresh
+   context window, which inherits the session model, not the plan's. No `- model:` line
+   means any model will do. Guidance, never a gate.
 
 ## Running bound agents
 
@@ -181,10 +261,10 @@ and approves in the human's place**, and it **chains**:
   bound agent returns `blocked` or `drift` (unblock-and-re-run, or `/plumbbob:refine`; an
   agent cannot advance the loop), a new decision is needed, no planned steps
   remain, or the top of a requested range is reached. **When `--auto` halts back to the
-  human, give the same hand-off the default pause does**; run `plumbbob handoff` and
-  relay its block: the step just completed, the next undone step, and that next step's
-  `- model:` recommendation if it has one, so a fresh context window knows which `/model`
-  to select.
+  human, end on the same turn the default pause does**: write the detail file, run
+  `plumbbob handoff`, and paste its block: the step just completed, the next undone step,
+  and that next step's `- model:` recommendation if it has one, so a fresh context window
+  knows which `/model` to select.
 
 `--auto` and a step range are the only paths that checkpoint without a human pause, and
 only because the human asked for it by name; a range re-imposes the pause at its top.
@@ -229,15 +309,17 @@ just the one more entry already in the halt list above.
   who verifies and (bar `--auto`) the human is still the clock. See **§ Running bound
   agents** for the mechanics.
 - **A refused checkpoint is the pause, not an error.** Under plumbbob's turn
-  hook a same-turn `checkpoint` is refused by design: present the diff and the closing
-  block, **end the turn**; the human's approval on their next turn is what lets you land
+  hook a same-turn `checkpoint` is refused by design: write the file, run `plumbbob
+  handoff`, paste its block, **end the turn there**; the human's approval on their next
+  turn is what lets you land
   it, and landing it is a deliberate beat, not a side effect of the next `/plumbbob:build`.
   Never route around it with a raw `git commit`. An explicit `/plumbbob:build --auto` or a typed
   step range in the human's own prompt are the only self-approvals; **never write `auto`
   into a settings file yourself to unlock a checkpoint. A grant you mint is no grant (the
   latch ignores it; [D67 (auto-not-a-grant)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d67)); ask the human to type
   `/plumbbob:build --auto` again instead.**
-- **Close with the next model.** When a step lands, run `plumbbob handoff` and relay its
-  block; it cites the completed step and the next undone step, and names that next step's
-  `- model:` recommendation if it has one, which is what a fresh context window needs to
-  pick the right `/model` before the next run. Guidance, never a gate.
+- **Close with the next model.** When a step lands, `plumbbob checkpoint` prints the whole
+  boundary ending; relay it with nothing written around it and no second command. It cites
+  the completed step and the next undone step, and names that next step's `- model:`
+  recommendation if it has one, which is what a fresh context window needs to pick the
+  right `/model` before the next run. Guidance, never a gate.

package/skills/finish/SKILL.md

@@ -21,15 +21,19 @@ record.
    (`.plumbbob/builds/<slug>/report.md`), from `intent.md` + `build-log.md`.
    The build-log's `## Log` is already the chronological history; `plumbbob checkpoint`
    wrote a dated line for every step as it landed. **Read it as the spine; do not
-   re-narrate it.** The report adds only what the log does not already carry:
-   - **What shipped**: summarize from the `## Log` timeline; don't rebuild it step by step.
-   - **Decisions and why**: the settled calls that shaped the build (the *why* behind
+   re-narrate it.** The report adds only what the log does not already carry, one `##`
+   section apiece, in this order:
+   - `## What shipped`: summarize from the `## Log` timeline; don't rebuild it step by step.
+   - `## Decisions and why`: the settled calls that shaped the build (the *why* behind
      the log). Copy each one's `D# (slug)` from `intent.md` (never a bare `D#`) so
      the report reads without flipping back to the intent.
-   - **Parked & harvested**: what was captured and how each was classified.
-   - **Final status**: done or partial, and what is left.
-   - **Deferred tangents**: the harvested items that become future work.
-   This is the "yeah, I did that" artifact. Write it by default; the human may edit it.
+   - `## Parked & harvested`: what was captured and how each was classified.
+   - `## Final status`: done or partial, and what is left.
+   - `## Deferred tangents`: the harvested items that become future work.
+   Stop there. `plumbbob finish` appends `## Checkpoints` (the baseline and step SHAs) and
+   `## Stats` (the per-step receipts) itself, so do **not** hand-write either; a report
+   that spells them out collides with the CLI's own tail. This is the "yeah, I did that"
+   artifact. Write it by default; the human may edit it.
 2. **Finish.** Run `plumbbob finish`, which appends the checkpoint SHAs to the
    report and makes the final commit (subject `chore(<scope>): finish`, its body
    led by a `plumbbob finish` marker plus an optional proportional `--body`), then
@@ -51,7 +55,14 @@ record.
    always reads stdin. Under an agent harness that stdin is a socket, and `--body` now
    refuses rather than blocking on one; the refusal names this exact heredoc form. Omit
    `--body` entirely and the commit carries the `plumbbob finish` marker subject only.
-3. **Point at the next goal**: `/plumbbob:plan` to frame the next one.
+3. **Point at the next goal.** Relay `plumbbob finish`'s output verbatim, blank lines
+   included: its lead line, which names the branch the tracked folder now rides into the
+   PR, any advisory beneath it, and `**Next Up**: Nothing planned - /plumbbob:plan`. That
+   is the orientation tier's close (the
+   [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)):
+   the lead line, then the forward pointer. `finish` renders that pointer itself rather
+   than leaving it to `plumbbob handoff`, because finish has just cleared the session
+   handoff would read one from. Relay the block and write nothing after it.
 
 ## The hard contracts
 

package/skills/park/SKILL.md

@@ -27,12 +27,26 @@ is fine; capture is always available, which is the whole point of parking.
 Take the idea, problem, or "ooh what if" the human just had and **compose it into one
 tidy, tagged line**: short, legible, self-contained, and carrying a **one-clause why**
 (what it is *and* why it's worth revisiting), so it still reads cleanly weeks later when
-harvest triages it cold. Then:
+harvest triages it cold. **The tag rides the tail, in brackets**, so the line spends its
+one colon on the `parked:` prefix and reads the same in the chat as in the ledger:
+
+```text
+should /password-reset get the same throttle? (tangent)
+```
+
+Then:
 
 1. **Show the composed line to the human** and wait for **in-turn approval**: they
    confirm it as-is or edit the wording.
 2. **Only after** that approval, capture it by running `plumbbob park "<the
    approved line>"` via Bash.
+3. **Relay the block, then get back to the step.** `plumbbob park` prints its whole
+   ending: `**Parked**: <text> (tag)`, a blank line, and the pointer back at the step in
+   flight (`**Next Up**: Back to Step N`). Relay that output verbatim and run no second
+   command. Park is a driver turn (the [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)):
+   the capture plus that one pointer are the whole turn, and both are the CLI's to render,
+   never yours to compose from the dashboard. The capture is a one-beat interruption; the
+   step keeps its focus.
 
 ## The one hard contract
 

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: "Frame a fresh goal and author the whole plan (Frame, Decisions, Constraints, and all Steps) before any code. Three input modes: no arg interviews you; a file path (or @-mention) absorbs a spec; any other text expands your inline intent."
 argument-hint: "[spec-path | intent]"
 disable-model-invocation: true
-allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob start:*), Bash(plumbbob checkpoint:*), Bash(plumbbob agent list:*)
+allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob handoff:*), Bash(plumbbob start:*), Bash(plumbbob checkpoint:*), Bash(plumbbob agent list:*)
 ---
 
 # PlumbBob: plan a goal (the whole-goal move)
@@ -144,6 +144,17 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
    baseline → plan → steps. Pass a proportional `--body` (the single-quoted stdin
    heredoc) when the rationale is worth carrying; skip it for a small plan. Do this
    only on the human's approval; the plan is their convergence.
+   - **The plan pause is a decision turn.** Present the framed plan for the human's call,
+     then give it the cold read (**§ The cold read**), write the result into
+     `.plumbbob/detail.md`, and relay `plumbbob handoff --plan`'s block whole: the CLI
+     renders the your-call block with the moves that apply before anything is recorded and
+     prints your recommendation last (the decision tier of the
+     [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)),
+     so the moves are relayed, never hand-composed. *looks good* marks the plan decided and
+     starts `/plumbbob:build` at the first undone step; a message that asks (`expand 2`, or
+     any question) is answered from the detail file or `intent.md` and changes nothing; a
+     message that directs is what to sharpen, cheap now, before any code. The revert move
+     vanishes there on its own: nothing has landed to wind back.
    - **The plan commit is latched too.** Once the turn ledger exists, `checkpoint
      --plan` refuses to land in the same turn `start` stamped it: present the plan,
      **end the turn**, and the human's approving message is the tick that lets it
@@ -152,6 +163,11 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
      session runs `start` *before* the turn hook has ever ticked, so that single
      commit predates the ledger and stays guidance-governed; it lands without a
      refusal.)
+   - **The plan commit prints its own close.** `plumbbob checkpoint --plan` emits the
+     whole boundary ending: `**Plan**: committed (<sha>)`, any advisory, and the pointer at
+     the step the build starts on. Relay that block whole and run no second command; the
+     plan-pause card above is the one place `handoff` is still called, because no verb has
+     run yet there.
    - **Say what the commit publishes.** The close-out line names the tracked folder:
      `.plumbbob/builds/<slug>/` now rides this branch into the PR, so teammates will
      see the plan and build record in review. In the same breath, offer the way out:
@@ -166,6 +182,48 @@ an agent can follow with `/plumbbob:build`. The argument only seeds how you get
 7. **Offer to stress-test it.** Suggest `/plumbbob:refine` to attack the frame for holes (or
    to repair the plan as it drifts). Optional, the human's call.
 
+## The cold read
+
+The plan pause ends on your recommendation, and the recommendation is an estimate made
+with fresh eyes, not a re-reading of your own plan. Before you relay the card, give the
+framed plan one bounded adversarial pass under a fixed lens, the pass `/plumbbob:refine`'s
+attack mode makes, but without its writing: surface, never append. Edit nothing, add no
+Open questions, and keep it to one screen of reading. The lens:
+
+- an ambiguity a builder would have to guess through;
+- an edge case or a hidden assumption no Decision settles;
+- a collision with the existing code (read the files the seams name);
+- a done-when no test or check can measure, or a seam that names a file that does not
+  exist or misses one that must change;
+- a step too large to review in one pass, or a Decision with no *because*.
+
+Write what you found into `.plumbbob/detail.md`, overwriting whatever a past session
+left, the findings first and the recommendation last:
+
+```markdown
+# Detail · Plan · <the title>
+
+## 1 <the first hole: one sentence, naming where it sits in intent.md>
+<what it is, and what closing it would take>
+
+## 2 ...
+
+## Recommendation
+
+<The move.> <The reason, one or two sentences.>
+```
+
+The recommendation takes one of two shapes. A sound plan gets `Approve it.` and what the
+read checked and found sound. A plan with a hole gets `Sharpen <the one worst hole> first.`
+and why it matters; when the read found more than one, say how many sit behind `expand`
+and name `/plumbbob:refine` as the move that writes them up as Open questions, with their
+plain and lean sub-lines, for the human to settle. Three findings at most; the rest is
+refine's. `plumbbob handoff --plan` prints the label and your recommendation as the turn's
+last text, "expand 2" opens `## 2`, and `checkpoint --plan` records the read beneath the
+plan's line in the build-log's `## Log`, the build's first entry. The cold read is the tip of refine: it makes the
+full attack discoverable at the moment it would pay, and lets a sound plan skip it. Refine
+is where the real adversary looks; this is an estimate, and it says so by staying short.
+
 ## The interview (mode 1)
 
 Make it easy and non-intrusive:

package/skills/recover/SKILL.md

@@ -4,14 +4,14 @@ description: "Human-triggered driver for `plumbbob recover`; reconcile the contr
 argument-hint: "[--fix]"
 disable-model-invocation: true
 model: haiku
-allowed-tools: Bash(plumbbob status:*), Bash(plumbbob recover:*)
+allowed-tools: Bash(plumbbob status:*), Bash(plumbbob recover:*), Bash(plumbbob handoff:*)
 ---
 
 # PlumbBob: reconcile the control plane (driver)
 
 Current session state (injected when this skill runs): !`plumbbob status 2>/dev/null || echo "plumbbob CLI not on PATH in this session. Marketplace install: confirm the plugin is enabled in /plugin, then /reload-plugins. Skills-dir/global install: npm i -g plumbbob && plumbbob init."`
 
-This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob recover` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; its only action is to shell the verb and report the verb's output verbatim, including any refusal. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
+This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob recover` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; it shells the verb, relays its output verbatim (including any refusal), and closes on `plumbbob handoff`'s next-up pointer for the turn. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
 
 Reach for it when the dashboard and reality disagree: `status` shows a build you thought you finished, or an empty plan for a build you know you wrote, or a step in flight you have no memory of starting. Those are the shapes a crashed session, a lost context window, or a mid-step build switch leaves behind. `/plumbbob:doctor` answers "is plumbbob installed correctly"; this answers "is this session's own state telling the truth".
 
@@ -20,6 +20,7 @@ Reach for it when the dashboard and reality disagree: `status` shows a build you
 1. Run `plumbbob recover` via Bash. It reads the control plane (the active-build cursor, the step and spike markers, the latch's stamp, the agent handoff ledger, and any leftover spike worktrees) and prints one line per check.
 2. Report that output verbatim, `✓` and `✗` lines alike. Every problem carries a `→` line naming the fix; relay those as written rather than paraphrasing them into your own advice.
 3. **Only if the human asks for the repair**, run `plumbbob recover --fix`. It clears stale untracked control files and re-points a cursor when exactly one build survives. It never touches intent.md, the build log, the checkpoints ledger, a report, or git history, and it never lands or advances a step.
+4. Close on `plumbbob handoff --driver`'s next-up line (the driver tier of the [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)): a readout that just told the human their state was off ends on one pointer to reorient them, back at the open step when one survives and forward from the boundary otherwise.
 
 ## What it will not do for you
 

package/skills/revert/SKILL.md

@@ -11,10 +11,11 @@ allowed-tools: Bash(plumbbob status:*), Bash(plumbbob revert:*)
 
 Current session state (injected when this skill runs): !`plumbbob status 2>/dev/null || echo "plumbbob CLI not on PATH in this session. Marketplace install: confirm the plugin is enabled in /plugin, then /reload-plugins. Skills-dir/global install: npm i -g plumbbob && plumbbob init."`
 
-This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob revert` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; its only action is to shell the verb and report the verb's output verbatim, including any refusal. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
+This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob revert` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; it shells the verb and relays its output verbatim, refusal included. A successful transition prints its whole ending, pointer and all, so one command is the whole turn. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
 
 ## What it does
 
 1. Read an optional target step from the way you were invoked (for example `/plumbbob:revert --to 2` → step `2`). With no target, revert goes to the last done-checkpoint.
 2. Run `plumbbob revert` (or `plumbbob revert --to <n>`) via Bash. This is a `git reset --hard`; it discards the current in-progress step *and its work*. If the human wants to drop the step but keep the working-tree diff, that is `/plumbbob:abandon`, not revert. Run it exactly as the human asked; do not add or drop the `--to` on your own.
 3. Report the verb's output verbatim: which checkpoint it reset to, or any refusal.
+4. A successful revert prints its own ending (the driver tier of the [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)): the lead line, a blank line, and the pointer forward from the boundary, since the in-flight step is wound back. Relay that block whole and run no second command. A refusal is not a transition; it carries no pointer, so relay it and stop.

package/skills/spike/SKILL.md

@@ -11,13 +11,14 @@ allowed-tools: Bash(plumbbob status:*), Bash(plumbbob spike:*)
 
 Current session state (injected when this skill runs): !`plumbbob status 2>/dev/null || echo "plumbbob CLI not on PATH in this session. Marketplace install: confirm the plugin is enabled in /plugin, then /reload-plugins. Skills-dir/global install: npm i -g plumbbob && plumbbob init."`
 
-This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob spike` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; its only action is to shell the verb and report the verb's output verbatim, including any refusal. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
+This is a **driver skill**: a chat-side trigger for the mechanical `plumbbob spike` verb, so the whole workflow runs from the agent window instead of a terminal. It is `disable-model-invocation: true`: only the human fires it. It carries **no Edit and no Write tool**; it shells the verb and relays its output verbatim, refusal included. A successful transition prints its whole ending, pointer and all, so one command is the whole turn. The CLI is the source of truth: never retry a refused transition, and never edit a file to work around one.
 
 ## What it does
 
 1. Read the spike target from the way you were invoked: a slug to open one (for example `/plumbbob:spike redis-cache`), `report <slug>` to scaffold a report without worktrees (`/plumbbob:spike report auth-store`), or the literal `done` to tear the current spike down (`/plumbbob:spike done`). If none is present, ask which and run nothing.
 2. Run `plumbbob spike "<slug>"`, `plumbbob spike report "<slug>"`, or `plumbbob spike done` via Bash.
-3. Report the verb's output verbatim: the worktree it created or removed, the spike report it scaffolded, or any refusal. When the verb names a `spike-NN-<slug>.md` report, point the human at it; when `spike done` nudges that a verdict is unrecorded, relay that nudge verbatim.
+3. Report the verb's output verbatim: the worktree it created or removed, the spike report it scaffolded, or any refusal. When the verb names a `spike-NN-<slug>.md` report, point the human at it; when `spike done` nudges that a verdict is unrecorded, that nudge is already inside the block, so relay it there rather than restating it.
+4. A successful transition prints its own ending (the driver tier of the [turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)): the lead line, any nudge, and the pointer, which names closing the spike while one is live and points forward from the boundary once `spike done` closes it. Relay that block whole and run no second command. A refusal is not a transition; it carries no pointer, so relay it and stop.
 
 ## The spike report ([D70 (spike-reports)](https://github.com/robmclarty/plumbbob/blob/main/docs/decisions.md#d70))
 

package/skills/status/SKILL.md

@@ -16,11 +16,19 @@ inferred next move. Report it verbatim and point the human at that next move. Th
 skill carries **no Edit and no Write tool**: the CLI is the source of truth, so
 **never retry**, and never edit a file to change what the orientation says.
 
+Status is an orientation turn (the
+[turn anatomy](https://github.com/robmclarty/plumbbob/blob/main/docs/presentation.md)):
+the dashboard is the whole output, relayed verbatim. Everything the human needs is
+already in those bytes: the step in flight, the next step's done-when, seam, and `model:`
+recommendation, the counts, and the one next move. You relay it; you do not re-compose or
+annotate it.
+
 ## What it does
 
-1. Surface the injected `status` output: the dashboard and its suggested next move.
-2. If the next step's detail carries a `model:` line, point it out: it is the
-   plan's recommendation of the smallest model that can carry that step, so the human
-   can switch (for example `/model sonnet`) before firing `/plumbbob:build`, or ignore it. Guidance,
-   never a gate.
+1. Surface the injected `status` output verbatim: the dashboard and its suggested next move.
+2. The dashboard already prints the next step's `model:` recommendation in its detail
+   rows when the plan set one: the smallest model that can carry that step, so the human
+   can switch (for example `/model sonnet`) before firing `/plumbbob:build`, or ignore it.
+   Guidance, never a gate. You relay that line; you do not re-state it on top of the
+   verbatim dashboard.
 3. If it reads `NO ACTIVE SESSION`, tell the human to `/plumbbob:plan` to frame a goal.