plumbbob 0.8.18 → 0.9.1

package/dist/verbs/turn.js

@@ -1,16 +1,26 @@
-// `plumbbob turn` — the turn-ledger hook (D64). Wired to Claude Code's
-// UserPromptSubmit, it runs once per human prompt: it ticks `.plumbbob/TURN` (the
-// monotonic count of human turns the checkpoint latch reads to know a human turn
-// intervened since a step began) and rewrites `.plumbbob/GRANT` from the literal
-// prompt — minting a one-turn self-approval only when the human typed
-// `/pb-build --auto` or a `N-M` range (D65), clearing it otherwise. When a step is
-// in flight it also emits ONE `UserPromptSubmit` additionalContext line so a fresh
-// session (post-compaction, or a new `-p` turn where no skill is in context) still
-// knows the beat — a tangent is parked, not chased (amends D64's "writes nothing";
-// guidance only, D10/D13). It ALWAYS exits 0 and any failure degrades to no output,
-// so neither the tick nor the emit can ever wedge prompting (C3).
+// `plumbbob turn` — the turn-ledger hook. Wired to the harness's
+// UserPromptSubmit event, it runs once per human prompt and maintains two of the
+// sidecar's git-excluded control files (flat files under `.plumbbob/`): it ticks
+// `TURN`, the monotonic count of human turns the checkpoint latch compares
+// against a step's entry stamp to know a human turn intervened since the step
+// began, and it rewrites `GRANT` from the literal prompt — minting a one-turn
+// self-approval only when the human typed `/build --auto` or an `N-M` step
+// range, clearing it otherwise (those strings can only come from a human
+// keystroke, because `build` is disable-model-invocation — a grant the model
+// could forge would be no grant). When a step is in flight it also emits ONE
+// `UserPromptSubmit` additionalContext line so a fresh session (post-compaction,
+// or a scripted `-p` turn where no skill prose is in context) still knows the
+// beat — a tangent is parked, not chased. Guidance only: it blocks nothing. It
+// ALWAYS exits 0 and any failure degrades to no output, so neither the tick nor
+// the emit can ever wedge prompting.
 import { readFileSync, writeFileSync } from 'node:fs';
 import { findSessionRoot, setGrant, stepPath, turnPath } from "../lib/sidecar.js";
