create-claude-cabinet 0.46.0 → 0.48.0

package/templates/skills/briefing/SKILL.md

@@ -5,10 +5,13 @@ description: |
   project by project — plain-English state, what deserves attention,
   and the project's pending inbox items batched into proposed
   dispositions you approve in-conversation. Decisions are chunked by
-  project, never interleaved. Also handles /recap (factual-only mode).
+  project, never interleaved. Also handles /recap (factual-only mode)
+  and a per-project decision-lineage drill-down ("why is this project
+  the way it is — what still constrains it").
   Use when: "briefing", "brief me", "/briefing", "what's the landscape",
-  "recap", "/recap", "what happened", "what did I do yesterday".
-argument-hint: "scope — e.g., 'today', 'this week', 'maginnis only', 'recap'"
+  "recap", "/recap", "what happened", "what did I do yesterday",
+  "decision lineage", "why is this the way it is".
+argument-hint: "scope — e.g., 'today', 'this week', 'maginnis only', 'recap', 'lineage'"
 ---
 
 # /briefing — The Daily Surface
@@ -21,10 +24,19 @@ the conversation. The success test: the operator runs this daily
 because it is pleasant, and the inbox drains through batch decisions
 here instead of item-by-item `/inbox` walks.
 
-Tone contract for every section below: conversational, concept-first,
-no fid/jargon walls. Item ids and `act:` fids appear on request or in
-disposition confirmations — never as the narrative spine. Lead with
-what matters; counts and mechanics trail.
+Tone contract for every section below — **non-negotiable, every run**:
+plain English, conversational, concept-first. No insider jargon, no
+fid/jargon walls. Say "the background system files one note when the
+same mistake keeps happening" — not "Ring 2 emitPatternPromotion
+dedups by failure class." Name the thing in words the operator would
+use, then add the id only as a trailing reference. Item ids and `act:`
+fids appear on request or in disposition confirmations — never as the
+narrative spine. Lead with what matters; counts and mechanics trail.
+This recurred live (2026-06-14): a briefing slipped into "Ring 2
+meta-critiques / generator leak" and the operator could not act on it
+until it was re-said plainly. If you catch yourself writing a term a
+non-author wouldn't recognize, rewrite the sentence. See also the
+decision/context structure rule under Step 3c.
 
 ## The Anti-Accretion Invariant (structural rule)
 
@@ -57,6 +69,9 @@ rules, not sections:
 - If `$ARGUMENTS` contains the word "recap", or the skill was invoked
   as `/recap`: **Factual mode.** Deliver Step 2's summary, write the
   timestamp (Step 5), and stop. No walk, no dispositions, no cabinet.
+- If `$ARGUMENTS` contains "lineage", "why is", or "decision history":
+  **Lineage mode.** Render THIS desk's project decision lineage (see
+  "Lineage Mode" below), then stop. No walk, no dispositions, no cabinet.
 - Otherwise: **Full mode.** Summary, then the project walk with batch
   dispositions, then the cross-portfolio close.
 
@@ -81,6 +96,87 @@ The time window scopes the NARRATIVE (sessions, threads, what
 happened); pending inbox items are always loaded in full — old pending
 items are exactly what batch dispositions exist to drain.
 
