plumbbob 0.8.17 → 0.9.1

package/skills/{pb-refine → refine}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-refine
+name: refine
 description: Keep intent.md true — attack the plan for holes (append as Open questions) and refine or repair the Frame, Decisions, Constraints, and Steps to match reality. Usable at any point; you propose, the human approves.
 argument-hint: "[focus]"
 disable-model-invocation: true
@@ -10,16 +10,16 @@ allowed-tools: Read, Edit, Bash(plumbbob status:*)
 
 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."`
 
-`/pb-refine` keeps `intent.md` honest. Use it at **any point** — right after `/pb-plan`
+`/plumbbob:refine` keeps `intent.md` honest. Use it at **any point** — right after `/plumbbob:plan`
 to stress-test a fresh frame, or mid-build to repair a plan that drifted from what the
-code is actually doing. It is the document-level complement to `/pb-step` (which only
-sharpens the *next* step): `/pb-refine` works the *whole* plan.
+code is actually doing. It is the document-level complement to `/plumbbob:step` (which only
+sharpens the *next* step): `/plumbbob:refine` works the *whole* plan.
 
 ## No-session refusal
 
 This skill refines an existing plan, so it needs one. Read the state injected above: if
 it is `NO ACTIVE SESSION`, **refuse** in one line and tell the human to run
-`plumbbob start "<title>"` (or `/pb-plan`) first, and edit nothing. Every active state
+`plumbbob start "<title>"` (or `/plumbbob:plan`) first, and edit nothing. Every active state
 is fine — refining is always available.
 
 ## Two modes
@@ -56,5 +56,5 @@ is fine — refining is always available.
   approves every change to `intent.md`. Never guess a hole into a Decision.
 - **Open questions for holes, edits for drift.** New uncertainty goes to
   `## Open questions`; settled drift gets repaired in place once the human OKs it.
-- **Refine the plan, not the code.** `/pb-refine` touches `intent.md` only — turning a
-  decision into a diff is `/pb-build` or your own hands, never this skill.
+- **Refine the plan, not the code.** `/plumbbob:refine` touches `intent.md` only — turning a
+  decision into a diff is `/plumbbob:build` or your own hands, never this skill.

package/skills/{pb-revert → revert}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-revert
+name: revert
 description: Human-triggered driver for `plumbbob revert` — git reset --hard to a checkpoint SHA (discarding the half-done step) and return to the boundary.
 argument-hint: "[--to <step>]"
 disable-model-invocation: true
@@ -15,6 +15,6 @@ This is a **driver skill** — a chat-side trigger for the mechanical `plumbbob
 
 ## What it does
 
-1. Read an optional target step from the way you were invoked (e.g. `/pb-revert --to 2` → step `2`). With no target, revert goes to the last done-checkpoint.
+1. Read an optional target step from the way you were invoked (e.g. `/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. 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.

package/skills/{pb-spike → spike}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-spike
+name: spike
 description: Human-triggered driver for `plumbbob spike` — open a throwaway worktree experiment for a genuine fork, scaffold a spike report for a spike-as-step, or tear it down with `spike done`.
 argument-hint: "<slug> | report <slug> | done"
 disable-model-invocation: true
@@ -15,7 +15,7 @@ This is a **driver skill** — a chat-side trigger for the mechanical `plumbbob
 
 ## What it does
 
-1. Read the spike target from the way you were invoked: a slug to open one (e.g. `/pb-spike redis-cache`), `report <slug>` to scaffold a report without worktrees (`/pb-spike report auth-store`), or the literal `done` to tear the current spike down (`/pb-spike done`). If none is present, ask which and run nothing.
+1. Read the spike target from the way you were invoked: a slug to open one (e.g. `/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.
 