+/**
+ * The hook entry point: apply the tick, then emit the in-flight-step nudge.
+ *
+ * Always returns 0 — a broken turn must never wedge a prompt, so any failure is
+ * swallowed and degrades to no output.
+ */
 export function turn(cwd, _args) {
     try {
         applyTurn(cwd, readStdin());
@@ -19,15 +29,20 @@ export function turn(cwd, _args) {
             process.stdout.write(context);
     }
     catch {
-        // C3: a broken turn must never wedge a prompt — swallow and exit 0.
+        // A broken turn must never wedge a prompt — swallow and exit 0.
     }
     return 0;
 }
-// The `UserPromptSubmit` additionalContext payload when a step is in flight (a STEP
-// marker between `build` and `checkpoint`), or null. Guidance only: it reminds a
-// fresh session that a tangent is a park (not an edit) and how the step lands, since
-// the pb-build prose may not be in context after compaction or on a scripted turn.
-// Exported because an in-process test cannot read the hook's real stdout.
+/**
+ * The `UserPromptSubmit` additionalContext payload when a step is in flight, or null.
+ *
+ * A step is in flight when a STEP marker (the flat control file recording the
+ * step between `build` and `checkpoint`) is present. Guidance only: it reminds a
+ * fresh session that a tangent is a park (not an edit) and how the step lands,
+ * since the build prose may not be in context after compaction or on a
+ * scripted turn. Exported because an in-process test cannot read the hook's
+ * real stdout.
+ */
 export function stepInFlightContext(cwd) {
     const root = findSessionRoot(cwd);
     if (root === null)
@@ -40,8 +55,12 @@ export function stepInFlightContext(cwd) {
         `It lands when you run \`plumbbob checkpoint ${step}\` after approval.`;
     return `${JSON.stringify({ hookSpecificOutput: { hookEventName: 'UserPromptSubmit', additionalContext: text } })}\n`;
 }
-// The in-flight step number, or null when no STEP marker is present (no step entered,
-// or it already checkpointed). A garbled marker reads as null — never an error (C3).
+/**
+ * The in-flight step number, or null when no STEP marker is present.
+ *
+ * Absent means no step entered, or it already checkpointed. A garbled marker
+ * reads as null — never an error, because the hook must not wedge a prompt.
+ */
 function inFlightStep(root) {
     try {
         const n = Number.parseInt(readFileSync(stepPath(root), 'utf8').trim(), 10);
@@ -51,9 +70,13 @@ function inFlightStep(root) {
         return null;
     }
 }
-// The testable core: apply one tick given the raw hook stdin. Split from the fd-0
-// read so the unit tests can drive it directly — an in-process test cannot feed fd 0
-// (the same constraint checkpoint's `--body` lives under).
+/**
+ * The testable core: apply one tick given the raw hook stdin.
+ *
+ * Split from the fd-0 read so the unit tests can drive it directly — an
+ * in-process test cannot feed fd 0 (the same constraint checkpoint's `--body`
+ * lives under).
+ */
 export function applyTurn(cwd, raw) {
     const root = findSessionRoot(cwd);
     if (root === null)
@@ -62,21 +85,31 @@ export function applyTurn(cwd, raw) {
     setGrant(root, grantFromPrompt(extractPrompt(raw)));
     return 0;
 }
-// GRANT is minted only from a literal `pb-build` invocation the human typed:
-// `pb-build` is disable-model-invocation, so this string can only come from a human
-// keystroke, never model-authored pressure (D65). A bounded range beats `--auto`
-// (bounded wins); a bare `/pb-build`, or any non-invocation prompt, mints nothing.
-// The namespaced `/plumbbob:pb-build` form is honored alongside the bare one.
-//
-// Only the invocation's own arguments can mint: the tokens that follow it on its
-// line, up to the first token that isn't a sanctioned argument (`--auto`, a step
-// number, or a range — the argument-hint sanctions nothing else). An unrecognized
-// flag ends the scan, so `/pb-build --wip 2020-2024` mints nothing — the `2020-2024`
-// is never reached. An incidental range elsewhere in the prompt — an issue number, a
-// pasted `2020-2024` — is prose, not a grant. Trailing sentence punctuation on an
-// argument (`/pb-build 1-3.`) is still the argument the human typed.
+/**
+ * Derive the GRANT content from the human's prompt, or null to clear it.
+ *
+ * A grant is minted only from a literal `build` invocation the human typed:
+ * `build` is disable-model-invocation, so this string can only come from a
+ * human keystroke, never model-authored pressure — a grant the model can forge
+ * is no grant. A bounded range beats `--auto` (bounded wins); a bare
+ * `/build`, or any non-invocation prompt, mints nothing. The namespaced
+ * `/plumbbob:build` form is honored alongside the bare one.
+ *
+ * The invocation must *start* a token: a slash preceded by a word character,
+ * `/`, `.`, `-`, or `~` is a path segment (`src/build`, `./build`), not a
+ * command the human fired, so it mints nothing.
+ *
+ * Only the invocation's own arguments can mint: the tokens that follow it on
+ * its line, up to the first token that isn't a sanctioned argument (`--auto`, a
+ * step number, or a range — the argument-hint sanctions nothing else). An
+ * unrecognized flag ends the scan, so `/build --wip 2020-2024` mints
+ * nothing — the `2020-2024` is never reached. An incidental range elsewhere in
+ * the prompt — an issue number, a pasted `2020-2024` — is prose, not a grant.
+ * Trailing sentence punctuation on an argument (`/build 1-3.`) is still the
+ * argument the human typed.
+ */
 export function grantFromPrompt(prompt) {
-    const invocation = /\/(?:plumbbob:)?pb-build\b/.exec(prompt);
+    const invocation = /(?<![\w/.~-])\/(?:plumbbob:)?build\b/.exec(prompt);
     if (invocation === null)
         return null;
     const line = prompt.slice(invocation.index + invocation[0].length).split('\n', 1)[0] ?? '';
@@ -103,10 +136,13 @@ export function grantFromPrompt(prompt) {
         return `range ${ceiling}`;
     return auto ? 'auto' : null;
 }
-// Extract the `prompt` field from the UserPromptSubmit JSON, or '' when the input is
-// absent, unparseable, or carries no string prompt. Malformed input contributes
-// nothing (D27): the tick still lands (a human turn did occur) and the empty prompt
-// clears any GRANT; the verb never throws over bad stdin.
+/**
+ * Extract the `prompt` field from the UserPromptSubmit JSON, or '' otherwise.
+ *
+ * Absent, unparseable, or non-string input contributes nothing rather than
+ * wedging the tool: the tick still lands (a human turn did occur) and the empty
+ * prompt clears any GRANT; the verb never throws over bad stdin.
+ */
 function extractPrompt(raw) {
     try {
         const parsed = JSON.parse(raw);
@@ -116,8 +152,11 @@ function extractPrompt(raw) {
         return '';
     }
 }
-// The current TURN as a non-negative integer, or 0 when the ledger is absent or
-// unreadable — so the first tick creates it at 1.
+/**
+ * The current TURN count, or 0 when the ledger is absent or unreadable.
+ *
+ * Starting from 0 means the first tick creates the file at 1.
+ */
 function readTurn(root) {
     try {
         const n = Number.parseInt(readFileSync(turnPath(root), 'utf8').trim(), 10);
@@ -127,9 +166,13 @@ function readTurn(root) {
         return 0;
     }
 }
-// Read the hook JSON from fd 0. An interactive TTY never sends EOF, so skip the read
-// there rather than hang (mirrors checkpoint's `--body`); a read error degrades to
-// '' — extractPrompt then clears the grant and the tick still lands.
+/**
+ * Read the hook JSON from fd 0, degrading to '' on any failure.
+ *
+ * An interactive TTY never sends EOF, so skip the read there rather than hang
+ * (mirrors checkpoint's `--body`); a read error degrades to '' — extractPrompt
+ * then clears the grant and the tick still lands.
+ */
 function readStdin() {
     if (process.stdin.isTTY === true)
         return '';

package/dist/verbs/use.js

@@ -1,13 +1,22 @@
-// `plumbbob use <slug>` (D30) — re-point the per-worktree cursor at an existing
-// build and resume it. Both switching and resuming are the same one word (Q10,
-// `nvm use`-shaped): the cursor is STATE's single-line content, so pointing it
-// elsewhere IS the switch and one-active-per-worktree holds by
-// construction (D28). It validates the target folder exists, and warns — but
-// allows — leaving a build with a step in flight: that surviving in-flight state
-// is D26's whole payoff, resumed the next time you `use` that build.
+// `plumbbob use <slug>` — re-point the active-build cursor at an existing build
+// and resume it, `nvm use`-shaped: switching and resuming are the same one word.
+// The cursor is the single-line content of `.plumbbob/STATE`, the untracked
+// per-worktree file whose existence means a session is live and whose one line
+// names the build that session is on — so pointing it elsewhere IS the switch,
+// and one-active-per-worktree holds by construction (one line cannot name two
+// builds). It validates the target folder exists, and warns — but allows —
+// leaving a build with a step in flight: the in-flight markers live per build,
+// so that state survives the switch and resumes the next time you `use` the
+// build.
 import { existsSync } from 'node:fs';
 import { findRepoRoot } from "../lib/git.js";
 import { activeBuild, hasSession, intentPath, listBuilds, setActiveBuild, stepPath } from "../lib/sidecar.js";
+/**
+ * Switch the active-build cursor to the named build.
+ *
+ * Refuses without a session, without a slug, or when the target folder has no
+ * intent.md; notes — but allows — a step left in flight on the build being left.
+ */
 export function use(cwd, args) {
     const root = findRepoRoot(cwd);
     if (root === null || !hasSession(root)) {
@@ -36,8 +45,10 @@ export function use(cwd, args) {
     process.stdout.write(`plumbbob: now on build "${target}"${resuming}. \`status\` to orient.\n`);
     return 0;
 }
-// A trailing " Builds: a, b." hint when any exist, so a bad or missing slug points
-// the user straight at the valid choices.
+/**
+ * A trailing " Builds: a, b." hint when any exist, so a bad or missing slug
+ * points the user straight at the valid choices.
+ */
 function buildsHint(builds) {
     return builds.length > 0 ? ` Builds: ${builds.join(', ')}.` : '';
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "plumbbob",
-  "version": "0.8.18",
+  "version": "0.9.1",
   "description": "Attention-first build process: 12 skills + a CLI that keep you the decider — guidance on the work, a latch on the record.",
   "keywords": [
     "claude-code",

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

@@ -1,6 +1,6 @@
 ---
-name: pb-build
-description: The default engine — read the next planned step from intent, implement it (its done-when, seam, Decisions, Constraints), then verify it through to the approval pause. Swappable — build by hand/vibed/another harness and run /pb-verify instead. `--auto` self-approves and chains to done; a step range like `1-3` self-approves through step 3, then pauses.
+name: build
+description: The default engine — read the next planned step from intent, implement it (its done-when, seam, Decisions, Constraints), then verify it through to the approval pause. Swappable — build by hand/vibed/another harness and run /plumbbob:verify instead. `--auto` self-approves and chains to done; a step range like `1-3` self-approves through step 3, then pauses.
 argument-hint: "[step-number | step-range] [--auto]"
 disable-model-invocation: true
 allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob build:*), Bash(plumbbob handoff:*), Bash(plumbbob check:*), Bash(plumbbob checkpoint:*), Bash(plumbbob park:*), Bash(plumbbob agent:*), Bash(plumbbob spike:*), Bash(git diff:*)
@@ -12,13 +12,13 @@ Current session state (injected when this skill runs): !`plumbbob status 2>/dev/
 
 This is the **bundled executor** — the default engine, not the only one. It is
 **swappable**: you can implement any step by hand, in a vibe session, or with
-another harness and go straight to `/pb-verify` instead — plumbbob does not care how
+another harness and go straight to `/plumbbob:verify` instead — plumbbob does not care how
 the diff appeared. When you do run it, it reads the plan, writes the step, and
 carries straight through to the verify pause.
 
-Since `/pb-plan` lays down the whole step list up front, the happy path is to fire
-`/pb-build` once per step until done — each run builds the next undone step and stops
-at the pause for your approval. **Re-firing `/pb-build` is itself the clock tick.**
+Since `/plumbbob:plan` lays down the whole step list up front, the happy path is to fire
+`/plumbbob:build` once per step until done — each run builds the next undone step and stops
+at the pause for your approval. **Re-firing `/plumbbob:build` is itself the clock tick.**
 
 A model note: this skill **inherits the session model** — nothing pins or switches
 it. If the step you're about to build carries a `- model:` recommendation that
@@ -27,14 +27,14 @@ differs from the model you're running as, say so before implementing — the hum
 
 ## What this skill does, in order
 
-1. **Pick the step.** Use the number you were invoked with (e.g. `/pb-build 4`) — or,
-   if you were given a range like `/pb-build 1-3`, start at the first number and treat
+1. **Pick the step.** Use the number you were invoked with (e.g. `/plumbbob:build 4`) — or,
+   if you were given a range like `/plumbbob:build 1-3`, start at the first number and treat
    the second as the auto-approve ceiling (see the range note under `--auto`). With no
    argument, don't resolve the next step yourself — the CLI does: bare `plumbbob build`
-   (step 2) enters the next undone step and refuses with a `/pb-step` nudge when every
+   (step 2) enters the next undone step and refuses with a `/plumbbob:step` nudge when every
    step is checkpointed.
 2. **Enter the step.** Run `plumbbob build <n>` — or bare `plumbbob build` to enter the
-   next undone step (records the in-flight STEP + SEAM so `/pb-status` shows the step in
+   next undone step (records the in-flight STEP + SEAM so `/plumbbob:status` shows the step in
    flight; the seam is awareness, not a lock).
    - **Spike-as-step.** If the step's title opens with `spike:` / `Spike:`, the increment
      *is* the experiment — resolving a fork the plan couldn't settle on paper. After
@@ -42,7 +42,7 @@ differs from the model you're running as, say so before implementing — the hum
      `spike-NN-<slug>.md` in the build folder, stamped `via: step <n>`), then work the
      experiment and record your **Findings** and **Verdict** there. A recorded verdict is
      what the step's done-when should check — the report, not just the code, is the
-     deliverable. This is the same artifact `/pb-spike` produces for a mid-build fork (D70).
+     deliverable. This is the same artifact `/plumbbob:spike` produces for a mid-build fork (D70).
 3. **Read the plan.** Read the step's **done-when**, its **seam**, and the
    **Decisions** and **Constraints** in `intent.md`. Build to *that* — the deciding
    already happened, off the chat.
@@ -61,7 +61,7 @@ differs from the model you're running as, say so before implementing — the hum
      `harness bindings:` block, a `build`-slot agent may author the diff, a `when`-cue may
      fire an agent mid-build, and a non-`done` envelope routes by its status — see
      **§ Running bound agents**.
-5. **Verify, through to the pause.** Run the verify tick exactly as `/pb-verify`
+5. **Verify, through to the pause.** Run the verify tick exactly as `/plumbbob:verify`
    does: `plumbbob check` (on red, read `.check/summary.json` and the failing slot's
    raw output under `.check/` for the actual diagnostics; while iterating on a fix,
    narrow the loop with `plumbbob check --bail --only <slots>` — the checkpoint gate
@@ -94,7 +94,7 @@ differs from the model you're running as, say so before implementing — the hum
    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
-   `/pb-build` only ever starts the *next* step. **Never route around a refusal with a
+   `/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
@@ -102,7 +102,7 @@ differs from the model you're running as, say so before implementing — the hum
    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
-   `/pb-status` reports; you supply only the judgment above it. It already drops the model
+   `/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.
 
@@ -110,7 +110,7 @@ differs from the model you're running as, say so before implementing — the hum
    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 firing `/pb-build` again. It is what
+   human knows which `/model` to select before firing `/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.
@@ -140,7 +140,7 @@ harness *is* bound, this is what each affected step gains, in lifecycle order.
 - **Route a non-`done` envelope by its status (step 4).** An agent that returns `blocked`
   couldn't finish (missing input, failed precondition): surface its `notes`, let the human
   unblock, and re-run it — don't work around it. One that returns `drift` finished but found
-  the plan no longer matches reality: **stop and send the human to `/pb-refine`** to repair
+  the plan no longer matches reality: **stop and send the human to `/plumbbob:refine`** to repair
   the plan before continuing, rather than building on a plan that's now wrong. A non-zero
   exit is a failed run: report it and stop.
 - **`after` — advisory input to the verify tick (step 5).** After `plumbbob check`, run any
@@ -151,7 +151,7 @@ harness *is* bound, this is what each affected step gains, in lifecycle order.
 
 ## `--auto` — let the agent be the clock (opt-in)
 
-`/pb-build --auto` is the explicit escape hatch when the human wants unattended
+`/plumbbob:build --auto` is the explicit escape hatch when the human wants unattended
 progress instead of approving each step. It does the same work, but **the agent reviews
 and approves in the human's place**, and it **chains**:
 
@@ -163,7 +163,7 @@ and approves in the human's place**, and it **chains**:
   `after`-agent output simply feeds the *existing* self-review halt condition.
 - **Stop and hand back to the human** the moment any of these is true: the check is red,
   the self-review finds a mismatch (surface exactly what, and do not checkpoint it), a
-  bound agent returns `blocked` or `drift` (unblock-and-re-run, or `/pb-refine` — an
+  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
@@ -177,7 +177,7 @@ The default — no flag, no range — always ends at the pause.
 
 ### A step range (`N-M`) is a bounded `--auto`
 
-`/pb-build 1-3` self-approves steps 1 through 3 exactly as `--auto` does, then **pauses
+`/plumbbob:build 1-3` self-approves steps 1 through 3 exactly as `--auto` does, then **pauses
 after step 3** instead of chaining to done. The range *is* the opt-in — you do not also
 pass `--auto`. Run it as the `--auto` loop with one extra halt: **stop before building
 any next step whose plan number is past the top of the range.** It adds no machinery —
@@ -195,11 +195,11 @@ just the one more entry already in the halt list above.
   check. Do not skip past the gap.
 - **N is above the next undone step** — you are jumping over earlier planned work; note
   that you are skipping the steps before N, then proceed (the same latitude as a
-  single-number jump like `/pb-build 4`).
+  single-number jump like `/plumbbob:build 4`).
 
 ## The hard contracts
 
-- **Swappable, never required.** The loop works without this skill; `/pb-verify`
+- **Swappable, never required.** The loop works without this skill; `/plumbbob:verify`
   checkpoints a hand-built or vibed diff just the same.
 - **Build the decided step, not a new one.** Implement what `intent.md` settled. A
   new idea mid-build is captured with `plumbbob park`, not an edit — a promise to
@@ -210,17 +210,17 @@ just the one more entry already in the halt list above.
   at its top.
 - **Agents feed the beat; they never advance it**. `before` loads context,
   `build` writes the diff, `after` is advisory — none can checkpoint, flip a step, or
-  chain. `blocked` → unblock and re-run; `drift` → `/pb-refine`. You are still the one
+  chain. `blocked` → unblock and re-run; `drift` → `/plumbbob:refine`. You are still the one
   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
-  it, and landing it is a deliberate beat, not a side effect of the next `/pb-build`.
-  Never route around it with a raw `git commit`. An explicit `/pb-build --auto` or a typed
+  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 since D67); ask the human to re-fire `/pb-build --auto` instead.**
+  latch ignores it since D67); ask the human to re-fire `/plumbbob:build --auto` 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

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

@@ -1,5 +1,5 @@
 ---
-name: pb-doctor
+name: doctor
 description: Diagnose the plugin install from inside a session — is plumbbob linked, are the skills and hook present, is there a collision. A thin trigger for `plumbbob doctor`. Matters most for a marketplace install, where the CLI is on PATH only inside Claude Code.
 disable-model-invocation: true
 model: haiku

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

@@ -1,5 +1,5 @@
 ---
-name: pb-finish
+name: finish
 description: Finish the build — write the report (what shipped, decisions, parked/harvested items, deferred tangents), then make the final commit that closes the session. The build folder rides the branch into the PR — no separate archive. Report by default, no gate.
 disable-model-invocation: true
 allowed-tools: Read, Write, Bash(plumbbob status:*), Bash(plumbbob finish:*)
@@ -9,7 +9,7 @@ allowed-tools: Read, Write, Bash(plumbbob status:*), Bash(plumbbob finish:*)
 
 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-finish` ends the build: it captures what happened, then makes the final commit
+`/plumbbob:finish` ends the build: it captures what happened, then makes the final commit
 that closes the session. **Report by default** — no refuse-without-report gate,
 and no separate docs phase. The build folder is tracked: it merges with the
 branch and shows up in the PR, so there is nothing to archive — the folder *is* the
@@ -48,7 +48,7 @@ record.
    an argument value (`--body "$(cat <<'BODY'…)"`): `--body` ignores an argument and
    reads stdin, so that form leaves stdin open with no EOF and the command hangs. Omit
    `--body` entirely and the commit carries the `plumbbob finish` marker subject only.
-3. **Point at the next goal** — `/pb-plan` to frame the next one.
+3. **Point at the next goal** — `/plumbbob:plan` to frame the next one.
 
 ## The hard contracts
 

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

@@ -1,5 +1,5 @@
 ---
-name: pb-harvest
+name: harvest
 description: Triage the park list at a step boundary — propose one class (blocker/tangent/pivot) per parked item, write only after the human confirms each, record under ## Harvest, and fold a confirmed blocker into intent.
 disable-model-invocation: true
 allowed-tools: Read, Edit, Bash(plumbbob status:*)
@@ -9,7 +9,7 @@ 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-harvest` is the complement of `/pb-park`: you parked ideas as seeds during a
+`/plumbbob:harvest` is the complement of `/plumbbob:park`: you parked ideas as seeds during a
 build; now, at a boundary, you harvest them — decide what each one is.
 
 ## When to run it — boundary only
@@ -19,7 +19,7 @@ DESIGN boundary, not mid-step. Read the dashboard injected above:
 
 - `NO ACTIVE SESSION` — **refuse**; tell the human to `plumbbob start "<title>"` first.
 - A step in flight (the dashboard reads `[BUILD]`, and `next →` points at finishing the
-  step) — **refuse** and suggest finishing it with `/pb-verify` before harvesting.
+  step) — **refuse** and suggest finishing it with `/plumbbob:verify` before harvesting.
   Chasing parked items mid-step is the disease parking prevents.
 - At the boundary (the dashboard reads `[DESIGN]`) — go ahead.
 
@@ -40,7 +40,7 @@ one line of reasoning, then **wait for the human to confirm or override**. Write
 **only after** per-item confirmation:
 
 - Record each confirmed class in `build-log.md`'s `## Harvest` section.
-- **Flip the harvested item** from `- [ ]` to `- [x]` in the Park list, so `/pb-status`
+- **Flip the harvested item** from `- [ ]` to `- [x]` in the Park list, so `/plumbbob:status`
   stops counting it as open.
 - A confirmed **blocker** also folds its decision into `intent.md`.
 - Never reclassify or resolve an item the human hasn't confirmed, and default every

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

@@ -1,5 +1,5 @@
 ---
-name: pb-park
+name: park
 description: Compose one tidy tagged park line, get the human's OK in-turn, then capture it by shelling `plumbbob park` — never by editing a file. The capture half of the park/harvest loop.
 argument-hint: "[idea]"
 disable-model-invocation: true
@@ -11,7 +11,7 @@ allowed-tools: Bash(plumbbob status:*), Bash(plumbbob park:*)
 
 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-park` is the **capture** half of the loop; `/pb-harvest` is where parked items
+`/plumbbob:park` is the **capture** half of the loop; `/plumbbob:harvest` is where parked items
 get triaged later. Capturing the instant an idea arrives — instead of acting on
 it — is the whole point: it protects the step in flight.
 

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

@@ -1,5 +1,5 @@
 ---
-name: pb-plan
+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
@@ -10,10 +10,10 @@ allowed-tools: Read, Edit, Write, Bash(plumbbob status:*), Bash(plumbbob start:*
 
 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` is the **whole-goal** move — it opens a session and gets the deciding out
+`/plumbbob:plan` is the **whole-goal** move — it opens a session and gets the deciding out
 of your head and onto `intent.md` *before* any code. By default it authors the
 **complete plan, including all the Steps**, so the happy path afterward is just
-`/pb-build` until done. (Revising a single increment later is the separate `/pb-step`
+`/plumbbob:build` until done. (Revising a single increment later is the separate `/plumbbob:step`
 move; do not confuse the two.)
 
 A model note: this skill **inherits the session model** — nothing pins or switches
@@ -42,7 +42,7 @@ Look at the argument the human gave and pick the mode yourself:
    genuinely ambiguous.
 
 All three modes converge on the **same artifact**: a complete, standalone `intent.md`
-an agent can follow with `/pb-build`. The argument only seeds how you get there.
+an agent can follow with `/plumbbob:build`. The argument only seeds how you get there.
 
 ## What this skill does
 
@@ -79,9 +79,9 @@ an agent can follow with `/pb-build`. The argument only seeds how you get there.
       - model: <optional — smallest that can carry it, with the one-phrase why>
    ```
 
-   Every step needs a **done-when** `/pb-verify` can check and a **seam** (the exact
+   Every step needs a **done-when** `/plumbbob:verify` can check and a **seam** (the exact
    paths it touches). Later steps may be fuzzier than the first — that's fine; they get
-   sharpened just-in-time when you reach them with `/pb-step`. Keep each small enough to
+   sharpened just-in-time when you reach them with `/plumbbob:step`. Keep each small enough to
    verify in one review pass.
 
    **The title *is* the commit subject — author it as one** *(D1)*: write each
@@ -96,7 +96,7 @@ an agent can follow with `/pb-build`. The argument only seeds how you get there.
    **Set the build's default scope, then let steps override it** *(D8)*: fill the
    `**Scope:**` header once with a short feature-level name — the catch-all every step
    inherits — and give a step its own `(scope)` when it touches a distinct code area
-   (`pb-plan`, `commitmsg`, `docs`). A step's `(scope)` names the *code area*; the header
+   (`plan`, `commitmsg`, `docs`). A step's `(scope)` names the *code area*; the header
    names the *feature*, so scopes stay consistent and greppable across builds. Scope
    resolves title-scope → `**Scope:**` default → build slug → bare, and type resolves
    title-type → `feat`, so a scopeless plain title still yields a clean
@@ -108,7 +108,7 @@ an agent can follow with `/pb-build`. The argument only seeds how you get there.
    `model: sonnet — mechanical, fully specified by the done-when` for rote edits;
    `model: opus — strong-assertion test authoring` where the tests do the thinking;
    `model: fable — subtle cross-cutting design` for judgment-heavy or creative work.
-   It is advisory metadata for the human — `/pb-status` surfaces it before each build —
+   It is advisory metadata for the human — `/plumbbob:status` surfaces it before each build —
    never a gate, and nothing switches models automatically. Write it plain (no
    backticks) and omit it when any model would do.
 5. **Offer harness bindings** *(optional)*. If the build will lean on
@@ -153,7 +153,7 @@ an agent can follow with `/pb-build`. The argument only seeds how you get there.
      see the plan and build record in review. In the same breath, offer the way out:
      a repo that won't track a tool folder can restart with `plumbbob start --local`
      (a fully untracked sidecar) before any steps are built.
-7. **Offer to stress-test it.** Suggest `/pb-refine` to attack the frame for holes (or
+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 interview (mode 1)
@@ -166,11 +166,11 @@ Make it easy and non-intrusive:
   without typing** ("done-when: the 6th request in 60s returns 429 — good?"), while
   taking arbitrary detail when they want to give it, including pointers to other files.
 - **Let them double back.** They will revise as the picture sharpens; that's expected.
-  They can also edit `intent.md` by hand at any time, or call `/pb-refine` to repair it.
+  They can also edit `intent.md` by hand at any time, or call `/plumbbob:refine` to repair it.
 
 ## The hard contracts
 
-- **Deciding before code.** `/pb-plan` writes `intent.md` only — never source.
+- **Deciding before code.** `/plumbbob:plan` writes `intent.md` only — never source.
 - **The human converges.** You surface options and draft wording; the human picks.
   An unresolved hole is an Open question, not a guessed Decision.
 - **Stands on its own.** Whatever the input mode, the finished `intent.md` carries

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.