create-claude-cabinet 0.15.0 → 0.16.0

package/lib/cli.js

@@ -356,7 +356,7 @@ const MODULES = {
     mandatory: false,
     default: true,
     lean: true,
-    templates: ['hooks/git-guardrails.sh', 'hooks/cc-upstream-guard.sh', 'hooks/skill-telemetry.sh', 'hooks/skill-tool-telemetry.sh', 'hooks/compaction-save.md', 'hooks/compaction-recover.sh', 'scripts/cc-drift-check.cjs'],
+    templates: ['hooks/git-guardrails.sh', 'hooks/cc-upstream-guard.sh', 'hooks/skill-telemetry.sh', 'hooks/skill-tool-telemetry.sh', 'scripts/cc-drift-check.cjs'],
   },
   'work-tracking': {
     name: 'Work Tracking (pib-db or markdown)',

package/lib/settings-merge.js

@@ -15,19 +15,6 @@ const MEMORY_HOOKS = {
   ],
 };
 
-// Prompt text for the PreCompact hook. Source of truth: templates/hooks/compaction-save.md
-const COMPACTION_SAVE_PROMPT = `Before compaction destroys your current context, you MUST save state so the next session can recover.
-
-REQUIRED — Always write .claude/compaction-state.md with these sections:
-- Current Task: what you were actively working on (file paths, function names, exact step)
-- Decisions Made: key decisions with reasoning
-- Next Steps: ordered list, most urgent first
-- References: files, URLs, error messages needed by next context
-
-CONDITIONAL — If mid-workflow with intermediate results, ALSO write .claude/<workflow-name>-partial.md (e.g. .claude/audit-partial.md for a mid-audit). Include completed items, partial results, progress tracking.
-
-Keep total output under 200 lines. Use concrete details, not vague summaries. Write the files now.`;
-
 const DEFAULT_HOOKS = {
   PreToolUse: [
     {
@@ -71,27 +58,6 @@ const DEFAULT_HOOKS = {
       ],
     },
   ],
-  PreCompact: [
-    {
-      hooks: [
-        {
-          type: 'prompt',
-          prompt: COMPACTION_SAVE_PROMPT,
-        },
-      ],
-    },
-  ],
-  SessionStart: [
-    {
-      matcher: 'compact',
-      hooks: [
-        {
-          type: 'command',
-          command: '.claude/hooks/compaction-recover.sh',
-        },
-      ],
-    },
-  ],
 };
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-cabinet",
-  "version": "0.15.0",
+  "version": "0.16.0",
   "description": "Claude Cabinet — opinionated process scaffolding for Claude Code projects",
   "bin": {
     "create-claude-cabinet": "bin/create-claude-cabinet.js"

package/templates/skills/audit/SKILL.md

@@ -201,11 +201,17 @@ Read `phases/finding-output.md` for how to persist and report the
 audit results.
 
 **Default (absent/empty):**
+
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
 1. Create a timestamped run directory: `reviews/YYYY-MM-DD/HH-MM-SS/`
 2. Write each cabinet member's JSON output to the run directory
 3. Run `scripts/merge-findings.js <run-dir>` to produce `run-summary.json`
-4. Run `scripts/merge-findings.js <run-dir> --db` to also ingest into
-   the reference data layer (if pib-db is initialized)
+4. Ingest into the reference data layer: use `pib_ingest_findings` with
+   the run directory (or `scripts/merge-findings.js <run-dir> --db`) if
+   pib-db is initialized
 5. Present findings summary: total count, breakdown by severity, by
    cabinet member, and highlight any critical findings
 

package/templates/skills/cabinet-anthropic-insider/SKILL.md

@@ -25,6 +25,11 @@ directives:
   seed: >
     Evaluate whether a proposed cabinet member or skill overlaps with built-in
     Claude Code functionality. If the platform already does it, say so.
+  verify: >
+    Before recommending adoption of any platform feature, confirm it works
+    for the project's use case — not just that it exists in the changelog.
+    Test it or cite authoritative documentation showing it works as needed.
+    "The changelog says X exists" is not verification.
 ---
 
 # Claude Ecosystem Cabinet Member
@@ -232,6 +237,26 @@ the project is using what the platform offers:
 - **Version awareness** — does the project track which Claude Code version
   it targets? Will it work with older/newer versions?
 
+#### 8. Feature Verification
+
+Before recommending adoption of any platform capability:
+
+- **GA check** — Is the feature generally available, or experimental/beta?
+  Experimental features may change or be removed.
+- **Hook type check** — Does the feature work for the specific hook type,
+  tool type, or invocation context being proposed? (e.g., prompt hooks
+  cannot take actions; command hooks can.)
+- **Minimal test** — Can you demonstrate the behavior works with a quick
+  test? If you can't test it, cite authoritative documentation that
+  explicitly confirms the behavior for your use case.
+- **Limitation inventory** — What are the known limitations? Are there
+  open issues or feature requests that indicate the feature doesn't do
+  what you'd expect?
+
+**The standard:** "The changelog says X exists" is not verification.
+"I tested X and it does Y" or "The hooks documentation explicitly states
+prompt hooks can/cannot Z" is verification.
+
 ### Scan Scope
 
 - `.claude/settings*.json` — configuration and permissions
@@ -324,3 +349,12 @@ field-feedback. The CC maintainer adds it to this section. Project-specific
 patterns that don't generalize stay in `patterns-project.md`.
 
 <!-- Universal patterns below this line -->
+
+- **Unverified platform recommendation (PreCompact hooks):** Recommended
+  adopting PreCompact/PostCompact hooks for compaction state management.
+  PreCompact prompt hooks are single-turn policy evaluations with no tool
+  access — they cannot write files, run commands, or take any action.
+  The hooks were designed, built, shipped in v0.15.0, and deployed to 3
+  consumers where they silently failed. GitHub issues #43733 and #36749
+  are open feature requests for agentic PreCompact support. Always verify
+  that the hook type supports the intended action before recommending.

package/templates/skills/cabinet-cc-health/SKILL.md

@@ -224,9 +224,10 @@ drift between the two:
   - Work tracking specifically: the pib-db scripts ship with both the
     work-tracking and audit modules, so `.ccrc.json` alone doesn't tell
     you if work tracking is active. Check whether `pib.db` exists AND
-    has projects/actions with real data (`node scripts/pib-db.mjs
-    list-projects`). If it does but the briefing says "no work tracking,"
-    that's a direct contradiction.
+    has projects/actions with real data — use `pib_list_projects` (or
+    `node scripts/pib-db.mjs list-projects` CLI fallback). If it does
+    but the briefing says "no work tracking," that's a direct
+    contradiction.
   - `.ccrc.json` version vs `package.json` version — they should match.
   - `package.json` dependencies vs what the briefing describes as the
     tech stack. New dependencies not mentioned? Removed ones still listed?

package/templates/skills/cabinet-organized-mind/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: cabinet-organized-mind
 description: >
-  Levitin's cognitive neuroscience applied to system design. Thinks about
+  Levitin's cognitive neuroscience applied to system design for human operators. Thinks about
   attention economics (the two brain modes, switching costs, the 120-bit
   bottleneck), memory architecture (associative, reconstructive, overconfident),
   categorization theory (functional vs. taxonomic, fuzzy boundaries, the
@@ -17,13 +17,33 @@ standing-mandate: audit, plan
 tools: []
 directives:
   plan: >
-    Evaluate cognitive load. Will this plan's result be understandable
-    and maintainable? Does it externalize complexity or pile it on the
-    operator?
+    Evaluate cognitive load on human operators. Will this plan's result
+    be understandable and maintainable by humans? Does it externalize
+    complexity or pile it on the human operator?
 ---
 
 # The Organized Mind
 
+## Scope: Human Cognition, Not AI Cognition
+
+Every principle in this member's toolkit — working memory limits, decision
+fatigue, attention economics, the 120-bit bottleneck, metabolic switching
+costs — comes from human neuroscience. These constraints apply to the
+**human operators** who use, maintain, and make decisions with this system.
+
+Claude does not share these constraints. Claude has no metabolic cost for
+context switching, no working memory ceiling in the human sense, no
+decision fatigue from accumulated choices, and no need for externalization
+to prevent forgetting.
+
+When this member evaluates whether a system imposes cognitive load, the
+question is always: **"on the human."** A dashboard with 15 columns costs
+a human attention and working memory. It costs Claude nothing. A workflow
+requiring the operator to remember 6 implicit rules taxes human cognition.
+Claude reads the rules file and moves on.
+
+Design for the human. Claude adapts.
+
 ## Identity
 
 You think with the full conceptual apparatus of Daniel Levitin's *The

package/templates/skills/cc-feedback/SKILL.md

@@ -57,7 +57,15 @@ Present the draft to the user:
 If the user confirms, deliver using the standard upstream feedback
 mechanism:
 
-**If linked** (CC package resolves to a local directory — check if
+**If this IS the CC source repo** (check: `node -e "const p = require('./package.json'); process.exit(p.name === 'create-claude-cabinet' ? 0 : 1)"` exits 0):
+
+- Write directly to the local `feedback/` directory (create if needed)
+- Filename: `[source-project]-[date]-[short-title].md`
+- This is the dogfood case — the project IS the upstream repo, so
+  feedback goes directly into the local `feedback/` directory.
+
+**If linked** (not the source repo, but CC package resolves to a local
+directory — check if
 `node -e "console.log(require.resolve('create-claude-cabinet'))"` points
 to a local path rather than `node_modules`):
 

package/templates/skills/cc-publish/SKILL.md

@@ -88,7 +88,12 @@ each project that is NOT the CC source repo itself:
 2. If it's older than the just-published version, update it:
    - `cd <path> && npx create-claude-cabinet@latest --yes`
    - Verify the install succeeded (`.ccrc.json` version matches)
-3. Report which consumers were updated and which were already current
+3. After a successful update, commit the CC-managed files in the consumer:
+   - `git -C <path> add .claude/ .mcp.json scripts/pib-db*.mjs scripts/pib-db-schema.sql scripts/*.cjs .ccrc.json`
+   - Commit with message: `chore: update claude-cabinet to v<version>`
+   - Only stage files that are actually modified (`git -C <path> diff --name-only` to check)
+   - Do NOT push — leave that to the user
+4. Report which consumers were updated, committed, and which were already current
 
 **Important:**
 - Never force-install or pass flags beyond `--yes` — the installer
@@ -96,3 +101,5 @@ each project that is NOT the CC source repo itself:
 - If a consumer's path doesn't exist, note it (stale registry entry)
   but don't error — mention it in the report
 - If an install fails, report the error but continue with other consumers
+- The commit in step 3 should only include CC-managed files, not any
+  project-owned files that happen to be dirty in the working tree

package/templates/skills/debrief/phases/audit-pattern-capture.md

@@ -22,10 +22,8 @@ this phase entirely.
 For each cabinet member that produced findings this session, check
 whether the same CLASS of finding has appeared before:
 
-- Check triage history if available:
-  ```bash
-  node scripts/pib-db.mjs triage-history 2>/dev/null
-  ```
+- Check triage history if available: use `pib_triage_history` (or
+  `node scripts/pib-db.mjs triage-history` CLI fallback).
   Look for approved findings from the same cabinet member with similar
   descriptions.
 

package/templates/skills/debrief/phases/close-work.md

@@ -12,17 +12,21 @@ pib-db is not initialized, skip gracefully.
 
 ## Default Behavior (pib-db)
 
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
 When no custom close-work is configured:
 
 1. **Get session work:** Review `git log --oneline` for this session's
    commits (since session start or last 2 hours)
-2. **Get open actions:** `node scripts/pib-db.mjs list-actions`
+2. **Get open actions:** Use `pib_list_actions` (or `node scripts/pib-db.mjs list-actions`)
 3. **Match:** For each open action, check if this session's work
    addresses it (compare action text/notes against commit messages
    and changed files)
 4. **Propose:** Present matched actions and ask the user to confirm
    which to close
-5. **Close confirmed:** `node scripts/pib-db.mjs complete-action <fid>`
+5. **Close confirmed:** Use `pib_complete_action` (or `node scripts/pib-db.mjs complete-action <fid>`)
 
 If pib-db doesn't exist, skip with a note.
 
@@ -122,23 +126,23 @@ leaving it active is stale state that erodes trust in the work tracker.
 
 When using pib-db (default):
 
-```bash
-node scripts/pib-db.mjs query "
-  SELECT p.fid, p.name,
-    (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) as total,
-    (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 1) as done
-  FROM projects p
-  WHERE p.status = 'active'
-    AND p.deleted_at IS NULL
-    AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) > 0
-    AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) = 0
-"
+Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+```sql
+SELECT p.fid, p.name,
+  (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) as total,
+  (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 1) as done
+FROM projects p
+WHERE p.status = 'active'
+  AND p.deleted_at IS NULL
+  AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) > 0
+  AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) = 0
 ```
 
 For each result: all actions are complete. Propose completing the project:
 - Show the project name and action count (e.g., "prj:abc — My Project (5/5 actions done)")
 - Ask the user to confirm before closing
-- On confirmation: `node scripts/pib-db.mjs query "UPDATE projects SET status = 'done', completed_at = date('now') WHERE fid = '<fid>'"`
+- On confirmation, use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+  `UPDATE projects SET status = 'done', completed_at = date('now') WHERE fid = '<fid>'`
 
 **Design notes:**
 - Projects with zero total actions are excluded — they may be containers

package/templates/skills/debrief/phases/upstream-feedback.md

@@ -80,8 +80,16 @@ friction points (rare), present each separately.
 If the user confirms, deliver the feedback. Detection and delivery
 follow the same pattern as `/cc-extract`:
 
-**If linked** (the CC package resolves to a local directory — check
-if `node -e "console.log(require.resolve('create-claude-cabinet'))"`
+**If this IS the CC source repo** (check: `node -e "const p = require('./package.json'); process.exit(p.name === 'create-claude-cabinet' ? 0 : 1)"` exits 0):
+
+- Write directly to the local `feedback/` directory (create if needed)
+- Filename: `[source-project]-[date]-[short-title].md`
+- This is the dogfood case — the project IS the upstream repo, so
+  feedback goes directly into the local `feedback/` directory.
+
+**If linked** (not the source repo, but CC package resolves to a local
+directory — check if
+`node -e "console.log(require.resolve('create-claude-cabinet'))"`
 points to a local path rather than a `node_modules` path):
 
 - Write the feedback as a markdown file in the CC repo's `feedback/`

package/templates/skills/execute-plans/SKILL.md

@@ -54,16 +54,19 @@ Phase files have three states:
 Read `phases/fetch-plans.md` for where plans come from.
 
 **Default (absent/empty):** Query pib-db for open actions that have
-surface area declarations:
-
-```bash
-node scripts/pib-db.mjs query "
-  SELECT a.fid, a.text, a.notes
-  FROM actions a
-  WHERE a.completed = 0 AND a.deleted_at IS NULL
-    AND a.notes LIKE '%## Surface Area%'
-  ORDER BY a.sort_order
-"
+surface area declarations.
+
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
+Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+```sql
+SELECT a.fid, a.text, a.notes
+FROM actions a
+WHERE a.completed = 0 AND a.deleted_at IS NULL
+  AND a.notes LIKE '%## Surface Area%'
+ORDER BY a.sort_order
 ```
 
 Projects using external APIs, different databases, or filtered project
@@ -198,7 +201,8 @@ and validated (and post-group actions complete, if defined).
 
 Read `phases/completion.md` for how to mark plans as done after execution.
 
-**Default (absent/empty):** Mark completed plans via pib-db:
+**Default (absent/empty):** Mark completed plans via pib-db. Use
+`pib_complete_action` (or CLI fallback):
 ```bash
 node scripts/pib-db.mjs complete-action <fid>
 ```

package/templates/skills/orient/SKILL.md

@@ -136,55 +136,55 @@ whatever the project uses to track work: a backlog, task list, inbox,
 queue, or issue tracker.
 
 **Default (absent/empty):** If `scripts/pib-db.mjs` exists, run the
-standard work scan:
+standard work scan.
+
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
 
 1. **Active projects and open actions:**
-   ```bash
-   node scripts/pib-db.mjs query "
-     SELECT p.fid, p.name,
-       (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) as open_actions
-     FROM projects p
-     WHERE p.status = 'active' AND p.deleted_at IS NULL
-     ORDER BY open_actions DESC
-   "
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name,
+     (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) as open_actions
+   FROM projects p
+   WHERE p.status = 'active' AND p.deleted_at IS NULL
+   ORDER BY open_actions DESC
    ```
 
 2. **Flagged actions** (prioritized items needing attention):
-   ```bash
-   node scripts/pib-db.mjs query "
-     SELECT a.fid, a.text, p.name as project
-     FROM actions a
-     LEFT JOIN projects p ON a.project_fid = p.fid
-     WHERE a.flagged = 1 AND a.completed = 0 AND a.deleted_at IS NULL
-   "
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT a.fid, a.text, p.name as project
+   FROM actions a
+   LEFT JOIN projects p ON a.project_fid = p.fid
+   WHERE a.flagged = 1 AND a.completed = 0 AND a.deleted_at IS NULL
    ```
 
 3. **Staleness detection** — flag projects that need attention:
 
    **Completion candidates** — active projects where all actions are done:
-   ```bash
-   node scripts/pib-db.mjs query "
-     SELECT p.fid, p.name
-     FROM projects p
-     WHERE p.status = 'active' AND p.deleted_at IS NULL
-       AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) > 0
-       AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) = 0
-   "
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name
+   FROM projects p
+   WHERE p.status = 'active' AND p.deleted_at IS NULL
+     AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) > 0
+     AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) = 0
    ```
 
    **Stale projects** — active projects with no action completed in 14+ days:
-   ```bash
-   node scripts/pib-db.mjs query "
-     SELECT p.fid, p.name,
-       MAX(a.completed_at) as last_completion
-     FROM projects p
-     LEFT JOIN actions a ON a.project_fid = p.fid AND a.completed = 1
-     WHERE p.status = 'active' AND p.deleted_at IS NULL
-       AND (SELECT COUNT(*) FROM actions a2 WHERE a2.project_fid = p.fid AND a2.completed = 0 AND a2.deleted_at IS NULL) > 0
-     GROUP BY p.fid
-     HAVING last_completion < date('now', '-14 days')
-       OR last_completion IS NULL
-   "
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name,
+     MAX(a.completed_at) as last_completion
+   FROM projects p
+   LEFT JOIN actions a ON a.project_fid = p.fid AND a.completed = 1
+   WHERE p.status = 'active' AND p.deleted_at IS NULL
+     AND (SELECT COUNT(*) FROM actions a2 WHERE a2.project_fid = p.fid AND a2.completed = 0 AND a2.deleted_at IS NULL) > 0
+   GROUP BY p.fid
+   HAVING last_completion < date('now', '-14 days')
+     OR last_completion IS NULL
    ```
 
    Surface in briefing as actionable signals:

package/templates/skills/plan/SKILL.md

@@ -231,7 +231,14 @@ needs to wire it up later" — the plan is incomplete. Dead code is not
 a feature. A callback nobody calls is not a feature.
 
 **b. Surface area completeness.** Every file mentioned in Implementation
-appears in Surface Area. New files are marked `(new)`.
+appears in Surface Area. New files are marked `(new)`. The Surface Area
+section MUST use the exact format that pib-db validates:
+- Section header: `## Surface Area` (not `### Files`, not `### Surface Area`)
+- Each entry: `- files: path/to/file` or `- dirs: path/to/dir/`
+Do NOT use `### Files` with Created/Modified sublists or any other format
+variant. The database rejects non-conforming notes at the API layer
+(`pib-db-lib.mjs` validates structurally). If the plan uses the wrong
+format, rewrite it before filing.
 
 **c. Acceptance criteria are testable.** Every criterion is pass/fail
 with a category tag ([auto], [manual], [deferred]).
@@ -269,8 +276,13 @@ work item in your project's tracking system.
 **Default (absent/empty):** If `scripts/pib-db.mjs` exists, file the
 approved plan as a pib-db action. Use the plan title as the action text
 and the full plan (with surface area, acceptance criteria, etc.) as the
-notes. If the plan belongs to an existing project, associate it:
+notes. If the plan belongs to an existing project, associate it.
 
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
+Use `pib_create_action` (or CLI fallback):
 ```bash
 node scripts/pib-db.mjs create-action --text "<plan title>" --project "<project fid>" --notes "<full plan>"
 ```

package/templates/skills/plan/phases/overlap-check.md

@@ -10,11 +10,15 @@ proposed work. If pib-db is not initialized, skip gracefully.
 
 ## Default Behavior (pib-db)
 
-When no custom overlap check is configured:
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
 
-```bash
-# Search open actions for keywords related to the proposed work
-node scripts/pib-db.mjs query "SELECT fid, text, substr(notes, 1, 200) as notes_preview FROM actions WHERE completed = 0 AND deleted_at IS NULL AND (text LIKE '%keyword%' OR notes LIKE '%keyword%')"
+When no custom overlap check is configured, use `pib_query` (or
+`node scripts/pib-db.mjs query`) with:
+
+```sql
+SELECT fid, text, substr(notes, 1, 200) as notes_preview FROM actions WHERE completed = 0 AND deleted_at IS NULL AND (text LIKE '%keyword%' OR notes LIKE '%keyword%')
 ```
 
 Search with multiple keywords derived from the proposed plan's problem

package/templates/skills/plan/phases/work-tracker.md

@@ -10,10 +10,14 @@ via `node scripts/pib-db.mjs init`.
 
 ## Default Behavior (pib-db)
 
-When no custom work tracker is configured:
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
+When no custom work tracker is configured, use `pib_create_action` (or
+CLI fallback):
 
 ```bash
-# Create an action for the approved plan
 node scripts/pib-db.mjs create-action "Short imperative plan title" \
   --area "<area>" \
   --notes "## Problem\n...\n\n## Implementation\n..."

package/templates/skills/triage-audit/SKILL.md

@@ -105,10 +105,15 @@ for a cabinet member is signal that the cabinet member's calibration is off.
 Read `phases/load-findings.md` for where to get the findings to triage.
 
 **Default (absent/empty):** Query the reference data layer (pib-db) for
-findings with `triage_status = 'open'`. If pib-db is not initialized or
-has no findings, fall back to reading the most recent
+findings with `triage_status = 'open'`. Use `pib_query` (or
+`node scripts/pib-db.mjs query`) with the appropriate SQL. If pib-db is
+not initialized or has no findings, fall back to reading the most recent
 `reviews/*/run-summary.json` file.
 
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
 Present a summary before triage: how many findings, breakdown by
 severity and cabinet member, how many are new vs previously seen.
 
@@ -142,27 +147,32 @@ decisions.
 **Default (absent/empty):** For each verdict:
 
 **Fix verdicts:**
-1. Update finding's triage_status to 'approved' in pib-db
+1. Update finding's triage_status to 'approved' via `pib_triage`
+   (or `node scripts/pib-db.mjs triage`)
 2. If the finding is marked `autoFixable: true`, attempt the fix
    immediately. Verify the fix works before marking it done.
-3. If not auto-fixable, create an action in pib-db with:
+3. If not auto-fixable, create an action via `pib_create_action`
+   (or `node scripts/pib-db.mjs create-action`) with:
    - Text: the finding title
    - Notes: finding description, evidence, suggested fix
    - Area: derived from cabinet member or finding metadata
 
 **Defer verdicts:**
-1. Update finding's triage_status to 'deferred' in pib-db
+1. Update finding's triage_status to 'deferred' via `pib_triage`
+   (or `node scripts/pib-db.mjs triage`)
 2. Record the user's reason in triage_notes
 3. The finding will be suppressed in future audit runs
 
 **Reject verdicts:**
-1. Update finding's triage_status to 'rejected' in pib-db
+1. Update finding's triage_status to 'rejected' via `pib_triage`
+   (or `node scripts/pib-db.mjs triage`)
 2. Record the user's reason in triage_notes
 3. The finding will be permanently suppressed in future audit runs
 
 **Question verdicts:**
 1. Finding stays open (triage_status remains 'open')
-2. Record the question in triage_notes
+2. Record the question in triage_notes via `pib_triage`
+   (or `node scripts/pib-db.mjs triage`)
 3. The finding will appear again in the next triage
 
 If pib-db is not initialized, write verdicts to

package/templates/skills/triage-audit/phases/apply-verdicts.md

@@ -19,29 +19,38 @@ Define your verdict application strategy:
 
 ## Default Behavior
 
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
 ### Fix Verdicts
-1. Update `triage_status = 'approved'` in pib-db
+1. Update `triage_status = 'approved'` via `pib_triage` (or
+   `node scripts/pib-db.mjs triage`)
 2. If `autoFixable: true`:
    - Attempt the fix based on the finding's `suggestedFix`
    - Verify the fix (run relevant tests or checks)
    - If successful, update `triage_status = 'fixed'`
    - If failed, create an action instead
 3. If not auto-fixable:
-   - Create an action via `node scripts/pib-db.mjs create-action`
+   - Create an action via `pib_create_action` (or
+     `node scripts/pib-db.mjs create-action`)
    - Include finding details in action notes
 
 ### Defer Verdicts
-1. Update `triage_status = 'deferred'` in pib-db
+1. Update `triage_status = 'deferred'` via `pib_triage` (or
+   `node scripts/pib-db.mjs triage`)
 2. Record reason in `triage_notes`
 3. Finding suppressed in future audits via triage history
 
 ### Reject Verdicts
-1. Update `triage_status = 'rejected'` in pib-db
+1. Update `triage_status = 'rejected'` via `pib_triage` (or
+   `node scripts/pib-db.mjs triage`)
 2. Record reason in `triage_notes`
 3. Finding permanently suppressed in future audits
 
 ### Question Verdicts
-1. Finding stays `triage_status = 'open'`
+1. Finding stays `triage_status = 'open'` — record question via
+   `pib_triage` (or `node scripts/pib-db.mjs triage`)
 2. Record question in `triage_notes`
 3. Finding reappears in next triage
 

package/templates/skills/triage-audit/phases/load-findings.md

@@ -4,8 +4,10 @@ Define where the triage skill loads audit findings from. The /triage-audit
 skill reads this file before presenting findings.
 
 When this file is absent or empty, the default behavior is: query pib-db
-for findings with `triage_status = 'open'`, fall back to the most recent
-`reviews/*/run-summary.json`. To explicitly skip, write only `skip: true`.
+for findings with `triage_status = 'open'` using `pib_query` MCP tool
+(or `node scripts/pib-db.mjs query` CLI fallback), fall back to the most
+recent `reviews/*/run-summary.json`. To explicitly skip, write only
+`skip: true`.
 
 ## What to Include
 
@@ -27,9 +29,10 @@ curl -s https://your-api.example.com/api/audit/findings?status=open \
 Returns JSON array of findings in the same format as run-summary.json.
 
 ### Specific Run
-Load findings from a specific audit run instead of all open findings:
-```bash
-node scripts/pib-db.mjs query "SELECT * FROM audit_findings WHERE run_id = 'run-2026-04-01'"
+Load findings from a specific audit run instead of all open findings.
+Use `pib_query` (or `node scripts/pib-db.mjs query` CLI fallback):
+```sql
+SELECT * FROM audit_findings WHERE run_id = 'run-2026-04-01'
 ```
 
 ### Multiple Sources

package/templates/hooks/compaction-recover.sh

@@ -1,46 +0,0 @@
-#!/bin/bash
-# Compaction Recovery — SessionStart command hook (compact matcher)
-#
-# Reads compaction state files written by the PreCompact prompt hook
-# and outputs them to stdout for injection as additionalContext.
-#
-# Files checked:
-#   .claude/compaction-state.md  — always (main state)
-#   .claude/*-partial.md         — any workflow partial state files
-
-PROJECT_DIR="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
-STATE_FILE="$PROJECT_DIR/.claude/compaction-state.md"
-
-# Collect all partial state files
-PARTIAL_FILES=()
-for f in "$PROJECT_DIR"/.claude/*-partial.md; do
-  [ -f "$f" ] && PARTIAL_FILES+=("$f")
-done
-
-# If no state files exist, output fallback message
-if [ ! -f "$STATE_FILE" ] && [ ${#PARTIAL_FILES[@]} -eq 0 ]; then
-  echo "No compaction state found. This session started fresh (no prior compaction state to recover)."
-  exit 0
-fi
-
-echo "=== COMPACTION RECOVERY ==="
-echo ""
-echo "State was saved before compaction. Use this to resume where you left off."
-echo ""
-
-# Output main state file
-if [ -f "$STATE_FILE" ]; then
-  echo "--- compaction-state.md ---"
-  cat "$STATE_FILE"
-  echo ""
-fi
-
-# Output any partial state files
-for f in "${PARTIAL_FILES[@]}"; do
-  BASENAME=$(basename "$f")
-  echo "--- $BASENAME ---"
-  cat "$f"
-  echo ""
-done
-
-echo "=== END COMPACTION RECOVERY ==="

package/templates/hooks/compaction-save.md

@@ -1,46 +0,0 @@
-# Compaction State Save — PreCompact Prompt Hook
-
-Before compaction destroys your current context, you MUST save state so the
-next session can recover. This is not optional — compaction erases everything
-you're holding in working memory.
-
-## Required: Always write .claude/compaction-state.md
-
-Write this file with these structured sections:
-
-```
-# Compaction State
-
-## Current Task
-What you were actively working on. Be specific — include file paths, function
-names, the exact step you were on.
-
-## Decisions Made
-Key decisions from this session that a fresh context needs to know.
-Include the reasoning, not just the conclusion.
-
-## Next Steps
-What should happen immediately after recovery. Ordered list, most urgent first.
-
-## References
-Files, URLs, error messages, or other artifacts that the next context will need.
-```
-
-## Conditional: Write workflow-specific partial state
-
-If you are in the middle of a multi-step workflow with intermediate results,
-ALSO write a partial state file to `.claude/<workflow-name>-partial.md`.
-
-Use the workflow you're currently executing as the filename. Examples:
-- Mid-audit with findings collected so far → `.claude/audit-partial.md`
-- Mid-migration with some files moved → `.claude/migration-partial.md`
-- Mid-refactor tracking what's done → `.claude/refactor-partial.md`
-
-Include whatever intermediate work products would be lost to compaction:
-completed items, partial results, progress tracking, error logs.
-
-## Constraints
-
-- Keep total output under 200 lines across all files written.
-- Use concrete details (file paths, line numbers, variable names), not vague summaries.
-- Write the files using the Edit/Write tools — do not just describe what you would write.