@@ -23,7 +23,7 @@ This is a **driver skill** — a chat-side trigger for the mechanical `plumbbob
 
 Every spike leaves a durable `spike-NN-<slug>.md` in the build folder, beside `intent.md`/`report.md`, so the fork's verdict rides the branch into the PR instead of evaporating. The CLI scaffolds it from a template and numbers it — you never create or number the file:
 
-- **`/pb-spike <slug>`** scaffolds the report *at open*, so findings accrue while the throwaway worktrees are still live. Fill its **Findings** and **Verdict** before `/pb-spike done`.
-- **`/pb-spike report <slug>`** is for a *spike-as-step* — a planned step titled `spike: …`, where the increment itself is the experiment and there are no worktrees. It stamps the report's provenance as `step <n>` when a step is in flight.
+- **`/plumbbob:spike <slug>`** scaffolds the report *at open*, so findings accrue while the throwaway worktrees are still live. Fill its **Findings** and **Verdict** before `/plumbbob:spike done`.
+- **`/plumbbob:spike report <slug>`** is for a *spike-as-step* — a planned step titled `spike: …`, where the increment itself is the experiment and there are no worktrees. It stamps the report's provenance as `step <n>` when a step is in flight.
 
 This skill stays Write-less: the CLI owns the file. Your job is to run the verb and, between runs, help the human fill the report's prose — but the edits land through the normal build flow, not this driver.

package/skills/{pb-status → status}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-status
+name: status
 description: Show the orientation dashboard — where you are, what's done, what's parked, and the next move. A thin trigger for `plumbbob status`.
 disable-model-invocation: true
 model: haiku
@@ -21,6 +21,6 @@ skill carries **no Edit and no Write tool**: the CLI is the source of truth, so
 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 (e.g. `/model sonnet`) before firing `/pb-build` — or ignore it. Guidance,
+   can switch (e.g. `/model sonnet`) before firing `/plumbbob:build` — or ignore it. Guidance,
    never a gate.
-3. If it reads `NO ACTIVE SESSION`, tell the human to `/pb-plan` to frame a goal.
+3. If it reads `NO ACTIVE SESSION`, tell the human to `/plumbbob:plan` to frame a goal.

package/skills/{pb-step → step}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-step
+name: step
 description: Revise the next increment just-in-time — sharpen the next undone step against what's now true, or (with input) re-cut, split, or add a step. Empty input runs an automatic sharpen. One at a time; the human approves.
 argument-hint: "[what-changed]"
 disable-model-invocation: true
@@ -10,21 +10,21 @@ allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob agent l
 
 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."`
 
-`/pb-plan` authors the **whole** step list up front, so `/pb-step` is the
+`/plumbbob:plan` authors the **whole** step list up front, so `/plumbbob:step` is the
 **just-in-time revision** move: it keeps the *next* undone step honest against what the
-build has actually taught you, right before you `/pb-build` it. (Framing the whole goal
-is the separate `/pb-plan` move.) It can also add or re-cut a step when scope genuinely
+build has actually taught you, right before you `/plumbbob:build` it. (Framing the whole goal
+is the separate `/plumbbob:plan` move.) It can also add or re-cut a step when scope genuinely
 grew — but its everyday job is to sharpen, not to invent.
 
 ## Two ways to fire it
 
-- **`/pb-step` (no input) → automatic sharpen.** Re-examine the next undone step
+- **`/plumbbob:step` (no input) → automatic sharpen.** Re-examine the next undone step
   against the completed code, the Decisions, the Constraints, and the build-log, then
   make the obvious revisions to its **done-when** and **seam** so it matches reality —
   e.g. a file moved, a decision narrowed the scope, an earlier step already did part of
   it. This is the zero-effort "keep my next step in sync" move: if the human does
   nothing else, the next step stays current.
-- **`/pb-step <what changed>` → directed revision.** Take the human's input and propose
+- **`/plumbbob:step <what changed>` → directed revision.** Take the human's input and propose
   the matching change: tighten the done-when, adjust the seam, split the step in two, or
   add a new increment the plan was missing.
 
@@ -33,7 +33,7 @@ grew — but its everyday job is to sharpen, not to invent.
 1. **Read the plan and the reality.** Read `intent.md`'s Frame, Decisions, Constraints,
    and the steps already done, plus the next undone step, to see what it *should* now be.
 2. **Propose the revision** (or the new/split step): a one-line **title**, a **done-when**
