create-claude-cabinet 0.6.3 → 0.6.4

package/package.json

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

package/templates/README.md

@@ -117,7 +117,7 @@ execution, audit). Each is a named domain expert encoded in markdown.
 | `_briefing-template.md` | 1+2 | Template for the project-specific briefing every cabinet member reads. Wave 2 added: Scan Scopes, API Configuration, Entity Types, User Context. |
 | `_prompt-guide.md` | 2 | Craft knowledge for writing cabinet member prompts. 17 principles including Levitin's cognitive architecture. |
 | `output-contract.md` | 5 | How cabinet members produce structured findings for the audit system. Defines the assumption/evidence/question triad, severity calibration, positive findings, autoFixable field, JSON output format. |
-| `committees-template.yaml` | 5 | Technology-implied starter committees for organizing cabinet members (ux, code, health, process). Copy as `committees.yaml` and customize. |
+| `committees.yaml` | 5 | Upstream committee definitions for organizing cabinet members (ux, code, health, process, strategic). Upstream-owned; project customizations go in `committees-project.yaml`. |
 | `_lifecycle.md` | 5 | When to adopt, retire, and assess cabinet members. Cross-cutting vs grouped distinction. |
 
 ### Memory (1 pattern + 1 template)
@@ -281,7 +281,7 @@ when you outgrow them.
 3. **Copy cabinet member infrastructure:**
    ```bash
    cp process-in-a-box/skills/cabinet/output-contract.md .claude/skills/cabinet/
-   cp process-in-a-box/skills/cabinet/committees-template.yaml .claude/skills/cabinet/
+   cp process-in-a-box/skills/cabinet/committees.yaml .claude/skills/cabinet/
    cp process-in-a-box/skills/cabinet/_lifecycle.md .claude/skills/cabinet/
    ```
 