+## Lineage Mode: Decision-Lineage Drill-Down (act:a2efc0ce)
+
+On-demand, read-only. Answers "why is THIS desk's project the way it is —
+what past decisions still constrain it, and what's safely reversible?"
+This is a **projection** over existing stores (the inbox, threads, memory
+`decision_*.md`, `.claude/methodology/`, pib-db), never a new store, and
+it **writes nothing**. It is current-project-scoped in Stage 1: it reads
+the project the current desk's cwd belongs to (worktree-aware). If the
+operator named a *different* project, say plainly that lineage is
+per-desk for now — run it from that project's desk — then either run it
+for the current project or stop. (Cross-project lineage is deferred.)
+
+Distinct from `/threads arc <slug>`, which tells **one work thread's**
+evolution. Lineage tells the **whole project's decision causality**.
+
+**L1 — corpus (inbox + threads).** Run the read-only helper (it lives
+beside the queue lib, in the project-root `scripts/` dir):
+```bash
+node scripts/watchtower-narrative-corpus.mjs --corpus --project-path "$(pwd)"
+```
+It returns `project_identity`, `inbox_decisions` (knowledge-extraction
+items, captured-to-memory duplicates already dropped, `superseded`
+included), `thread_cursors` (full `cursor_history` timelines),
+`per_store_counts`, and `skipped_unresolved`. If `reason` is
+`project-unresolved`, say the desk isn't a watchtower project and stop.
+
+**L2 — memory decisions + recorded edges.** Resolve the project's
+built-in memory dir the way orient does (prefer
+`node -e "console.log(require('./scripts/project-context.cjs').resolveMemoryDir())"`
+when that script exists; else `~/.claude/projects/<dashified-cwd>/memory`),
+then have the SAME helper parse the decision files (the consumer resolves
+the path; the helper owns the edge rule):
+```bash
+node scripts/watchtower-narrative-corpus.mjs --memory "<memory-dir>"
+```
+Each entry carries `supersedes` (RECORDED, directional edges) and
+`see_also` (undirected wikilinks — **never** render a see-also as a
+supersession).
+
+**L3 — methodology "why" (richest substrate).** If `.claude/methodology/`
+exists in the cwd, read its `README.md` index and the `-internal.md`
+bodies relevant to the load-bearing decisions — these carry the
+Claim→Evidence→Skeptic→Counter reasoning the other stores summarize away.
+
+**L4 — pib-db design rationale.** `pib_list_actions` for the current
+project (resolve the `prj:` fid via `pib_list_projects`; if the name is
+ambiguous, ask — never guess). Action notes carry `absorbs act:…` /
+`Supersedes …` prose — these are **inferred** edges (prose, not a
+structural field), mark them so.
+
+**L5 — synthesize, ANSWER-FIRST** (plain English, concept-first; the tone
+contract above applies in full):
+
+1. **What still constrains this project right now** — lead with this. The
+   decisions/constraints from earlier that later work still depends on;
+   for the ones the operator might want to revisit, say whether anything
+   still hangs on them (reversible vs load-bearing). This is the answer
+   the drill-down exists to give.
+2. **Supersession chains** — what replaced what, with **provenance**:
+   *recorded* (a parsed `**Supersedes:**` block or a pib `absorbs act:`
+   marker — citable) vs *inferred* (read from prose) — labeled, never
+   conflated. A narrative is a trust surface: do not present an inferred
+   link as recorded history, and never render a `[[wikilink]]` as a
+   supersede.
+3. **The causal timeline** — OPTIONAL deep-read, placed **below** the
+   answer. Chapter by causal **pivot / phase transition** (the moments
+   direction changed — a constraint discovered, an approach superseded),
+   not by raw time gaps. Skip this entirely when the corpus is sparse.
+
+**Honesty footer.** Report `per_store_counts` and `skipped_unresolved` in
+plain words when either is notable: "history may be incomplete — N inbox
+items couldn't be attributed to a project and may belong here." Never
+present a silently-truncated history as complete.
+
+**Sparse / empty.** If the combined decision count (inbox_kept + memory
+decisions) is under ~3, say "not enough decision history to narrate yet
+(N found)" and stop — a story needs enough points to have an arc.
+
+Lineage mode renders inline and stops. It writes nothing — no state file,
+no inbox item, no memory write.
+
 ## Step 1: Gather Data
 
 No Claude API calls — pure filesystem reads plus the queue lib. State
@@ -116,18 +212,58 @@ and titles. Also collect resolved `qa-handoff` items whose
 pib-db (`pib_get_action` or `node scripts/pib-db.mjs get <fid>`) and
 keep only still-open ones — these are the open QA debts for Step 4.
 
-### 1d. Portfolio state
+### 1d. Cross-ring portfolio view (state, threads, git attention, resolution history)
 