-   `/pb-verify` can validate, and a **seam** (exact paths, or a `dir/` grant). Keep it
+   `/plumbbob:verify` can validate, and a **seam** (exact paths, or a `dir/` grant). Keep it
    small enough to verify in one review pass. Show the before/after so the human can see
    what you changed and why. Re-check the optional `- model:` recommendation too:
    a step that sharpened into rote work can drop to a smaller model; one that grew subtle
@@ -53,14 +53,14 @@ grew — but its everyday job is to sharpen, not to invent.
    build carries a `harness.json` (beside `intent.md`) and the reality that moved the
    step also changed which agents it wants, sharpen that step's slot bindings
    (`before`/`build`/`after`) and `note` at the same time — this is the just-in-time
-   counterpart to `/pb-plan`'s plan-time binding. `plumbbob agent list` shows what's
+   counterpart to `/plumbbob:plan`'s plan-time binding. `plumbbob agent list` shows what's
    resolvable. Same rule as the plan move: bindings + prose only, never a conditional
   . Leave it untouched when the step's agents are still right, or when the build
    uses none.
 
 ## The hard contracts
 
-- **One verifiable increment.** Each step carries a done-when `/pb-verify` can check
+- **One verifiable increment.** Each step carries a done-when `/plumbbob:verify` can check
   and a seam small enough to review in one pass.
 - **Edit `## Steps` only**, in the standard format `status` and `build` parse — never
   the Roadmap, never loose prose. A done step (`[x]`) is history; do not rewrite it.

package/skills/{pb-verify → verify}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pb-verify
+name: verify
 description: "The verify tick — run the check, self-review the diff against intent, validate the step's done-when, pause for your approval, then checkpoint. Executor-agnostic: it reads the diff, not who wrote it."
 disable-model-invocation: true
 allowed-tools: Read, Bash(plumbbob status:*), Bash(plumbbob handoff:*), Bash(plumbbob check:*), Bash(plumbbob checkpoint:*), Bash(plumbbob agent:*), Bash(git diff:*), Bash(git status:*)
