create-claude-cabinet 0.7.2 → 0.7.3

package/README.md

@@ -76,7 +76,7 @@ left off.
 
 ### The Cabinet (included in lean)
 
-20 expert cabinet members who each own a domain and stay in their lane.
+27 expert cabinet members who each own a domain and stay in their lane.
 **Speed-freak** watches performance. **Boundary-man** catches edge cases.
 **Record-keeper** flags when docs drift from code. **Workflow-cop**
 evaluates whether your process actually works. Each member has a
@@ -174,7 +174,7 @@ source code.
 ```
 .claude/
 ├── skills/          # orient, debrief, plan, execute, audit, etc.
-│   └── cabinet-*/   # 20 cabinet member definitions
+│   └── cabinet-*/   # 27 cabinet member definitions
 ├── cabinet/         # committees, lifecycle, composition patterns
 ├── briefing/        # project briefing templates
 ├── hooks/           # git guardrails, telemetry

package/package.json

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

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

@@ -47,7 +47,7 @@ See `_briefing.md` for shared cabinet member context.
 
 ## Identity
 
-You are the **box adoption and configuration health analyst.** Other
+You are the **CC adoption and configuration health analyst.** Other
 cabinet members evaluate the product. Process-therapist evaluates whether skills and
 cabinet members are doing their jobs well -- prompt quality, calibration, overlap.
 You evaluate something different: whether the CC infrastructure is configured
@@ -215,11 +215,26 @@ consolidation, promotion bottlenecks.
 The project evolves. The CC configuration should evolve with it. Check for
 drift between the two:
 
-- **`_briefing.md` freshness.** Compare the shared context file against the
-  current project state. Has `package.json` changed (new dependencies,
-  removed dependencies)? Have new directories appeared that aren't mentioned
-  in scan scopes? Has the deployment architecture changed? Stale context
-  means cabinet members are making decisions based on outdated information.
+- **`_briefing.md` freshness.** Compare the briefing files against the
+  actual project state. Do NOT trust what the briefing says — verify it
+  against the filesystem. Concrete cross-references to make:
+  - `.ccrc.json` modules vs briefing claims about what's installed.
+  - 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.js
+    list-projects`). 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?
+  - Actual directories and files vs what the briefing's paths/jurisdictions
+    section references. New directories that aren't mentioned? Referenced
+    paths that no longer exist?
+  - Split vs monolithic briefing: if the project has enough content for
+    split files but is still using a monolithic `_briefing.md`, flag it.
+  Stale context means cabinet members are making decisions based on
+  outdated information.
 - **Scan scope accuracy.** Do cabinet member `files` frontmatter entries and
   scan scope sections reference directories and files that still exist?
   Scan scopes pointing at moved or deleted paths mean cabinet members are

package/templates/skills/debrief/SKILL.md

@@ -149,6 +149,21 @@ reality so the next orient reads accurate information.
 (or equivalent) needs updating to reflect what was built, fixed, or
 changed.
 
+Also check **briefing freshness** — did this session's work invalidate
+any claims in the briefing files? Common drift signals:
+- Session installed a new module or capability, but the briefing still
+  says it's not available
+- Session changed architecture (new data store, new framework, new
+  deployment), but the briefing describes the old state
+- Version numbers in `.ccrc.json` or briefing don't match `package.json`
+- Work tracking was set up or changed, but `_briefing-work-tracking.md`
+  doesn't reflect it
+
+If the briefing is stale, update the relevant split file (or the
+monolithic `_briefing.md` if the project hasn't split yet). Don't wait
+for `/audit` to catch this — stale briefings degrade every cabinet
+member's judgment until they're fixed.
+
 Also check the **user-level state** (silently — don't make this a
 conversation unless something needs updating):