create-claude-cabinet 0.12.1 → 0.13.1

package/lib/cli.js

@@ -266,6 +266,11 @@ function generateSkillIndex(projectDir) {
       entry.directives = fm.directives;
     }
 
+    // Tools (declared capabilities for audit/plan member selection)
+    if (Array.isArray(fm.tools)) {
+      entry.tools = fm.tools;
+    }
+
     // Merge project directive overlay (if any)
     const overlay = projectDirectives[dir.name];
     if (overlay) {
@@ -284,6 +289,42 @@ function generateSkillIndex(projectDir) {
     entries.push(entry);
   }
 
+  // Index plugin skills if .claude-plugin/plugin.json exists
+  const pluginFile = path.join(projectDir, '.claude-plugin', 'plugin.json');
+  if (fs.existsSync(pluginFile)) {
+    try {
+      const pluginDef = JSON.parse(fs.readFileSync(pluginFile, 'utf8'));
+      const pluginSkills = pluginDef.skills || [];
+      for (const skillPath of pluginSkills) {
+        const skillFile = path.join(projectDir, skillPath, 'SKILL.md');
+        if (!fs.existsSync(skillFile)) continue;
+
+        const content = fs.readFileSync(skillFile, 'utf8');
+        const fm = parseFrontmatter(content);
+        if (!fm || !fm.name) continue;
+
+        let shortDesc = (fm.description || '').replace(/\s*Use when:.*$/is, '').trim();
+        const sentenceEnd = shortDesc.match(/\.\s/);
+        if (sentenceEnd) shortDesc = shortDesc.slice(0, sentenceEnd.index + 1);
+
+        const entry = {
+          name: fm.name,
+          path: `${skillPath}/SKILL.md`,
+          description: shortDesc,
+          type: 'plugin',
+          source: pluginDef.name || 'plugin',
+        };
+
+        if (fm['disable-model-invocation'] === 'true') entry.manual = true;
+        if (fm['user-invocable'] === 'false') entry.userInvocable = false;
+
+        entries.push(entry);
+      }
+    } catch (e) {
+      console.warn(`  Warning: could not parse ${pluginFile}: ${e.message}`);
+    }
+  }
+
   entries.sort((a, b) => a.name.localeCompare(b.name));
 
   const index = {
@@ -373,7 +414,7 @@ const MODULES = {
     mandatory: false,
     default: true,
     lean: true,
-    templates: ['skills/onboard', 'skills/seed', 'skills/cc-upgrade', 'skills/link', 'skills/unlink', 'skills/extract'],
+    templates: ['skills/onboard', 'skills/seed', 'skills/cc-upgrade', 'skills/cc-link', 'skills/cc-unlink', 'skills/cc-extract', 'skills/cc-feedback'],
   },
   'validate': {
     name: 'Validate',
@@ -755,7 +796,7 @@ async function run() {
         // Note: publish is CC-source-repo-only, not shipped to consumers.
         const alwaysCopyPhases = [
           'skills/onboard', 'skills/seed',
-          'skills/cc-upgrade', 'skills/extract',
+          'skills/cc-upgrade', 'skills/cc-extract',
         ];
         const isSkill = tmpl.startsWith('skills/') && !alwaysCopyPhases.some(p => tmpl.startsWith(p));
         const results = await copyTemplates(srcPath, destPath, {

package/package.json

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

package/templates/README.md

@@ -40,20 +40,20 @@ templates, see [EXTENSIONS.md](EXTENSIONS.md).
 | `skills/debrief-quick/` | Quick debrief variant — core phases only, skip presentation. |
 | `skills/execute/` | Execute a plan with cabinet member checkpoints. 3-checkpoint protocol (pre-implementation, per-file-group, pre-commit). 5 phase files. |
 | `skills/execute-plans/` | Batch execution of multiple plans with conflict detection. |
-| `skills/extract/` | Analyze project artifacts and propose upstream extraction candidates for Claude Cabinet. |
+| `skills/cc-extract/` | Analyze project artifacts and propose upstream extraction candidates for Claude Cabinet. |
 | `skills/investigate/` | Structured codebase exploration: frame, observe, hypothesize, test, conclude. |
-| `skills/link/` | Set up local development linking for Claude Cabinet source repo work. |
+| `skills/cc-link/` | Set up local development linking for Claude Cabinet source repo work. |
 | `skills/memory/` | Browse, search, and manage semantic memory via omega. |
 | `skills/menu/` | Dynamically discover and display all available skills. Reads from `_index.json`. |
 | `skills/onboard/` | Conversational onboarding. Interviews you, generates briefings, wires the session loop. Re-runnable. 8 phase files. |
 | `skills/orient/` | Session start. Load context, sync data, scan work, run health checks, spawn cabinet consultations, show skills menu. 7 phase files. |
 | `skills/orient-quick/` | Quick orient variant — core phases only, skip presentation. |
 | `skills/plan/` | Structured planning with cabinet critique. Research, overlap check, draft, critique, completeness, present, file. 9 phase files. |
-| `skills/publish/` | Publish workflow (CC source repo only, not shipped to consumers). |
+| `skills/cc-publish/` | Publish workflow (CC source repo only, not shipped to consumers). |
 | `skills/pulse/` | Self-description accuracy check. Count freshness, dead references, staleness. 3 phase files. |
 | `skills/seed/` | Recruit new cabinet members. Detect technology signals, propose expertise, build collaboratively. 4 phase files. |
 | `skills/triage-audit/` | Audit finding triage via local web UI or CLI. Load, present, apply verdicts. 3 phase files. |
-| `skills/unlink/` | Remove local development linking. Returns to published npm package. |
+| `skills/cc-unlink/` | Remove local development linking. Returns to published npm package. |
 | `skills/validate/` | Run structural validation checks. Validators defined in phase files. |
 | `skills/work-tracker/` | Open the work tracking UI interactively. Starts local server. |
 

package/templates/cabinet/_cabinet-member-template.md

@@ -0,0 +1,165 @@
+# Cabinet Member Template
+
+Use this template when creating new cabinet members via `/seed` or
+manually. Every section is required unless marked optional. The structure
+ensures consistent quality across the cabinet and enables validation.
+
+## Reference Implementation
+
+See `cabinet-security/SKILL.md` for a fully upgraded example showing
+all sections in practice.
+
+---
+
+## Required Frontmatter
+
+```yaml
+---
+name: cabinet-{name}
+description: >
+  One sentence: what this member evaluates and why it matters.
+  Start with a role noun ("Security engineer who...", "Performance
+  analyst who...", "Data coherence analyst who...").
+user-invocable: false
+briefing:
+  - _briefing-identity.md
+  # Add other briefing files relevant to this member's domain
+  # Common: _briefing-architecture.md, _briefing-jurisdictions.md, _briefing-api.md
+standing-mandate: audit
+  # Add plan, execute, orient, debrief if this member should activate
+  # in those contexts. Most members are audit-only.
+tools:
+  # List every external tool/command this member uses.
+  # Format: "tool-name (scope -- what it does)"
+  # Examples:
+  #   - npm audit (Node projects -- dependency vulnerabilities)
+  #   - sqlite3 (SQLite projects -- index coverage, EXPLAIN QUERY PLAN)
+  #   - grep patterns (all projects -- dead code detection)
+  # Use "tools: []" for pure-reasoning members with no tool stage.
+directives:
+  # Only if standing-mandate includes plan, execute, orient, or debrief.
+  # Each directive is a one-sentence focused task for that context.
+  # plan: >
+  #   What to evaluate when reviewing a plan.
+  # execute: >
+  #   What to watch for during code execution.
+---
+```
+
+## Required Sections (in order)
+
+### 1. Identity
+
+Who this expert is. What they care about. What threat model or quality
+dimension they evaluate. One role, bounded scope, specific to the
+project's actual risk profile.
+
+Include:
+- The expert's perspective in **bold** ("You are a **security engineer**
+  thinking about...")
+- The bounded threat model or quality dimension
+- What this is NOT about (calibrate expectations)
+
+### 2. Convening Criteria
+
+When this member activates:
+- `standing-mandate` contexts
+- File patterns that trigger activation
+- Topic keywords
+- Any mandatory-for triggers (e.g., "all plans that add API endpoints")
+
+### 3. Investigation Protocol
+
+**Two stages: measure first, then reason.**
+
+#### Stage 1: Instrument
+
+Concrete commands to run. Each tool is optional — include an explicit
+fallback for when the tool is unavailable:
+
+```markdown
+**1a. [Check name]**
+
+\`\`\`bash
+# The command to run
+tool-name --flags 2>/dev/null
+\`\`\`
+
+Parse output and flag [specific conditions]. If [tool] is unavailable:
+[manual fallback — what to grep, read, or check instead].
+```
+
+Rules:
+- Every tool reference MUST have an "if unavailable" fallback
+- Fallbacks should be grep patterns, file reading, or manual checklists
+- The member must produce useful findings with zero tools available
+- Include a "Stage 1 results" summary template
+
+#### Stage 2: Analyze
+
+Manual code reading and reasoning informed by Stage 1 results. This is
+where domain expertise matters — tools find candidates, analysis
+confirms and contextualizes them.
+
+Group analysis areas with clear labels (2a, 2b, 2c...). Reference
+relevant standards by number where applicable (OWASP, WCAG, etc.).
+
+### 4. Scan Scope
+
+What files and directories to examine. Reference `_briefing.md` for
+project-specific paths. Use comments to tell consuming projects where
+to customize.
+
+### 5. Portfolio Boundaries
+
+What this member does NOT own. Name the other cabinet member responsible
+for each excluded area. This prevents overlap and scope creep.
+
+Format: "X concerns (that's {other-member})"
+
+### 6. Calibration Examples
+
+2-4 examples at different severities showing what a finding looks like.
+Include at least one "not a finding" and one "wrong portfolio" example
+to anchor the boundaries.
+
+### 7. Historically Problematic Patterns
+
+Two-file overlay:
+
+```markdown
+## Historically Problematic Patterns
+
+Two sources — read both and merge at runtime:
+
+1. **This section** (upstream, CC-owned) — universal patterns that apply to
+   any project. Grows when consuming projects promote recurring findings
+   via field-feedback.
+2. **`patterns-project.md`** in this skill's directory — project-specific
+   patterns discovered during audits of this particular project. Project-
+   owned, never overwritten by CC upgrades.
+
+If `patterns-project.md` exists, read it alongside this section. Both
+inform your analysis equally.
+
+**How patterns get here:** A consuming project's audit finds a real issue.
+If the same pattern recurs across projects, it gets promoted upstream via
+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 -->
+```
+
+This section starts empty for new members. It accumulates from real
+findings over time — never pre-fill with hypothetical patterns.
+
+## Optional Sections
+
+- **directives** (frontmatter) — only if the member activates in
+  non-audit contexts
+- **activation** (frontmatter) — file patterns and topic keywords,
+  if different from convening criteria
+- **Knowledge Sources** — if the member uses MCP servers, WebSearch,
+  or framework documentation
+- **interactive-only** (frontmatter) — set to `true` if the member
+  requires preview tools or a running dev server

package/templates/cabinet/directives-project.yaml

@@ -15,9 +15,9 @@
 # Format:
 #
 #   cabinet-record-keeper:
-#     standing-mandate: [publish]
+#     standing-mandate: [cc-publish]
 #     directives:
-#       publish: >
+#       cc-publish: >
 #         Check all docs for staleness and missing additions
 #         before the version is published.
 #

package/templates/cabinet/lifecycle.md

@@ -76,16 +76,25 @@ audits where it doesn't belong, and miss unassigned contexts where it does.
 
 ## Creating a New Cabinet Member
 
-A cabinet member is a skill with `user-invocable: false`. Create it in
-`.claude/skills/cabinet-{name}/SKILL.md` with:
+A cabinet member is a skill with `user-invocable: false`. Use the
+template at `.claude/cabinet/_cabinet-member-template.md` for the
+required structure. Create in `.claude/skills/cabinet-{name}/SKILL.md`
+with:
 
 1. **Identity** — who is this expert? What do they care about?
 2. **Convening Criteria** — `standing-mandate`, `files`, `topics`
-3. **Research Method** — what to examine, what tools to use, what to
-   reason about
+3. **Investigation Protocol** — two-stage: Stage 1 (Instrument) runs
+   automated tools with explicit "if unavailable" fallbacks, Stage 2
+   (Analyze) does manual reasoning informed by Stage 1 results
 4. **Boundaries** — what this cabinet member does NOT own (prevents overlap)
 5. **Calibration Examples** — good findings, wrong-portfolio findings, severity
    anchors
+6. **Historically Problematic Patterns** — two-file overlay: upstream
+   section (CC-owned) + `patterns-project.md` (project-owned)
+
+Required frontmatter: `name`, `description`, `user-invocable: false`,
+`briefing`, `standing-mandate`, `tools` (list every tool the member
+uses; `tools: []` for pure-reasoning members).
 
 Add the cabinet member to your `committees-project.yaml` under the appropriate
 committee (using `additional_members` to append to an upstream committee, or

package/templates/cabinet/prompt-guide.md

@@ -146,8 +146,9 @@ Forcing premature classification degrades the taxonomy. The
 "uncategorized" state is legitimate infrastructure, not technical debt.
 
 ### 16. Affordances in Skill Templates
-The template structure (Identity → Convening Criteria → Research Method
-→ Boundaries → Calibration Examples) is itself an affordance system.
+The template structure (Identity → Convening Criteria → Investigation Protocol
+→ Boundaries → Calibration Examples → Historically Problematic Patterns) is
+itself an affordance system.
 Each section tells the agent *how to use the skill* without needing
 external memory. If a new skill requires reading documentation outside
 itself to be invoked correctly, the template has failed.
@@ -244,9 +245,11 @@ Files: glob patterns that trigger this cabinet member (also in frontmatter `file
 Topics: keywords that trigger this cabinet member (also in frontmatter `topics`)
 Standing-mandate: which contexts always activate this cabinet member (frontmatter `standing-mandate`)
 
-## Research Method
-Where to get information, how to investigate, what to examine.
-Merged from Knowledge Base + What to Reason About + Paths.
+## Investigation Protocol
+Two-stage investigation: Stage 1 (Instrument) runs automated tools with
+explicit "if unavailable" fallbacks. Stage 2 (Analyze) does manual
+reasoning informed by Stage 1 results. Every member works in every
+project regardless of available tooling.
 
 ## Boundaries
 What you do NOT examine. Which other cabinet members own it.
@@ -254,6 +257,10 @@ What you do NOT examine. Which other cabinet members own it.
 ## Calibration Examples
 Plain-text observations (not JSON) showing the kind of things
 this cabinet member notices.
+
+## Historically Problematic Patterns
+Two-file overlay: upstream section (CC-owned, universal) +
+`patterns-project.md` (project-owned, never overwritten on upgrade).
 ```
 
 ## Common Failure Modes

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

@@ -9,6 +9,10 @@ user-invocable: false
 briefing:
   - _briefing-identity.md
   - _briefing-jurisdictions.md
+tools:
+  - axe-core (web projects -- via preview_eval CDN injection)
+  - preview_snapshot (web projects -- accessibility tree inspection)
+  - preview_inspect (web projects -- computed style contrast ratios)
 activation:
   standing-mandate: audit
   files:
@@ -50,7 +54,12 @@ screen readers, or other assistive technology.
 - Color contrast concerns
 - Always active during audit runs
 
-## Research Method
+## Investigation Protocol
+
+**Two stages: measure first, then reason.** Run automated tools to establish
+a baseline before manual testing. Every tool is optional — if preview tools
+aren't available (non-web project, no dev server), use the code-reading
+fallback. The member produces useful findings either way.
 
 ### Knowledge Sources
 
@@ -62,79 +71,132 @@ Use WebSearch to check current WCAG 2.2 guidelines when evaluating
 specific criteria. Search `site:w3.org/WAI` for authoritative guidance.
 Don't guess about compliance levels — verify.
 
-### Testing Approach
+### Stage 1: Instrument
+
+Run automated accessibility checks if preview tools are available.
+
+**1a. axe-core automated scan**
 
-Use preview tools to actually test accessibility:
+Start the dev server with `preview_start`, then inject axe-core via
+`preview_eval`:
 
-**Keyboard Navigation:**
-1. Start the dev server with `preview_start`
-2. Use `preview_eval` to simulate keyboard-only navigation:
-   ```javascript
-   document.activeElement.tagName  // what has focus?
-   ```
-3. Use `preview_snapshot` to check focus state and element structure
-4. Trace tab order through every page — can you reach everything?
+```javascript
+// Load axe-core from CDN and run full scan
+const script = document.createElement('script');
+script.src = 'https://cdnjs.cloudflare.com/ajax/libs/axe-core/4.10.2/axe.min.js';
+script.onload = () => {
+  axe.run().then(results => {
+    console.log('axe-core violations:', results.violations.length);
+    results.violations.forEach(v => {
+      console.log(`[${v.impact}] ${v.id}: ${v.description} (${v.nodes.length} instances)`);
+      console.log(`  WCAG: ${v.tags.filter(t => t.startsWith('wcag')).join(', ')}`);
+    });
+    console.log('axe-core passes:', results.passes.length);
+  });
+};
+document.head.appendChild(script);
+```
 
-**Screen Reader Simulation:**
-Use `preview_snapshot` (accessibility tree) to evaluate what a screen
-reader would announce:
+Parse violations by impact level (critical, serious, moderate, minor).
+axe-core catches ~57% of WCAG violations automatically — use this as
+a baseline, not a complete assessment.
+
+**1b. Accessibility tree inspection**
+
+Use `preview_snapshot` to capture the accessibility tree. Check:
 - Do all interactive elements have accessible names?
-- Do images have alt text?
-- Are form fields properly labeled?
-- Is the heading hierarchy logical (h1 -> h2 -> h3, no skips)?
-- Are live regions used for dynamic content updates?
+- Is the heading hierarchy logical (h1 → h2 → h3, no skips)?
+- Are form fields associated with labels?
+- Are landmarks (`main`, `nav`, `aside`) present?
+
+**1c. Contrast measurement**
+
+Use `preview_inspect` with computed styles to check contrast ratios on
+key elements (headings, body text, interactive controls, placeholder text).
+
+### Stage 1 fallback (no preview tools)
+
+If this is a non-web project or preview tools aren't available, scan
+source code directly:
+
+```bash
+# Find interactive elements missing aria-label
+grep -rn --include='*.tsx' --include='*.jsx' \
+  '<button\|<Button\|<IconButton' src/ | grep -v 'aria-label'
+
+# Find images missing alt text
+grep -rn --include='*.tsx' --include='*.jsx' \
+  '<img\|<Image' src/ | grep -v 'alt='
+
+# Find heading hierarchy (check for skips)
+grep -rn --include='*.tsx' --include='*.jsx' \
+  '<h[1-6]\|<Title\|<Heading' src/
 
-### What to Evaluate
+# Check for role="button" on non-button elements (a11y smell)
+grep -rn --include='*.tsx' --include='*.jsx' \
+  'role="button"' src/
+```
 
-**1. Keyboard Navigation**
+### Stage 1 results
+
+Summarize before proceeding:
+- N axe-core violations (N critical, N serious) — or "axe-core not available"
+- Accessibility tree: N elements without accessible names
+- Contrast: N elements below WCAG AA thresholds
+- Missing alt text: N images
+
+### Stage 2: Analyze
+
+Interpret Stage 1 results + manual evaluation for what automation misses.
+
+**2a. Keyboard Navigation** (SC 2.1.1, SC 2.1.2, SC 2.4.3, SC 2.4.7)
 - **Tab order** — Is it logical? Does it follow visual layout?
 - **Focus indicators** — Can you always see what's focused? Are custom
   focus styles visible against the dark theme?
 - **Keyboard shortcuts** — Are they documented? Do they conflict with
-  browser/OS shortcuts? Can they be discovered?
+  browser/OS shortcuts? Can they be discovered? (SC 2.1.4)
 - **Focus traps** — Do modals and drawers trap focus correctly? Can you
-  escape them with Esc?
-- **Skip links** — Can keyboard users skip repetitive navigation?
+  escape them with Esc? (SC 2.1.2)
+- **Skip links** — Can keyboard users skip repetitive navigation? (SC 2.4.1)
 
-**2. Semantic Structure**
+**2b. Semantic Structure** (SC 1.3.1, SC 2.4.6, SC 2.4.10)
 - **Headings** — Is there a logical heading hierarchy on each page?
 - **Landmarks** — Are `<main>`, `<nav>`, `<aside>` used appropriately?
 - **Lists** — Are lists of items marked up as `<ul>`/`<ol>`, not just
   styled divs?
 - **Tables** — Do data tables have proper headers (`<th>` with scope)?
-- **Forms** — Are all inputs associated with labels?
+- **Forms** — Are all inputs associated with labels? (SC 1.3.1)
 
-**3. Color and Contrast**
+**2c. Color and Contrast** (SC 1.4.3, SC 1.4.6, SC 1.4.11)
 - **Text contrast** — Does all text meet WCAG AA minimum (4.5:1 for
   normal text, 3:1 for large text)? Check against the dark theme AND
-  any light theme option.
+  any light theme option. (SC 1.4.3)
+- **Non-text contrast** — Do UI components and graphical objects have at
+  least 3:1 contrast? (SC 1.4.11)
 - **Color as sole indicator** — Is color ever the only way to convey
-  information? (e.g., red for errors without an icon or text)
+  information? (SC 1.4.1)
 - **Focus contrast** — Are focus indicators visible against all
-  backgrounds?
-- Use `preview_inspect` with computed styles to check specific contrast
-  ratios.
+  backgrounds? (SC 2.4.7)
 
-**4. Interactive Elements**
-- **Button labels** — Do icon-only buttons have `aria-label`?
-- **Link purpose** — Can link text be understood out of context?
+**2d. Interactive Elements** (SC 4.1.2, SC 1.3.1, SC 3.3.1, SC 3.3.2)
+- **Button labels** — Do icon-only buttons have `aria-label`? (SC 4.1.2)
+- **Link purpose** — Can link text be understood out of context? (SC 2.4.4)
 - **Error messages** — Are form errors associated with their fields
-  via `aria-describedby`?
+  via `aria-describedby`? (SC 3.3.1)
 - **Loading states** — Are loading indicators announced to screen
-  readers? (`aria-live`, `aria-busy`)
+  readers? (`aria-live`, `aria-busy`) (SC 4.1.3)
 - **Notifications** — Are toast notifications in an `aria-live` region?
 
-**5. Dynamic Content**
-- **Content updates** — When content changes (task completed, item
-  processed), is the change communicated to assistive technology?
-- **Drag and drop** — Is there a keyboard alternative for drag-and-drop
-  reordering?
-- **Modals and drawers** — Do they manage focus correctly? (Focus moves
-  in on open, returns to trigger on close)
-- **Tabs** — Do tab panels follow WAI-ARIA tab pattern? Arrow keys to
-  switch tabs, tab key to enter panel content?
-
-**6. Motion and Animation**
+**2e. Dynamic Content** (SC 4.1.3, SC 2.1.1, SC 2.4.3)
+- **Content updates** — When content changes, is the change communicated
+  to assistive technology? (SC 4.1.3)
+- **Drag and drop** — Is there a keyboard alternative? (SC 2.1.1)
+- **Modals and drawers** — Focus moves in on open, returns to trigger
+  on close? (SC 2.4.3)
+- **Tabs** — Follow WAI-ARIA tab pattern? Arrow keys to switch, tab key
+  to enter panel content?
+
+**2f. Motion and Animation** (SC 2.3.1, SC 2.3.3)
 - **Reduced motion** — Does the app respect `prefers-reduced-motion`?
 - **Auto-playing animation** — Is any content animated automatically
   without user control?
@@ -178,3 +240,24 @@ Adding aria-label to each would fix it with no behavior change.
 **Not a finding:** A component uses a slightly different shade of blue
 than the theme default. This is a visual preference, not an accessibility
 concern, unless the contrast ratio falls below WCAG AA thresholds.
+
+## Historically Problematic Patterns
+
+Two sources — read both and merge at runtime:
+
+1. **This section** (upstream, CC-owned) — universal patterns that apply to
+   any project. Grows when consuming projects promote recurring findings
+   via field-feedback.
+2. **`patterns-project.md`** in this skill's directory — project-specific
+   patterns discovered during audits of this particular project. Project-
+   owned, never overwritten by CC upgrades.
+
+If `patterns-project.md` exists, read it alongside this section. Both
+inform your analysis equally.
+
+**How patterns get here:** A consuming project's audit finds a real issue.
+If the same pattern recurs across projects, it gets promoted upstream via
+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 -->

package/templates/skills/cabinet-anti-confirmation/SKILL.md

@@ -20,6 +20,7 @@ topics:
   - high stakes
   - redesign
   - strategy
+tools: []
 ---
 
 # Anti-Confirmation
@@ -170,3 +171,24 @@ should be revisited if categories are added more than twice per quarter."
 
 The plan still ships the same way. But the decision was *examined*, the
 alternatives were *recorded*, and the trigger for revisiting is *explicit*.
+
+## Historically Problematic Patterns
+
+Two sources — read both and merge at runtime:
+
+1. **This section** (upstream, CC-owned) — universal patterns that apply to
+   any project. Grows when consuming projects promote recurring findings
+   via field-feedback.
+2. **`patterns-project.md`** in this skill's directory — project-specific
+   patterns discovered during audits of this particular project. Project-
+   owned, never overwritten by CC upgrades.
+
+If `patterns-project.md` exists, read it alongside this section. Both
+inform your analysis equally.
+
+**How patterns get here:** A consuming project's audit finds a real issue.
+If the same pattern recurs across projects, it gets promoted upstream via
+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 -->

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

@@ -12,6 +12,9 @@ briefing:
   - _briefing-architecture.md
   - _briefing-jurisdictions.md
 standing-mandate: audit, plan, investigate
+tools:
+  - fetch_docs (all projects -- Claude Code llms.txt and capability pages)
+  - WebSearch (all projects -- ecosystem monitoring)
 directives:
   plan: >
     Evaluate structural fit. Does this plan compose well with existing
@@ -285,3 +288,24 @@ This cabinet member has the broadest scope -- the whole system:
 - Three npm packages provide overlapping functionality (e.g., two HTTP
   clients, two date libraries). This is a build-vs-buy debt pattern --
   the team adopted new tools without removing old ones.
+
+## Historically Problematic Patterns
+
+Two sources — read both and merge at runtime:
+
+1. **This section** (upstream, CC-owned) — universal patterns that apply to
+   any project. Grows when consuming projects promote recurring findings
+   via field-feedback.
+2. **`patterns-project.md`** in this skill's directory — project-specific
+   patterns discovered during audits of this particular project. Project-
+   owned, never overwritten by CC upgrades.
+
+If `patterns-project.md` exists, read it alongside this section. Both
+inform your analysis equally.
+
+**How patterns get here:** A consuming project's audit finds a real issue.
+If the same pattern recurs across projects, it gets promoted upstream via
+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 -->