@@ -10,7 +10,7 @@ allowed-tools: Read, Bash(plumbbob status:*), Bash(plumbbob handoff:*), Bash(plu
 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 the **tick** — the one beat where the human is the clock. Whatever produced
-the current diff — `/pb-build`, your own hands, a vibe session, another harness —
+the current diff — `/plumbbob:build`, your own hands, a vibe session, another harness —
 this skill verifies it the same way: **it reads the diff, not the author**.
 
 ## What this skill does, in order
@@ -31,7 +31,7 @@ this skill verifies it the same way: **it reads the diff, not the author**.
    `summary`/`body` into the review below; route a non-`done` one by its status: a
    `blocked` agent couldn't finish — surface its `notes`, let the human unblock, re-run;
    a `drift` agent found the plan no longer matches reality — stop and send the human to
-   `/pb-refine` to repair the plan before checkpointing. No binding, or no harness, is a
+   `/plumbbob:refine` to repair the plan before checkpointing. No binding, or no harness, is a
    clean no-op.
 3. **Self-review** *(a single structured read)*. Read `git diff` and
    `.plumbbob/intent.md`, then in one pass check the diff against:
@@ -79,7 +79,7 @@ this skill verifies it the same way: **it reads the diff, not the author**.
    step gone from in-flight it renders `step N checkpointed — back at the boundary` 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
-   firing `/pb-build` again. This matters most across a context boundary: a fresh window
+   firing `/plumbbob:build` again. This matters most across a context boundary: a fresh window
    inherits the *session's* model, not the plan's suggestion, so this line is what carries
    the recommendation over. The CLI owns the block, so it can't drift from what `plumbbob
    status` reports; no `- model:` line means any model will do. Guidance, never a gate.
@@ -94,24 +94,24 @@ the self-review, **end the turn**, and the human's next message is the tick that
 the checkpoint land when you re-fire. **Never reach for a raw `git commit` to force the
 land** — that forges the very record the latch exists to keep honest, and the
 commit-ask hook asks the human about it anyway. The refusal is a healthy latch doing its
-job on the *record* while the *work* plane stays free; a `/pb-build --auto` or
+job on the *record* while the *work* plane stays free; a `/plumbbob:build --auto` or
 a typed step range in the human's own prompt is the only self-approval — **never write
 `auto` into a settings file to unlock the land; the latch ignores a model-minted grant
-(D67), so ask the human to re-fire `/pb-build --auto` instead.**
+(D67), so ask the human to re-fire `/plumbbob:build --auto` instead.**
 
 ## The hard contracts
 
 - **Never skip the pause.** Check → self-review → validate, then wait. Approval is
   the only thing that triggers the checkpoint.
 - **Read the diff, not the author**. Verify identically whether the code was
-  built by `/pb-build`, by hand, vibed, or by another harness.
+  built by `/plumbbob:build`, by hand, vibed, or by another harness.
 - **Red means stop, not pause.** A failing check is not an approval decision; report
   it and end your turn.
 - **You review; you do not build.** If the self-review finds a problem, surface it
   and stop — fixing is a new build beat, not part of verify.
 - **`after`-agents advise; they never gate**. Their output feeds the
   self-review — checkride gates, the human approves. `blocked` → unblock and re-run;
-  `drift` → `/pb-refine` before checkpointing. No code path makes them blocking.
+  `drift` → `/plumbbob:refine` before checkpointing. No code path makes them blocking.
 - **A refused checkpoint is the pause, never a workaround.** Under the turn
   hook a same-turn checkpoint is refused *by design* — present the diff, **end the
   turn**, and let the human's next message re-tick it. Never route around it with a raw

package/templates/build-log.md

@@ -8,7 +8,7 @@ step boundaries. The antidote to "my plan got lost in the noise."
   Park list : where ideas go so you do not chase them. CAPTURE, never act inline.
   Harvest   : the boundary ritual that keeps you on one branch.
   Log       : the build's history. `plumbbob checkpoint` appends a line per step as it
-              lands; feeds the /pb-finish report, which rides the branch into the PR.
+              lands; feeds the /plumbbob:finish report, which rides the branch into the PR.
 -->
 
 # Build log — {{TITLE}}
@@ -21,7 +21,7 @@ step boundaries. The antidote to "my plan got lost in the noise."
 *(Mirror of intent.md's Steps, with live status — CLI-maintained, not hand-edited.
 `build`/`checkpoint`/`revert` re-render this from intent.md, and set the Current step
 line above. Only ONE step is in flight; a step is done only after a checkpoint —
-check green + checkpoint taken, via `/pb-verify` or `/pb-build`.)*
+check green + checkpoint taken, via `/plumbbob:verify` or `/plumbbob:build`.)*
 
 - ☐ 1. <step>
 
@@ -29,16 +29,16 @@ check green + checkpoint taken, via `/pb-verify` or `/pb-build`.)*
 
 > Mid-step, every new problem / idea / "ooh what if" lands HERE, untouched, and you
 > go straight back to the step. Acting the instant an idea arrives is the disease.
-> Capture is one line (`/pb-park` composes it). Harvest happens only at the boundary.
+> Capture is one line (`/plumbbob:park` composes it). Harvest happens only at the boundary.
 
-## Harvest  *(run `/pb-harvest` at each step boundary, after green)*
+## Harvest  *(run `/plumbbob:harvest` at each step boundary, after green)*
 
 Classify each parked item as exactly ONE. Naming it before acting is what keeps you
 from sprawling across branches.
 
 | Class            | Meaning                                   | Action                          |
 |------------------|-------------------------------------------|---------------------------------|
-| **blocker**      | Plan was wrong/incomplete; can't proceed  | `/pb-revert`, fold into intent  |
+| **blocker**      | Plan was wrong/incomplete; can't proceed  | `/plumbbob:revert`, fold into intent  |
 | **tangent**      | A different path, not clearly better      | Defer or kill. Default here.    |
 | **pivot signal** | Evidence the whole approach is wrong      | Stop. Replan deliberately.      |
 
@@ -52,8 +52,8 @@ Harvest results this boundary:
 ## Log
 
 *(The build's history, oldest first. `plumbbob checkpoint` appends a dated line here
-every time a step lands — via `/pb-build` or `/pb-verify` — so this
+every time a step lands — via `/plumbbob:build` or `/plumbbob:verify` — so this
 fills in as you go, not at the end. Add your own decision/event lines too: this is what
 you point at to say "I did that — the LLM helped, but those were my calls."
-`/pb-finish` reads this for the report; `plumbbob finish` commits it with the build
+`/plumbbob:finish` reads this for the report; `plumbbob finish` commits it with the build
 folder, so it rides the branch into the PR.)*

package/templates/intent.md

@@ -38,7 +38,7 @@ reads them once, to decide, and that legibility buys back a chat round-trip.
 ## Decisions
 
 *(One line each — settled, not re-litigated in the chat. Grows as you resolve the
-holes `/pb-refine` surfaces, and as blockers fold in during BUILD. Mint a two- or
+holes `/plumbbob:refine` surfaces, and as blockers fold in during BUILD. Mint a two- or
 three-word slug where each item is born — `D1 (slug-here)` — and copy that slug at
 every reference site, so a later `D4 (default-waves)` never decays into a bare `D4`
 a cold reader has to hunt down.)*
@@ -47,28 +47,28 @@ a cold reader has to hunt down.)*
 
 ## Constraints
 
-*(Hard rules the build must honor. `/pb-verify` and `/pb-refine` read against these.
+*(Hard rules the build must honor. `/plumbbob:verify` and `/plumbbob:refine` read against these.
 Slug and gloss them at birth too — `C1 (no-new-deps)` — same one line, same rule.)*
 
 - C1 (no-new-deps): <e.g. functional/procedural only; no new dependencies>
 
 ## Steps
 
-*(The build plan. `/pb-plan` authors the **whole list up front** — each step a small,
+*(The build plan. `/plumbbob:plan` authors the **whole list up front** — each step a small,
 verifiable increment with its own **done-when** and **seam** (the paths it will touch,
-which `/pb-build` records in the build folder's `SEAM` for orientation — awareness, not a lock).
+which `/plumbbob:build` records in the build folder's `SEAM` for orientation — awareness, not a lock).
 An optional **model** line recommends the smallest model that can carry the step —
 mechanical work runs fine on a small model; subtle or creative work earns a frontier
 one. Advisory for the human, never a gate; write it plain, no backticks (D62).
 The step title *is* the checkpoint's commit subject: write it as one plain line,
 `type(scope): description` — load-bearing paths live in `seam`, never jammed into the
 title (D2) — aiming for ≤72 characters (GitHub's subject convention: soft, no gate, D9).
-The `(scope)` names the primary code area the step touches (`pb-plan`, `commitmsg`); the
+The `(scope)` names the primary code area the step touches (`plan`, `commitmsg`); the
 build's `**Scope:**` header is the feature-level catch-all a step overrides (D8). Scope
 resolves title-scope → `**Scope:**` default → build slug → bare, and type resolves
-title-type → `feat` (D3/D68). Then drive `/pb-build` until done. Later steps may be
-fuzzier than the first; sharpen the next one just-in-time with `/pb-step` (empty input
-auto-syncs it), and use `/pb-refine` to repair the whole plan when a blocker rewrites it.)*
+title-type → `feat` (D3/D68). Then drive `/plumbbob:build` until done. Later steps may be
+fuzzier than the first; sharpen the next one just-in-time with `/plumbbob:step` (empty input
+auto-syncs it), and use `/plumbbob:refine` to repair the whole plan when a blocker rewrites it.)*
 
 1. [ ] feat: <step> — **done when:** <criterion, ideally a test or check result>
    - seam: `<file>`, `<file>`

package/templates/spike-report.md

@@ -5,7 +5,7 @@ folder into the PR beside intent.md / report.md. Fill it while the experiment is
 — the worktrees and their learnings are torn down at `spike done`, but this stays.
 
 Two ways a spike is born, both landing here:
-  - `/pb-spike <slug>` — an explicit mid-build fork with throwaway worktrees.
+  - `/plumbbob:spike <slug>` — an explicit mid-build fork with throwaway worktrees.
   - a planned step titled `spike: …` — the increment IS the experiment.
 Record the Verdict before you close the spike (or check off the step).
 -->