@@ -294,11 +294,11 @@ when you outgrow them.
    cp process-in-a-box/scripts/finding-schema.json your-project/scripts/
    ```
 
-5. **Set up committees** (optional):
-   ```bash
-   cp .claude/skills/cabinet/committees-template.yaml .claude/skills/cabinet/committees.yaml
-   ```
-   Uncomment the committees relevant to your project.
+5. **Customize committees** (optional):
+   Create a `committees-project.yaml` in `.claude/cabinet/` to add custom
+   members or committees. The upstream `committees.yaml` is installed
+   automatically. Run `node scripts/resolve-committees.js` to see the
+   merged result.
 
 6. **Run your first audit:** `/audit` — it discovers cabinet members, runs
    them, and persists findings. Then `/triage-audit` to review results.
@@ -346,8 +346,9 @@ These are the project-specific pieces to build as you adopt:
   checks as you discover what drifts.
 - **Triage phase files** — Where findings come from, how to present them,
   how to apply verdicts. Defaults use the local triage UI and pib-db.
-- **Committees** — Copy `committees-template.yaml` as `committees.yaml`
-  and uncomment the committees relevant to your technology stack.
+- **Committees** — The upstream `committees.yaml` is installed automatically.
+  Create `committees-project.yaml` to add custom members to upstream
+  committees or define new project-specific committees.
 
 None of this requires working alone. Claude is the constant companion
 throughout — the package provides the structure, and you build the

package/templates/briefing/_briefing-cabinet-template.md

@@ -3,7 +3,9 @@
 ## Active Cabinet Members
 
 *Which cabinet members are active in this project and how they're organized into committees.
-Reference `committees.yaml` for the canonical grouping.*
+Reference `committees.yaml` (upstream) and `committees-project.yaml` (project
+customizations) for the canonical grouping. Run `node scripts/resolve-committees.js`
+to see the merged result.*
 
 ## Portfolio Rules
 

package/templates/cabinet/committees.yaml

@@ -0,0 +1,49 @@
+# Cabinet member committees — canonical groupings of upstream cabinet members.
+#
+# This file is upstream-owned and manifest-tracked. It is updated automatically
+# by the installer. Do not edit — your customizations go in committees-project.yaml.
+#
+# Consumed by:
+#   - /audit skill (committee selection menu)
+#   - scripts/resolve-committees.js (merges with committees-project.yaml)
+#
+# Cross-portfolio cabinet members are NOT in any committee. They activate via
+# standing-mandate in their SKILL.md frontmatter and run on every audit:
+#   anti-confirmation, qa, debugger, organized-mind
+
+committees:
+  ux:
+    name: "UX & Design"
+    members:
+      - usability
+      - accessibility
+      - small-screen
+
+  code:
+    name: "Code Quality"
+    members:
+      - technical-debt
+      - architecture
+      - boundary-man
+
+  health:
+    name: "System Health"
+    members:
+      - security
+      - data-integrity
+      - speed-freak
+
+  process:
+    name: "Process & Meta"
+    members:
+      - workflow-cop
+      - record-keeper
+      - process-therapist
+      - roster-check
+      - cc-health
+
+  strategic:
+    name: "Strategic"
+    members:
+      - system-advocate
+      - historian

package/templates/cabinet/lifecycle.md

@@ -60,7 +60,9 @@ of calibration quality.
 
 ## Cross-Portfolio vs Committee-Assigned
 
-Most cabinet members belong in exactly one committee (see `committees-template.yaml`).
+Most cabinet members belong in exactly one committee (see `committees.yaml`
+for upstream committees and `committees-project.yaml` for project-specific
+additions).
 They cover a specific domain and stay in their portfolio.
 
 **Cross-portfolio cabinet members** intentionally span domains. Their expertise
@@ -85,7 +87,9 @@ A cabinet member is a skill with `user-invocable: false`. Create it in
 5. **Calibration Examples** — good findings, wrong-portfolio findings, severity
    anchors
 
-Add the cabinet member to your `committees.yaml` under the appropriate committee.
+Add the cabinet member to your `committees-project.yaml` under the appropriate
+committee (using `additional_members` to append to an upstream committee, or
+a new committee definition).
 It's automatically discovered by the audit skill.
 
 The best cabinet members emerge from real incidents and real audit findings.

package/templates/scripts/resolve-committees.js

@@ -0,0 +1,218 @@
+#!/usr/bin/env node
+'use strict';
+
+/**
+ * resolve-committees.js — Merge upstream committees.yaml with project committees-project.yaml
+ *
+ * Usage:
+ *   node scripts/resolve-committees.js [path-to-claude-dir]
+ *
+ * Default path: .claude
+ *
+ * Reads:
+ *   <claude-dir>/cabinet/committees.yaml        (upstream, required)
+ *   <claude-dir>/cabinet/committees-project.yaml (project, optional)
+ *
+ * Merge rules:
+ *   - Project `additional_members` appends to upstream member lists
+ *   - Project `members` replaces upstream member lists entirely
+ *   - Project `skip: true` removes that committee
+ *   - Project `name` overrides upstream display name
+ *   - New committees in project file are added
+ *
+ * Outputs merged JSON to stdout.
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+// --- Simple YAML parser (handles only what we need) ---
+
+function parseSimpleYaml(text) {
+  // Our YAML is exactly 3 levels deep with 2-space indentation:
+  //   committees:           (indent 0 — top level)
+  //     ux:                 (indent 2 — committee name)
+  //       name: "UX"       (indent 4 — property)
+  //       members:          (indent 4 — property, value is list below)
+  //         - usability     (indent 6+ — list item)
+  const result = {};
+  const lines = text.split('\n');
+  let topKey = null;       // e.g., 'committees'
+  let committeeKey = null; // e.g., 'ux'
+  let propKey = null;      // e.g., 'members'
+
+  for (const line of lines) {
+    const trimmed = line.trimEnd();
+    if (trimmed === '' || /^\s*#/.test(trimmed)) continue;
+
+    const indent = line.length - line.trimStart().length;
+    const content = trimmed.trim();
+
+    if (indent === 0) {
+      const m = content.match(/^(\w[\w-]*):\s*(.*)$/);
+      if (m) {
+        topKey = m[1];
+        result[topKey] = {};
+        committeeKey = null;
+        propKey = null;
+      }
+    } else if (indent >= 2 && indent < 4 && topKey) {
+      // Committee name level
+      const m = content.match(/^(\w[\w-]*):\s*(.*)$/);
+      if (m) {
+        committeeKey = m[1];
+        const val = m[2].trim();
+        if (val === 'true' || val === 'false') {
+          result[topKey][committeeKey] = parseValue(val);
+        } else {
+          result[topKey][committeeKey] = {};
+        }
+        propKey = null;
+      }
+    } else if (indent >= 4 && indent < 6 && topKey && committeeKey) {
+      // Property level (name, members, additional_members, skip)
+      const m = content.match(/^(\w[\w-]*):\s*(.*)$/);
+      if (m) {
+        propKey = m[1];
+        const val = m[2].trim();
+        if (val && val !== '') {
+          result[topKey][committeeKey][propKey] = parseValue(val);
+        } else {
+          // Empty value — will be a list (members:) or object
+          result[topKey][committeeKey][propKey] = [];
+        }
+      }
+    } else if (indent >= 6 && topKey && committeeKey && propKey) {
+      // List item
+      const m = content.match(/^- (.+)$/);
+      if (m) {
+        const container = result[topKey][committeeKey];
+        if (!Array.isArray(container[propKey])) {
+          container[propKey] = [];
+        }
+        container[propKey].push(m[1].trim());
+      }
+    }
+  }
+
+  return result;
+}
+
+function parseValue(str) {
+  if (str === 'true') return true;
+  if (str === 'false') return false;
+  if (str === 'null') return null;
+  // Strip quotes
+  if ((str.startsWith('"') && str.endsWith('"')) || (str.startsWith("'") && str.endsWith("'"))) {
+    return str.slice(1, -1);
+  }
+  // Try number
+  if (/^-?\d+(\.\d+)?$/.test(str)) return Number(str);
+  return str;
+}
+
+// --- Main ---
+
+function main() {
+  const claudeDir = process.argv[2] || '.claude';
+  const upstreamPath = path.join(claudeDir, 'cabinet', 'committees.yaml');
+  const projectPath = path.join(claudeDir, 'cabinet', 'committees-project.yaml');
+
+  // Read upstream (required)
+  if (!fs.existsSync(upstreamPath)) {
+    console.error(`Error: Upstream committees file not found at ${upstreamPath}`);
+    console.error('');
+    console.error('This file is installed by Claude Cabinet and should be at:');
+    console.error(`  ${upstreamPath}`);
+    console.error('');
+    console.error('Run the Claude Cabinet installer to restore it, or check that');
+    console.error('the path to your .claude directory is correct.');
+    process.exit(1);
+  }
+
+  let upstreamText;
+  try {
+    upstreamText = fs.readFileSync(upstreamPath, 'utf8');
+  } catch (err) {
+    console.error(`Error reading ${upstreamPath}: ${err.message}`);
+    process.exit(1);
+  }
+
+  let upstream;
+  try {
+    upstream = parseSimpleYaml(upstreamText);
+  } catch (err) {
+    console.error(`Error parsing ${upstreamPath}: ${err.message}`);
+    console.error('The file may be malformed. Check that it uses valid YAML syntax.');
+    process.exit(1);
+  }
+
+  const committees = upstream.committees || {};
+
+  // Read project overrides (optional)
+  if (!fs.existsSync(projectPath)) {
+    // No project file — output upstream as-is
+    console.log(JSON.stringify({ committees }, null, 2));
+    return;
+  }
+
+  let projectText;
+  try {
+    projectText = fs.readFileSync(projectPath, 'utf8');
+  } catch (err) {
+    console.error(`Error reading ${projectPath}: ${err.message}`);
+    process.exit(1);
+  }
+
+  let project;
+  try {
+    project = parseSimpleYaml(projectText);
+  } catch (err) {
+    console.error(`Error parsing ${projectPath}: ${err.message}`);
+    console.error('The file may be malformed. Check that it uses valid YAML syntax.');
+    process.exit(1);
+  }
+
+  const projectCommittees = project.committees || {};
+
+  // Merge
+  const merged = Object.assign({}, committees);
+
+  for (const key of Object.keys(projectCommittees)) {
+    const projectDef = projectCommittees[key];
+
+    // skip: true removes the committee
+    if (projectDef && projectDef.skip === true) {
+      delete merged[key];
+      continue;
+    }
+
+    if (merged[key]) {
+      // Existing upstream committee — apply overrides
+      if (projectDef.name) {
+        merged[key] = Object.assign({}, merged[key], { name: projectDef.name });
+      }
+
+      if (Array.isArray(projectDef.members)) {
+        // Full replacement
+        merged[key] = Object.assign({}, merged[key], { members: projectDef.members });
+      } else if (Array.isArray(projectDef.additional_members)) {
+        // Append to upstream
+        const existing = Array.isArray(merged[key].members) ? merged[key].members : [];
+        merged[key] = Object.assign({}, merged[key], {
+          members: existing.concat(projectDef.additional_members)
+        });
+      }
+    } else {
+      // New committee from project
+      merged[key] = {
+        name: projectDef.name || key,
+        members: Array.isArray(projectDef.members) ? projectDef.members : []
+      };
+    }
+  }
+
+  console.log(JSON.stringify({ committees: merged }, null, 2));
+}
+
+main();

package/templates/skills/audit/SKILL.md

@@ -111,10 +111,15 @@ project. Adjust.
 Read `phases/member-selection.md` for which cabinet members to run.
 
 **Default (absent/empty):** Discover all cabinet members from
-`skills/cabinet-*/SKILL.md`. If `cabinet/committees.yaml`
-exists (copied from `committees-template.yaml`), present committees and let the
-user choose which to run. If no committees file exists, run all discovered
-cabinet members.
+`skills/cabinet-*/SKILL.md`. Run `node scripts/resolve-committees.js` to
+get the merged committee list (upstream `cabinet/committees.yaml` merged
+with project `cabinet/committees-project.yaml`). Present the merged
+committees and let the user choose which to run. If neither committees
+file exists, run all discovered cabinet members.
+
+Cross-portfolio cabinet members (anti-confirmation, qa, debugger,
+organized-mind) always run regardless of committee selection — they
+activate via `standing-mandate` in their SKILL.md frontmatter.
 
 The selection determines what the audit looks at. A full audit runs
 everything; a focused audit runs one committee or a specific set of

package/templates/skills/audit/phases/member-selection.md

@@ -4,9 +4,11 @@ Define how the audit selects which cabinet members to run. The /audit skill
 reads this file before spawning cabinet member agents.
 
 When this file is absent or empty, the default behavior is: discover all
-cabinet members from `skills/cabinet-*/SKILL.md`, present committees if
-`committees.yaml` exists, otherwise run all. To explicitly skip member
-selection (and run no audit), write only `skip: true`.
+cabinet members from `skills/cabinet-*/SKILL.md`, run
+`node scripts/resolve-committees.js` to merge upstream `cabinet/committees.yaml`
+with project `cabinet/committees-project.yaml`, present merged committees,
+otherwise run all. Cross-portfolio members always run regardless of selection.
+To explicitly skip member selection (and run no audit), write only `skip: true`.
 
 ## What to Include
 
@@ -26,14 +28,11 @@ Discover all cabinet members in `skills/cabinet-*/SKILL.md`.
 Run every one. Good for small projects with few cabinet members.
 
 ### Committee-Based Selection
-Read `cabinet/committees.yaml` for committee definitions.
-Present committees to the user:
-  1. ux — accessibility, small-screen
-  2. code — technical-debt, architecture
-  3. health — security, data-integrity, speed-freak
-  4. process — workflow-cop, record-keeper
-
-Cross-portfolio cabinet members (marked in committees.yaml) always run
+Run `node scripts/resolve-committees.js` to merge upstream
+`cabinet/committees.yaml` with project `cabinet/committees-project.yaml`.
+Present merged committees to the user.
+
+Cross-portfolio cabinet members (standing-mandate in SKILL.md) always run
 regardless of committee selection.
 
 ### Targeted Audit

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

@@ -15,7 +15,8 @@ files:
   - .claude/skills/*/SKILL.md
   - .claude/skills/*/phases/*.md
   - .claude/skills/cabinet-*/SKILL.md
-  - .claude/skills/cabinet-*/committees.yaml
+  - .claude/cabinet/committees.yaml
+  - .claude/cabinet/committees-project.yaml
   - .claude/hooks/*.sh
 topics:
   - cc health
@@ -30,8 +31,11 @@ related:
     path: .claude/skills/cabinet-*/_lifecycle.md
     role: "Cabinet member lifecycle — when to adopt, when to retire"
   - type: file
-    path: .claude/skills/cabinet-*/committees-template.yaml
-    role: "Committee structure template"
+    path: .claude/cabinet/committees.yaml
+    role: "Upstream committee definitions (installer-owned)"
+  - type: file
+    path: .claude/cabinet/committees-project.yaml
+    role: "Project committee customizations (user-owned)"
   - type: file
     path: .claude/skills/cabinet-process-therapist/SKILL.md
     role: "Adjacent cabinet member — skill quality (not adoption health)"
@@ -90,7 +94,7 @@ Also activates when:
 - New skills or cabinet members are added (adoption decision to evaluate)
 - Phase files are modified (customization to assess)
 - Hook scripts are changed (enforcement layer shift)
-- `committees.yaml` is updated (committee composition change)
+- `committees.yaml` or `committees-project.yaml` is updated (committee composition change)
 
 ## Research Method
 
@@ -127,8 +131,10 @@ empty").
 
 ### 2. Cabinet Member Activation Patterns
 
-Read `committees.yaml` to understand which cabinet members are active and how they're
-grouped. Cross-reference against:
+Run `node scripts/resolve-committees.js` to get the merged committee list
+(upstream `committees.yaml` + project `committees-project.yaml`). Also
+validate that any members listed in `committees-project.yaml` actually
+exist as `cabinet-*` directories. Cross-reference against:
 
 - **Technology signals.** Does the project's stack imply cabinet members that
   aren't activated? (React app without accessibility? API without security?
@@ -387,8 +393,9 @@ entropy.
 ### Scan Scope
 
 - `.claude/skills/` — all skill definitions and phase files
-- `.claude/skills/cabinet-*/` — all cabinet member definitions, `committees.yaml`,
-  `_briefing.md`, `_lifecycle.md`, `committees.yaml`
+- `.claude/skills/cabinet-*/` — all cabinet member definitions
+- `.claude/cabinet/` — `committees.yaml`, `committees-project.yaml`,
+  `_lifecycle.md`, and other infrastructure
 - `.claude/hooks/` — hook scripts
 - `.claude/settings.json` — hook configuration
 - `memory/patterns/` — enforcement pipeline state
@@ -409,7 +416,7 @@ Do not cross into adjacent cabinet members' territory:
   That's process-therapist. You care whether the skill is *installed and used*,
   not whether its output is good.
 - **One-time setup** — initial CC installation, first-time skeleton
-  adoption, bootstrapping `committees.yaml`. That's the onboard skill. You
+  adoption, bootstrapping `committees-project.yaml`. That's the onboard skill. You
   evaluate the ongoing health of an already-adopted configuration, not the
   initial adoption process.
 - **Specific technology expertise** — you don't know whether React components

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

@@ -305,6 +305,22 @@ The upgrade skill only surfaces phase opportunities that are *relevant
 to what changed* in this upgrade — including cases where the project's
 context makes a default obviously insufficient.
 
+#### Committees Split Migration
+If the project has a project-owned `committees.yaml` that contains custom
+content (members not in the new upstream `committees.yaml`), split it:
+1. Compare the project's existing `committees.yaml` against the new upstream
+   version to identify which members are upstream and which are custom
+2. Generate `committees-project.yaml` with only the custom additions
+   (using `additional_members` for appending to upstream committees, or
+   new committee definitions for entirely custom committees)
+3. Present the split to the user — show what goes in `committees-project.yaml`
+   and explain that the installer's `committees.yaml` is now upstream-owned
+4. After approval, let the installer overwrite `committees.yaml` with the
+   upstream version, and write the custom content to `committees-project.yaml`
+
+If the project's `committees.yaml` matches the upstream version exactly
+(no custom content), no migration is needed.
+
 #### Schema Migrations
 If the upstream schema has new columns or tables:
 - Detect the difference between the shipped schema and the project's DB

package/templates/skills/debrief/SKILL.md

@@ -262,7 +262,7 @@ relevant expertise ever activates because nobody ran `/seed`.
 touched. Did the work involve a framework, library, data store, or
 infrastructure that isn't covered by any existing cabinet member? Compare
 against the cabinet members in `.claude/skills/cabinet-*/` and the
-committees in `committees.yaml`.
+merged committees (run `node scripts/resolve-committees.js`).
 
 Examples of what to catch:
 - Session used Mantine components but there's no framework-quality
@@ -272,8 +272,8 @@ Examples of what to catch:
 - Session built UI but accessibility isn't in any active committee
 
 **Check B — Dormant cabinet member that should be active.** Are there
-cabinet members installed in the project that aren't in any `committees.yaml`
-committee, but based on the last few sessions, probably should be? A
+cabinet members installed in the project that aren't in any committee
+(check merged output from `node scripts/resolve-committees.js`), but based on the last few sessions, probably should be? A
 cabinet member sitting dormant while the project does exactly the kind of
 work it's designed to review is a waste.
 
@@ -303,7 +303,7 @@ or:
 > sense as it grows. Want me to set that up?"
 
 If the user says yes, either:
-- Activate a dormant cabinet member (add it to `committees.yaml`)
+- Activate a dormant cabinet member (add it to `committees-project.yaml`)
 - Run `/seed` to build a new one
 - Install a Tier 3 cabinet member that isn't in the project yet
 

package/templates/skills/onboard/phases/post-onboard-audit.md

@@ -45,7 +45,7 @@ generated phase files:
 - **Skipped modules:** No phase file should reference a skipped module's
   infrastructure. If work-tracking was skipped, no phase should reference
   `pib.db` or `pib-db.js`. If audit was skipped, no phase should reference
-  `committees.yaml` or cabinet member activation.
+  `committees.yaml`, `committees-project.yaml`, or cabinet member activation.
 - **Installed modules:** Each installed module should have at least a
   minimal presence in the generated configuration. A module that's installed
   but has zero phase file references is a configuration gap.
@@ -75,7 +75,8 @@ technologies against the cabinet member catalog:
 - **Many skills (5+)** → roster-check
 - **Features shipping regularly** → system-advocate
 
-If implied cabinet members aren't in `committees.yaml` (or equivalent), note
+If implied cabinet members aren't in the merged committees (upstream
+`committees.yaml` + project `committees-project.yaml`), note
 it as a recommendation — not a blocker. The user may have good reasons
 to skip them, or may want to add them later via `/seed`.
 

package/templates/skills/seed/SKILL.md

@@ -137,7 +137,10 @@ collaborative expertise-building conversation:
 4. Walk through Identity, Research Method, Boundaries, and Calibration
    with the user
 5. Create the file in `cabinet-{name}/SKILL.md`
-6. Update `committees.yaml` if the cabinet member belongs in a committee
+6. Update `committees-project.yaml` if the cabinet member belongs in a committee
+   (add to `additional_members` of an existing upstream committee, or create
+   a new committee definition). Create `committees-project.yaml` if it
+   doesn't exist yet.
 
 This is co-authoring, not auto-generating. The user's domain knowledge
 is what makes a cabinet member useful for their specific project. A generic

package/templates/skills/seed/phases/build-member.md

@@ -69,8 +69,11 @@ Write the cabinet member's `SKILL.md` following `_lifecycle.md` guidance:
 
 ### Step 4: Wire It Up
 
-- Add to `committees.yaml` under the appropriate committee (unless it's
-  cross-portfolio, in which case it activates via `standing-mandate` signals)
+- Add to `committees-project.yaml` under the appropriate committee — use
+  `additional_members` to append to an existing upstream committee, or create
+  a new committee definition. Create `committees-project.yaml` if it doesn't
+  exist yet. (Unless the cabinet member is cross-portfolio, in which case it
+  activates via `standing-mandate` signals and needs no committee entry.)
 - Verify the cabinet member is discoverable by the audit skill
 
 ### Emphasis

package/templates/cabinet/committees-template.yaml

@@ -1,49 +0,0 @@
-# Cabinet member committees — canonical mapping of committee slugs to cabinet member lists.
-#
-# Copy this file as committees.yaml and uncomment/customize the committees that
-# match your project. Technology choices imply expertise needs: if your
-# project has a UI, you need a UI committee. If it has an API, you need
-# a system health committee.
-#
-# Consumed by:
-#   - /audit skill (committee selection menu)
-#   - scripts (--committee flag, resolve-committees helpers)
-#
-# Cross-portfolio cabinet members are NOT in any committee. They activate via
-# standing-mandate in their SKILL.md frontmatter:
-#   anti-confirmation, qa, debugger, organized-mind
-
-committees:
-  # -- If your project has a user interface --
-  # ux:
-  #   name: "UX & Design"
-  #   members:
-  #     - accessibility
-  #     - small-screen
-  #     # Add framework-specific cabinet members (e.g., mantine-quality, tailwind-quality)
-
-  # -- If your project has code (most projects) --
-  # code:
-  #   name: "Code Quality"
-  #   members:
-  #     - technical-debt
-  #     - boundary-man
-  #     # Add: architecture (if multi-layer system)
-
-  # -- If your project has an API, database, or infrastructure --
-  # health:
-  #   name: "System Health"
-  #   members:
-  #     - security
-  #     - data-integrity
-  #     - speed-freak
-  #     # Add: sync-health (if remote sync), deployment (if CI/CD)
-
-  # -- If your project has established process/methodology --
-  # process:
-  #   name: "Process & Meta"
-  #   members:
-  #     - workflow-cop
-  #     - record-keeper
-  #     - process-therapist
-  #     - cc-health           # CC adoption health, configuration drift, anti-bloat