-Read `state/projects/*.md` — Active Plans, Last Session, Standing
-Issues per project (scope-filtered if a project filter is active).
+Run the cross-ring reader — ONE gather call that replaces the old
+per-store reads (state files + threads) and adds two signals nothing
+here consulted before: the inbox **resolution history** (with
+`resolution_mix` ratios — what the operator's past decisions actually
+engaged vs discarded, per project) and the structured **git-attention
+facts**:
 
-### 1e. Active threads
+```bash
+XRING="$(mktemp)"
+node scripts/watchtower-cross-ring-reader.mjs --portfolio > "$XRING"
+# with a project filter active: --project "<name or slug>" instead
+# (config-key name preferred; a unique slug match also resolves)
+```
 
-Read `state/threads/*.json`; collect `status: "active"` threads. The
+**Consume by Reading the file, never by echoing it through Bash** — a
+live portfolio view runs to a few hundred KB and Bash tool output
+truncates long before that (a truncated JSON parse is the failure this
+instruction exists to prevent). Read the envelope's top (counts +
+honesty fields) for Step 2, then Read each project's view slice as you
+walk that chunk in Step 3; the JSON is pretty-printed, so each
+project's view is one contiguous block.
+
+Per project it returns the parsed Ring 1 state sections (Active Plans,
+Last Session, Standing Issues, Tech Stack), git-attention facts, recent
+session summaries, thread cursor timelines (capped to the newest 3
+snapshots with `history_total` — the full evolution is lineage mode's
+job; a legacy lone-`cursor` file arrives as a single-entry history;
+current cursor = the LAST history entry), pending counts by
+category/urgency, and the resolution history (`resolution_mix` carries
+full counts; the event list is capped with `resolution_events_total`).
+Every cap reports its total — "3 of 85" is signal, not truncation. The
+envelope's honesty fields (`unattributed_items`, `orphan_threads`,
+`orphaned_state_files`) are real signal — surface them in plain words
+in Step 4 when notable. Pending COUNTS here are a narration snapshot;
+1c's live `listPending()` load stays the disposition source of truth.
+
+**Fallback (script absent — a consumer that hasn't reinstalled since
+the reader shipped):** read the raw stores directly as 1e describes,
+and proceed without the resolution-history/git-attention signals.
+
+### 1e. Active threads (fallback path only)
+
+Normally covered by the 1d view. When the 1d fallback is in effect,
+read `state/threads/*.json`; collect `status: "active"` threads. The
 current cursor is `cursor_history[last].cursor` (older files may carry
 a lone `cursor` object — treat it as current). Extract `what`,
 `where_left_off`, `next_steps`, `last_updated`, session count. Sort by
-`last_updated` descending.
+`last_updated` descending. (Also read `state/projects/*.md` — Active
+Plans, Last Session, Standing Issues per project, scope-filtered if a
+project filter is active.)
 
 ### 1f. Last briefing timestamp
 
@@ -155,6 +291,29 @@ observation is Step 4 close material. Include only members who said
 something; silence is fine and is the common case. In recap mode, skip
 the panel entirely — it spawns only on full-mode invocation.
 
+### 1h. Unprocessed DX captures (mux's global capture list)
+
+Read mux's global DX-capture store — `~/.local/share/mux/dx.json` — the
+single cross-project list where `mux dx "..."` and `/dx-feedback` drop
+developer-experience ideas and friction. A pure filesystem read with no
+ordering dependency on the panel spawn. If the file is absent or
+unparseable (mux not installed, or no captures yet), skip silently — it
+is a mux-owned store and its absence is normal, not an error.
+
+An item is **active** (unprocessed) only when BOTH `done` is false AND
+`filed` is false. `done` items were cleared; `filed` items already live
+in pib-db (an action or feedback) — resurfacing either is exactly the
+write-only-telemetry bug this duty exists to kill. Collect each active
+item's `text`, `created_at`, `origin`, and its **global active-list
+position** (1-based index among active items — the position
+`manage-dx.py` addresses when draining). Resolve each item's `origin` to
+a walk project where you can: labels like `"claude-cabinet"` or `"flow"`
+map to a project chunk; labels like `"session-observation"` or
+`"unknown"` do not — those are portfolio-level (Step 4). If there are
+zero active items, skip silently. (This was orient's job; post-orient
+nothing reads these unless the briefing does — see
+`lesson_write_only_telemetry_wire_a_reader`.)
+
 ## Step 2: Top Brief
 
 Ten lines or fewer — the whole portfolio in one glance, curated. Not a
@@ -183,11 +342,19 @@ gate.").
 
 ## Step 3: The Project Walk
 
-One project at a time, in curated order: projects with pending gated
-items first, then urgent items, then by thread recency and pending
-count; quiet projects last (and a project with nothing to say gets one
-line or silence — absence of news is news the operator doesn't need).
-A project filter scopes the walk to that project.
+One project at a time, in curated order: lead with the chunks the
+operator can actually act on from this session — the current desk and
+any project with dispositionable (ungated, this-desk) items — then
+projects with pending gated items, then urgent items, then by thread
+recency and pending count; quiet projects last (and a project with
+nothing to say gets one line or silence — absence of news is news the
+operator doesn't need). A project filter scopes the walk to that
+project. **Why actionable-first:** a cross-desk gated item can only be
+"left queued for its own desk" from here — it is read-only from this
+session, so surfacing it (and a wall of another desk's state) before
+the operator's own decisions just front-loads context they must hold.
+Surface it, but later. A gated item is never dropped (floor #1); it is
+only re-ordered.
 
 **Decisions are never interleaved.** Each project's chunk completes —
 narrative, attention items, dispositions executed — before the next
@@ -204,9 +371,11 @@ Each chunk has three movements:
 ### 3a. State, in plain English
 
 Two to four sentences synthesized from the project's threads, Last
-Session, and standing issues: where work stands, what changed in
-scope, what's hanging. Concept-first — "the publish pipeline is built
-but has never run against a live tag" — not file paths and fids. This
+Session, and standing issues — all already in hand from the Step 1d
+cross-ring view (no second read; its parsed sections, session bullets,
+and cursor timelines are the input). Concept-first — "the publish
+pipeline is built but has never run against a live tag" — not file
+paths and fids. This
 is the operator-facing register (`cabinet/skill-output-conventions.md`
 §9) as the briefing's whole default; keep it that way. Offer nothing
 here; drill-down happens by the operator asking.
@@ -231,6 +400,14 @@ floor-or-not) — a new duty adds an entry here, never a section:
   shows ≥3 stale project(s) OR ≥2 completion candidate(s) (Ring 1 renders
   these counts) · one line max, "backlog showing cruft — consider
   /spring-clean" · decays once the counts fall; never its own section.
+- **Backlog rot** · this project's PENDING inbox is rotting: items older
+  than the rot threshold (30d) with ~0 recent dispositions — the
+  `not-consumed` verdict from `scripts/watchtower-inbox-assessment.mjs`
+  (co-equal with the keep ratio: a great keep ratio on an untouched pile
+  is still rot). Weigh high while it holds · one line, "N items sitting
+  30+ days unworked — work a batch now" pointing straight at this
+  project's 3c decay/sign-off batch · decays the moment the pile is
+  worked; never its own section.
 - **Environment advisories** · `suggested` entries in
   `.claude/cabinet/advisories-state.json` (the watchtower context builder's
   advisory pass already wrote them) for this chunk's project · one line
@@ -238,6 +415,13 @@ floor-or-not) — a new duty adds an entry here, never a section:
   just read the surfacing state.
 - **Verify signals** · shipped-uncovered warnings · weigh as they arrive.
 - **State-file flags** · anything in Standing Issues that needs a human.
+- **Unprocessed DX captures** · active items in mux's global `dx.json`
+  (1h) whose `origin` resolves to this chunk's project · weigh fresh,
+  then decay like any aged item — one line each, with a process/dismiss
+  path so the list actually drains (handling below) · not a floor:
+  captures are freely drainable and dismissable. Captures whose origin
+  resolves to no walk project go to the Step 4 close — never silently
+  dropped.
 
 Everything else stays in the batch counts below.
 
@@ -254,7 +438,7 @@ Advisor signals come from two sources, both weighed here:
   ungated items — legal batch material in 3c.
 - **Live panel observations** (Step 1g) that named this project.
 
-Two categories get specific handling when selected:
+Three categories get specific handling when selected:
 
 - **Gated items (`qa-handoff`):** present what merged and what hangs
   on it, then offer exactly two paths — run the recipient gate now in
@@ -269,10 +453,48 @@ Two categories get specific handling when selected:
   `acted-on`. If the moment passed (yesterday's morning briefing),
   propose it for the stale batch below — routine items are dispatched
   but not gated, and the engine supersedes stale ones anyway.
+- **DX captures:** write-only until something drains them. Surface each
+  active capture as one plain line (the idea · when · where it came
+  from) and offer exactly two paths, one decision at a time — **process**
+  it (act on it now, or file it to pib-db as an action or feedback, then
+  mark it filed) or **dismiss** it as no-longer-relevant. Both paths
+  drain the list through mux's own tooling — single source of truth,
+  never hand-edit `dx.json`:
+
+  ```bash
+  # dismiss (clear) a capture — n is its position in the active list
+  python3 ~/.config/mux/manage-dx.py done <origin> <n>
+  # after filing a capture to pib-db, mark it filed (drops it from the panel)
+  python3 ~/.config/mux/manage-dx.py mark-filed <origin> <n>
+  ```
+
+  `<n>` is the global active-list position, and positions renumber as
+  items leave — when draining several, clear from the **highest position
+  down** (or re-read positions between marks) so an earlier removal can't
+  shift the index out from under you. `<origin>` is context only; the
+  number addresses the global active list regardless of origin.
 
 ### 3c. Batch dispositions
 
-Cluster this project's remaining pending items into **at most three
+**First, the sign-off batch — the SAVE direction (M4, act:ffae4eec).**
+Before any decay clustering, partition this project's ungated pending
+items with `partitionForBatchSignoff` (the lib owns the predicate). Its
+`signoff` set is the high-confidence pre-drafted knowledge-extraction
+items (non-empty `draft_artifact`, not urgent, not low-confidence) —
+work the rings already did that needs a nod, not a judgment. Offer the
+whole set as ONE sign-off decision ("the background system drafted these
+N memory entries; approving writes them to memory — sign off on all?").
+On approval, write each `draft_artifact` to memory (`/cc-remember` or a
+direct write), THEN one `applyBatch` resolve with
+`resolution_type: 'captured-to-memory'`. This is the throughput valve:
+M1/M2 raise inflow and success = filed × approval-rate (the M5 canary
+tracks it), so a fast sign-off keeps drafts from ageing out
+unadjudicated. Pulled-out items get per-item `/inbox` treatment after
+the walk; everything else falls to the decay flow below — still one
+decision at a time, the sign-off batch presented first.
+
+**Then, decay clustering.** Cluster this project's REMAINING pending
+items into **at most three
 proposed batches** by theme — category × age × thread is the usual
 axis. For each batch, propose a disposition in plain English with the
 reasoning visible. Decay lives here: the curator's default proposal
@@ -283,27 +505,40 @@ A batch proposal must name: what's in it (count + a few example
 titles), the proposed disposition, and the typed reason that will land
 on every item.
 
-Ask for approval as a **plain-text question, never a same-turn
-dialog**. A dialog eclipses everything above it, and batch rationale
-does not fit inside option descriptions — the operator ends up
-approving reasoning they cannot see (recurred live 2026-06-13, twice
-in one session, during this skill's own QA). The shape: the chunk's
-prose ends with the batch proposals (each one: what's in it, the
-disposition, the typed reason) followed by a one-line question —
-"Apply batch 1, batch 2, both, or neither?" — and the turn STOPS
-there. The operator answers in prose. Reserve `AskUserQuestion` for
-choices that are self-sufficient inside the dialog; batch
-dispositions never are.
+Ask for approval **one decision at a time** — never a stack of
+questions under a wall of context, never a same-turn dialog. Two
+failure modes, both observed live: a same-turn dialog eclipses the
+reasoning above it, so the operator approves logic they cannot see
+(recurred 2026-06-13); and a long narrative followed by several
+questions at the end forces the operator to hold every batch's
+rationale in their head at once, which they cannot (recurred
+2026-06-14). **The decision/context structure rule:** the only thing
+that should require working memory is the single decision in front of
+the operator, with its reason immediately beside it.
+
+The shape: present **one batch** — what's in it (count + a few example
+titles), the proposed disposition, the typed reason — then a one-line
+question ("Dismiss these 14 as stale? y / n / show me") and the turn
+STOPS. The operator answers in prose. Apply it, confirm in one line,
+then present the next batch the same way. Pure read-only material —
+portfolio state for desks the operator isn't on, platform notes,
+anything needing no decision — is delivered AFTER all decisions are
+made; it costs nothing to hold, so it never sits above a decision.
+Reserve `AskUserQuestion` only for a self-contained choice whose
+options stand on their own inside the dialog (e.g. a layout pick with
+previews); batch dispositions never qualify.
 
 Execute approved batches immediately via the queue lib, then say what
 happened in one line each and move to the next project:
 
 ```bash
 node --input-type=module -e "
-import { applyBatch } from './scripts/watchtower-queue.mjs';
+import { applyBatch, partitionForBatchSignoff, listPending } from './scripts/watchtower-queue.mjs';
+// Sign-off batch (M4): partitionForBatchSignoff(listPending({project})).signoff
+// → resolve 'captured-to-memory' (write each draft_artifact FIRST). Decay='dismiss'.
 const r = applyBatch([/* ids */], {
-  disposition: 'dismiss',            // or 'resolve'
-  resolution_type: 'stale',          // typed reason — required
+  disposition: 'dismiss',            // or 'resolve' (the sign-off batch)
+  resolution_type: 'stale',          // typed reason — required ('captured-to-memory' for sign-off)
   notes: '<the reason shown to the operator, verbatim>',
 });
 console.log(JSON.stringify(r));
@@ -325,10 +560,15 @@ include a part only when it has signal.
 
 - **Cross-cutting synthesis** — patterns spanning projects (the same
   friction filed from two desks, a theme across threads, a decision
-  made in one project that answers a question open in another). This
-  is live synthesis by the briefing session; if a precomputed
-  cross-ring synthesis layer exists, consume it here instead of
-  re-deriving.
+  made in one project that answers a question open in another). The
+  substrate is the Step 1d cross-ring portfolio view — synthesize from
+  its per-project views (git-attention facts across projects,
+  `resolution_mix` ratios, thread/session convergence) instead of
+  re-deriving from raw stores. Its honesty fields belong here too, in
+  plain words when notable: "N inbox items couldn't be attributed to
+  any project", "one active thread matches no configured project".
+  The synthesis itself stays live — the reader gathers, this session
+  thinks.
 - **Standing debts** — floor #2: while any QA filed-gaps remain open,
   one roll-up line each ("X still owes the migration test filed by
   last week's QA — act:fid"). Same treatment for unmerged-worktree
@@ -338,6 +578,11 @@ include a part only when it has signal.
   historian precedent that answers an open question, a platform delta
   from the insider, a legibility flag from the user-advocate). One line
   each, only members who said something — never a roll call.
+- **Unprocessed DX captures, portfolio-level** — active `dx.json`
+  captures (1h) whose `origin` resolved to no walk project land here,
+  one line each, with the same process/dismiss drain path as the
+  per-project handling (3b). Only when some exist; never a standing
+  section.
 
 Close with one sentence: dispositions applied this run (N resolved, M
 dismissed, across K projects), what remains pending, and — only if
@@ -367,6 +612,9 @@ After the briefing completes (any mode), atomically write
   the watchtower module): deliver the read-only briefing from global
   state and say dispositions need a watchtower-installed project.
 - Corrupt/unparseable item files: skip with a one-line warning count.
+- No mux DX store (`~/.local/share/mux/dx.json` missing, or mux not
+  installed): skip the DX-capture candidate silently — a mux-owned
+  store's absence is normal, not an error.
 - An `applyBatch` throw is a stop-and-show, not a retry loop: name the
   item that tripped the gate, pull it into per-item handling, re-offer
   the rest as a new batch.

package/templates/skills/cabinet-accessibility/SKILL.md

@@ -11,7 +11,7 @@ briefing:
   - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: audit
 files:
-  # Adjust to your component paths. See .claude/cabinet/_briefing.md § Scan Scopes — App Source
+  # Adjust to your component paths. See .claude/cabinet/_briefing-jurisdictions.md § App Source
   - src/**/*.tsx
   - src/components/**/*.tsx
 topics:

package/templates/skills/cabinet-process-therapist/SKILL.md

@@ -125,3 +125,31 @@ universal patterns below. Absent is normal — it is seeded by debrief
 when recurring findings accumulate.
 
 <!-- Universal patterns below this line -->
+
+### Don't redo work that's already done or already specified
+
+Recurring inefficiency: discovery is run for things already in hand, and
+complete plans are rebuilt instead of executed.
+
+- **Use what you already know directly.** Don't run discovery
+  (ToolSearch, phase-file hunts, grep archaeology) for a tool name,
+  path, or spec you already have. A targeted lookup or direct attempt
+  beats a discovery loop; reserve discovery for the genuinely unknown.
+- **Don't re-encode a complete plan.** If the prompt is already ordered
+  and explicit, execute it rather than rebuilding it as tasks that
+  mirror it. A task layer earns its cost only when it adds structure the
+  prompt lacks: progress-tracking through a long single-session run, or
+  a durable record when the work will span sessions. Match the vehicle
+  to the lifespan — an in-session task list for progress (it is lost on
+  interruption), a `.claude/plans/` doc or pib-db action for anything
+  that must outlive the session.
+- **Bound your research.** Stop at minimum-viable understanding, not
+  maximal confidence. If you are hunting for something the user believes
+  exists, ask where it lives before a long search.
+- **Reconcile on resume.** A continuation prompt is a claim about the
+  past; check current state (query the named action FIDs) before acting
+  on it.
+- **Spawn with a sync point.** Load context before launching parallel
+  sub-agents, and define where you will collect and surface their
+  output. No fire-and-forget black boxes — no completion check, no
+  output handling.

package/templates/skills/cabinet-security/SKILL.md

@@ -108,3 +108,14 @@ universal patterns below. Absent is normal — it is seeded by debrief
 when recurring findings accumulate.
 
 <!-- Universal patterns below this line -->
+
+### Secrets pasted into the conversation need an active response
+
+When a secret lands in the chat — a PAT, API key, password, connection
+string the user pastes to unblock something — do not just consume it
+silently. Two reflexes: (1) advise against pasting secrets in plain text
+and point at the safer path (env var, secret store, the OS secure dialog
+the engagement flow uses); (2) when you must echo or reference it,
+redact/truncate it (`ghp_…abcd`) rather than reprinting it in full.
+Silently using a plaintext secret normalizes leaking it into transcripts
+and logs.

package/templates/skills/catch-up/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: catch-up
+description: |
+  Mid-session awareness refresh. Watchtower injects state once, at session
+  start; a long session then drifts from that snapshot as other sessions
+  advance threads, the background rings file inbox items and detect new git
+  state, and deferred tasks come due. /catch-up shows what CHANGED since this
+  session started — a short, plain-English delta, not a re-dump of everything.
+  Read-only. Use when: "catch-up", "/catch-up", "what changed", "what's new
+  since I started", "what did I miss", "refresh my context", "poll watchtower",
+  "re-orient".
+argument-hint: "(none)"
+---
+
+# /catch-up — What Changed Since This Session Started
+
+Watchtower runs continuously in the background, but it injects its state into
+a session exactly **once**, at session start. Over a long session that
+snapshot goes stale: other desks advance shared work threads, Ring 2 enriches
+and files inbox items, Ring 1 detects new git state, deferred actions come due.
+This skill closes that gap — it compares the current watchtower state against
+the **baseline captured when this session started** and tells you, in plain
+language, only what's new.
+
+This skill is **read-only**. It reads state and renders a delta. It never
+triages, resolves, or writes anything except (when no baseline exists yet) a
+fresh baseline for next time.
+
+It is the manual, on-demand half of mid-session awareness. The automatic
+"notify me when something significant changes" version is a deliberate later
+enhancement (see the plan's Option B) — not this skill.
+
+## How the baseline works
+
+At session start, the watchtower SessionStart hook captures a structured
+snapshot of watchtower state, keyed by this session's id, at
+`~/.claude-cabinet/watchtower/state/session-snapshots/<session-id>.json`.
+`/catch-up` re-reads current state and diffs it against that baseline. All the
+snapshot/diff/render logic lives in one place —
+`~/.claude-cabinet/watchtower/scripts/watchtower-snapshot.mjs` — which this
+skill just drives; it does not re-implement any of it.
+
+## Step 1 — Locate the runtime and this session's baseline
+
+```bash
+WT="${HOME}/.claude-cabinet/watchtower"
+SNAP="${WT}/scripts/watchtower-snapshot.mjs"
+SID="${CLAUDE_CODE_SESSION_ID:-}"
+BASE="${WT}/state/session-snapshots/${SID}.json"
+```
+
+Resolve three facts:
+
+- **Watchtower installed?** If `${SNAP}` does not exist, say plainly that
+  watchtower isn't installed (or this project isn't using it), so there's
+  nothing to catch up on, and stop.
+- **Session id known?** `CLAUDE_CODE_SESSION_ID` is the session's id (a UUID;
+  it matches the session transcript name and the id the SessionStart hook keys
+  the baseline under). If it is empty, there is no per-session baseline to diff
+  against — say so plainly and stop (do **not** read or write a keyless/shared
+  baseline file; a shared "unknown" baseline would show you another session's
+  changes as if they were yours).
+- **Baseline present?** Whether `${BASE}` exists decides Step 2's branch.
+
+## Step 2 — Diff, or self-seed if there's no baseline yet
+
+**If `${BASE}` exists** — run the diff and relay it:
+
+```bash
+node "${SNAP}" --diff "${BASE}" --project-path "$(pwd)"
+```
+
+The module prints the delta already in plain, concept-first English (deferred
+tasks that came due, new inbox items, threads that advanced or appeared, new or
+cleared git attention) — or a single "Nothing new since this session started"
+line. **Relay that output directly.** Don't reformat it into field dumps or
+re-expand it into the full state; the whole point is the delta. You may add one
+short framing sentence, but the rendered delta is the answer.
+
+Phrase anything you add as *project-level* change ("since your session started,
+the project picked up…"), never as something you personally did — in a worktree,
+a concurrent session's work legitimately shows up in this delta.
+
+**If `${BASE}` does NOT exist** — this session predates the feature, or the
+SessionStart hook didn't capture a baseline. Self-seed one now so the *next*
+`/catch-up` works, and say so honestly:
+
+```bash
+node "${SNAP}" --emit-snapshot "${BASE}" --project-path "$(pwd)" --session-id "${SID}"
+```
+
+Then tell the user, plainly: there was no start-of-session baseline to compare
+against, so you've captured one as of now — run `/catch-up` again later to see
+what's changed since this point. Do not invent a delta you can't compute.
+
+## Step 3 — Keep it short
+
+The value here is the delta, surfaced fast. Lead with the headline ("2 new
+inbox items, one thread advanced, a deferred task came due"), let the rendered
+detail follow, and stop. If a new item or freshly-due task clearly wants
+action, you may name the one next step — but routing and triage belong to
+`/inbox` and `/briefing`; this skill just makes you current.
+
+## Calibration
+
+**Without this skill:** the only way to re-orient mid-session is to restart, so
+a session works for an hour against a start-of-session snapshot while threads
+move, items get filed, and deferrals fire — all invisible until the next
+session.
+
+**With this skill:** one command answers "what did I miss while I was heads
+down?" against a real baseline — the single upgrade that makes watchtower feel
+alive mid-session rather than boundary-only.