create-claude-cabinet 0.29.9 → 0.29.11

package/package.json

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

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

@@ -22,9 +22,9 @@ description: >
   analyst who...", "Data coherence analyst who...").
 user-invocable: false
 briefing:
-  - _briefing-identity.md
+  - .claude/cabinet/_briefing-identity.md
   # Add other briefing files relevant to this member's domain
-  # Common: _briefing-architecture.md, _briefing-jurisdictions.md, _briefing-api.md
+  # Common: .claude/cabinet/_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.
@@ -106,7 +106,7 @@ relevant standards by number where applicable (OWASP, WCAG, etc.).
 
 ### 4. Scan Scope
 
-What files and directories to examine. Reference `_briefing.md` for
+What files and directories to examine. Reference `.claude/cabinet/_briefing.md` for
 project-specific paths. Use comments to tell consuming projects where
 to customize.
 

package/templates/cabinet/composition-patterns.md

@@ -26,7 +26,7 @@ presents them to the user as a tension to resolve, not a bug. The
 synthesis should name both cabinet members and their reasoning.
 
 **Implementation:** Use the Agent tool with multiple agents in a
-single message. Each agent receives: shared briefing (`_briefing.md`) +
+single message. Each agent receives: shared briefing (`.claude/cabinet/_briefing.md`) +
 cabinet member SKILL.md + output contract + input data.
 
 ---

package/templates/cabinet/output-contract.md

@@ -55,7 +55,7 @@ but calibrate the severity honestly.
 ### Severity Calibration
 
 Calibrate severity to actual risk in your project's context, not to
-generic compliance frameworks. Read `_briefing.md` for the project's
+generic compliance frameworks. Read `.claude/cabinet/_briefing.md` for the project's
 priorities and risk profile.
 
 <!-- Customize these anchors for your project. The examples below

package/templates/cabinet/prompt-guide.md

@@ -86,7 +86,7 @@ shallow ones. Depth of research matters more than breadth.
 
 ### 10. Know Your Cabinet
 Each cabinet member should be aware of what the others cover. The
-shared briefing (`_briefing.md`) lists the full cabinet with committees.
+shared briefing (`.claude/cabinet/_briefing.md`) lists the full cabinet with committees.
 Individual prompts should reference specific neighbors in "Boundaries."
 
 ## Cognitive Architecture Principles

package/templates/cabinet/skill-best-practices.md

@@ -117,7 +117,7 @@ it's reading has faded. Keep related content one link away from the
 entry point.
 
 Links to files outside the skill's directory (e.g.,
-`templates/cabinet/skill-best-practices.md`, `_briefing.md`) don't
+`templates/cabinet/skill-best-practices.md`, `.claude/cabinet/_briefing.md`) don't
 count — those are shared references available at any depth.
 
 ### Reference files over 100 lines have a TOC

package/templates/site-audit-runtime/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@claude-cabinet/site-audit",
-  "version": "0.1.7",
+  "version": "0.1.9",
   "description": "Comprehensive deployed-site quality audit engine for Claude Cabinet. Runs checks across performance, accessibility, security, SEO, content, DNS, and privacy against a deployed URL; single-site and comparison modes; standalone HTML report.",
   "type": "module",
   "bin": {

package/templates/site-audit-runtime/src/checks/nuclei.mjs

@@ -10,14 +10,21 @@ export const whyItMatters = "Scans for known security vulnerabilities (CVEs) tha
 export const defaultTimeoutMs = 300_000;
 
 export async function detect(executor) {
-  const r = await executor.spawn('nuclei', ['-version'], { timeoutMs: 10_000 });
-  return r.code === 0 || r.stderr?.includes('nuclei');
+  try {
+    const r = await executor.spawn('nuclei', ['-version'], { timeoutMs: 10_000 });
+    return r.code === 0;
+  } catch {
+    return false;
+  }
 }
 
 export async function run(url, executor, opts = {}) {
   const hostname = new URL(url).hostname;
-  if (!opts.authorizedDomain || opts.authorizedDomain !== hostname) {
-    return { __skipped: true, reason: `active scan not authorized for ${hostname} (pass --i-authorize-active-scan=${hostname})` };
+  const authorized = Array.isArray(opts.authorizedDomains)
+    ? opts.authorizedDomains
+    : (opts.authorizedDomain ? [opts.authorizedDomain] : []);
+  if (!authorized.includes(hostname)) {
+    return { __skipped: true, reason: `active scan not authorized for ${hostname}` };
   }
 
   const r = await executor.spawn('nuclei', [

package/templates/site-audit-runtime/src/checks/unlighthouse.mjs

@@ -8,7 +8,7 @@ import { join } from 'node:path';
 export const checkId = 'unlighthouse';
 export const tool = 'Unlighthouse (full-site crawl)';
 export const whyItMatters = "Runs Lighthouse on every page of your site, not just the homepage — catches performance and accessibility problems hiding on inner pages.";
-export const defaultTimeoutMs = 600_000;
+export const defaultTimeoutMs = 900_000;
 
 export async function detect(executor) {
   const r = await executor.spawn('unlighthouse', ['--version'], { timeoutMs: 15_000 });

package/templates/site-audit-runtime/src/orchestrator.mjs

@@ -54,7 +54,7 @@ const DEFAULT_TIMEOUTS = {
   lighthouse: 120_000,
   testssl: 180_000,
   nuclei: 300_000,
-  unlighthouse: 600_000,
+  unlighthouse: 900_000,
 };
 const FALLBACK_TIMEOUT = 60_000;
 const MAX_CONCURRENCY = 4;

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

@@ -7,8 +7,8 @@ description: >
   structure gaps. Activates during audits and when reviewing UI component code.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 tools:
   - axe-core (web projects -- via preview_eval CDN injection)
   - preview_snapshot (web projects -- accessibility tree inspection)
@@ -16,7 +16,7 @@ tools:
 activation:
   standing-mandate: audit
   files:
-    # Adjust to your component paths. See _briefing.md § Scan Scopes — App Source
+    # Adjust to your component paths. See .claude/cabinet/_briefing.md § Scan Scopes — App Source
     - src/**/*.tsx
     - src/components/**/*.tsx
   topics:
@@ -203,7 +203,7 @@ Interpret Stage 1 results + manual evaluation for what automation misses.
 
 ### Scan Scope
 
-<!-- Adjust these paths to your project. See _briefing.md § Scan Scopes — App Source -->
+<!-- Adjust these paths to your project. See .claude/cabinet/_briefing.md § Scan Scopes — App Source -->
 - Live app (via preview_start) — primary testing artifact
 - `src/components/` — All components
 - `src/pages/` — All pages

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

@@ -9,8 +9,8 @@ description: >
   platform alignment and surface ecosystem developments worth adopting.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
 standing-mandate: audit, plan, orient, seed
 tools:
   - fetch_docs (all projects -- Claude Code llms.txt index and capability pages)
@@ -45,7 +45,7 @@ gets maximum value from the platform it runs on, uses official patterns where
 they exist, and stays aligned with ecosystem conventions so it doesn't break
 on updates or miss new capabilities.
 
-Read `_briefing.md` for the project's architecture and stack. Understand what
+Read `.claude/cabinet/_briefing.md` for the project's architecture and stack. Understand what
 the project builds on top of Claude Code before evaluating it.
 
 You bring three kinds of expertise:
@@ -270,7 +270,7 @@ prompt hooks can/cannot Z" is verification.
 - `hooks/` — hook configurations
 - `.lsp.json` — LSP server configurations
 - `CLAUDE.md`, `**/CLAUDE.md` — memory and context files
-- `_briefing*.md` — project briefing files
+- `.claude/cabinet/_briefing*.md` — project briefing files
 - Claude Code docs (via framework-docs MCP) — authoritative reference
 - `changelog.md` / `whats-new/` (via docs) — release tracking
 

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

@@ -12,7 +12,7 @@ description: >
 user-invocable: false
 memory: project
 briefing:
-  - _briefing-identity.md
+  - .claude/cabinet/_briefing-identity.md
 topics:
   - decision
   - tradeoff
@@ -28,7 +28,7 @@ tools: []
 
 # Anti-Confirmation
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity
 
@@ -59,7 +59,7 @@ Your value is lowest when:
 ### The Portfolio Exception
 
 You are the ONE cabinet member exempted from the strict portfolio rule documented
-in `_briefing.md`. Every other cabinet member stays in its portfolio. You
+in `.claude/cabinet/_briefing.md`. Every other cabinet member stays in its portfolio. You
 intentionally cross portfolios — because reasoning quality touches every
 domain. However, when you surface a domain-specific concern, you **flag
 it for the relevant cabinet member** rather than developing the argument

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

@@ -10,9 +10,9 @@ description: >
   infrastructure leverage.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: audit, plan, investigate
 tools:
   - fetch_docs (all projects -- Claude Code llms.txt and capability pages)
@@ -37,7 +37,7 @@ layers interact, where boundaries are clean or leaking, whether data flows
 make sense, and whether the Claude Code / markdown OS setup is being
 leveraged to its full potential.
 
-Read `_briefing.md` for the project's architecture, stack, and design
+Read `.claude/cabinet/_briefing.md` for the project's architecture, stack, and design
 principles. Understand the system before evaluating it.
 
 You bring two kinds of expertise:
@@ -80,7 +80,7 @@ capabilities that would strengthen the architecture.
 
 #### Layer 2: Project Design Vision
 
-Read `_briefing.md` for the project's design principles, architectural
+Read `.claude/cabinet/_briefing.md` for the project's design principles, architectural
 decisions, and inspirations. Every project has deliberate choices --
 understand them before critiquing them. Check system status or equivalent
 tracking for what's built vs planned. Don't evaluate the system against
@@ -254,7 +254,7 @@ This cabinet member has the broadest scope -- the whole system:
 - `.claude/skills/` -- Skill definitions
 - `.claude/settings*.json` -- Claude Code configuration
 - `.mcp.json` -- MCP server configuration
-- `_briefing.md` -- Project context (if present)
+- `.claude/cabinet/_briefing.md` -- Project context (if present)
 - Server/API entry points -- Express, FastAPI, etc.
 - Frontend app structure -- React, Vue, etc.
 - Schema/model definitions

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

@@ -10,8 +10,8 @@ description: >
   and scheduled-task robustness.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
 standing-mandate: audit, plan, execute
 tools:
   - Playwright MCP (browser automation -- microsoft/playwright-mcp, the standard)
@@ -45,7 +45,7 @@ and deprecate APIs without notice. Your job is to evaluate whether the
 automation is built to survive this reality or whether it's one upstream
 change away from silent failure.
 
-Read `_briefing.md` for the project's architecture and what it automates.
+Read `.claude/cabinet/_briefing.md` for the project's architecture and what it automates.
 
 Your expertise spans four domains:
 
@@ -103,7 +103,7 @@ The threat model is **fragility and silent failure**, not security:
 
 ## Investigation Protocol
 
-See `_briefing.md` for shared codebase context and principles.
+See `.claude/cabinet/_briefing.md` for shared codebase context and principles.
 
 **Two stages: measure first, then reason.** Run automated checks to
 establish a baseline, then manual review for what automation misses.
@@ -379,7 +379,7 @@ or elaborate stealth against an unprotected target (wasted complexity).
 - State files and persistence layer
 - Retry/error handling utilities
 - Dockerfile and deployment config
-- See `_briefing.md` for project-specific paths
+- See `.claude/cabinet/_briefing.md` for project-specific paths
 
 ## Portfolio Boundaries
 

package/templates/skills/cabinet-boundary-man/SKILL.md

@@ -10,9 +10,9 @@ description: >
   exclusions in implementations.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: execute
 tools: []
 directives:

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

@@ -9,9 +9,9 @@ description: |
   health.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-cabinet.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-cabinet.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: audit
 tools:
   - grep/file scanning (all projects -- config validation)
@@ -47,7 +47,7 @@ related:
 
 # CC Health
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity
 
@@ -219,7 +219,7 @@ consolidation, promotion bottlenecks.
 The project evolves. The CC configuration should evolve with it. Check for
 drift between the two:
 
-- **`_briefing.md` freshness.** Compare the briefing files against the
+- **`.claude/cabinet/_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.
@@ -237,7 +237,7 @@ drift between the two:
     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.
+    split files but is still using a monolithic `.claude/cabinet/_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
@@ -286,20 +286,20 @@ catches the literal string but misses "the shared context file in the
 perspectives directory." You need to read each file and understand what
 it's saying.
 
-**Method:** Read each non-manifest file (phase files, `_briefing.md`,
+**Method:** Read each non-manifest file (phase files, `.claude/cabinet/_briefing.md`,
 custom skills, memory files, custom cabinet members). For each file,
 assess whether its content assumes the current CC world or the old one.
 You're looking for three categories of staleness:
 
 **1. Broken references** — content that points to things that no longer
 exist. A phase file that says "read `perspectives/_context.md`" will
-fail silently because that file is now `briefing/_briefing.md`. A hook
+fail silently because that file is now `.claude/cabinet/_briefing.md`. A hook
 reference to `cor-upstream-guard.sh` points to a deleted file. These
 cause real failures — the system tries to do something and can't.
 
 To help you recognize these, the v0.5 → v0.6 transition changed:
 - `perspectives/` directory → `cabinet-*/` directories + `briefing/`
-- `_context.md` → `_briefing.md`
+- `_context.md` → `.claude/cabinet/_briefing.md`
 - `_context-template.md` → `_briefing-template.md`
 - `_groups.yaml` → `committees.yaml`
 - `cor-upstream-guard.sh` → `cc-upstream-guard.sh`
@@ -361,7 +361,7 @@ directory structure:
 **Directory structure:**
 - `cabinet-*/` directories exist for active cabinet members (not
   `perspectives/`)
-- `briefing/` directory exists with `_briefing.md` (not `_context.md`
+- `briefing/` directory exists with `.claude/cabinet/_briefing.md` (not `_context.md`
   in `perspectives/`)
 - `cabinet/` directory exists for infrastructure files (committees,
   lifecycle, etc.)

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

@@ -16,12 +16,12 @@ over from a template and never removed. Recommend retirement per
 `_lifecycle.md` criteria."
 Severity: info. Evidence: triage history + project type mismatch.
 
-**Stale context:** "`_briefing.md` lists Express.js 4.x as the server
+**Stale context:** "`.claude/cabinet/_briefing.md` lists Express.js 4.x as the server
 framework, but `package.json` shows the project migrated to Hono three weeks
 ago. Three cabinet members reference Express middleware patterns in their scan
 scopes. These cabinet members are partially blind to the current server
 architecture."
-Severity: warn. Evidence: `_briefing.md` content vs `package.json` delta.
+Severity: warn. Evidence: `.claude/cabinet/_briefing.md` content vs `package.json` delta.
 
 **Telemetry gap:** "Hook telemetry JSONL hasn't been written to in 12 days,
 but the project had 8 Claude Code sessions in that period (per git log).

package/templates/skills/cabinet-data-integrity/SKILL.md

@@ -10,10 +10,10 @@ description: >
   consistency.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
-  - _briefing-jurisdictions.md
-  - _briefing-api.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
+  - .claude/cabinet/_briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-api.md
 standing-mandate: audit
 tools:
   - sqlite3 (SQLite projects -- data coherence queries)
@@ -29,8 +29,8 @@ entities reference each other correctly, whether state transitions make
 sense, whether the filesystem and database agree about what exists, and
 whether the API enforces the rules the schema implies.
 
-This project's data stores must stay consistent. See `_briefing.md § Data Store`
-for the specific stores in use, and `_briefing.md § Entity Types` for what
+This project's data stores must stay consistent. See `.claude/cabinet/_briefing.md § Data Store`
+for the specific stores in use, and `.claude/cabinet/_briefing.md § Entity Types` for what
 lives where. Common patterns include:
 
 1. **Structured database** (production canonical) -- Actions, projects,
@@ -46,7 +46,7 @@ integrity risk.
 ## Convening Criteria
 
 - **standing-mandate:** audit
-- **files:** See `_briefing.md § API / Server` and `_briefing.md § App Source` for server routes and type definitions
+- **files:** See `.claude/cabinet/_briefing.md § API / Server` and `.claude/cabinet/_briefing.md § App Source` for server routes and type definitions
 - **topics:** database, schema, referential integrity, orphan, identity, consistency, migration, API contract
 
 ## Research Method
@@ -60,7 +60,7 @@ this prompt was written. Instead:
 ```bash
 # Get the current DB schema
 # Use the appropriate client for your data store
-# See _briefing.md § Data Store for connection details
+# See .claude/cabinet/_briefing.md § Data Store for connection details
 ```
 
 Read the output. Understand what tables exist, what columns they have,
@@ -92,7 +92,7 @@ This is where a multi-store architecture creates unique risks:
   can go stale.
 
 #### Step 4: Check API Contract Integrity
-Read your API server (see `_briefing.md § API / Server`) and check:
+Read your API server (see `.claude/cabinet/_briefing.md § API / Server`) and check:
 
 - **Validation** -- Do API endpoints validate input before writing to the
   DB? Can the API create an action with an invalid area, a comment on a
@@ -101,7 +101,7 @@ Read your API server (see `_briefing.md § API / Server`) and check:
   records cleaned up? (e.g., deleting a project -- what happens to its
   actions and comments?)
 - **Response contracts** -- Do API responses match what the frontend's
-  type definitions expect? (Check types in `_briefing.md § App Source`
+  type definitions expect? (Check types in `.claude/cabinet/_briefing.md § App Source`
   against actual API responses)
 
 #### Step 5: Check Identity Integrity
@@ -113,7 +113,7 @@ or similar), verify:
 - Comments or references pointing to IDs that no longer exist in any file
 - Identity format consistency -- are all IDs using the correct patterns?
 
-The specific identity scheme is project-dependent -- see `_briefing.md § Entity
+The specific identity scheme is project-dependent -- see `.claude/cabinet/_briefing.md § Entity
 Types` for what your project uses.
 
 #### Step 6: Check Composite Entity Integrity
@@ -128,10 +128,10 @@ have internal consistency requirements:
 
 ### Scan Scope
 
-- See `_briefing.md § Data Store` -- Database (discover schema first, then query)
-- See `_briefing.md § API / Server` -- API endpoints (validation, consistency)
-- See `_briefing.md § App Source` -- Type definitions (API contracts)
-- See `_briefing.md § Entity Types` -- All entity directories and files
+- See `.claude/cabinet/_briefing.md § Data Store` -- Database (discover schema first, then query)
+- See `.claude/cabinet/_briefing.md § API / Server` -- API endpoints (validation, consistency)
+- See `.claude/cabinet/_briefing.md § App Source` -- Type definitions (API contracts)
+- See `.claude/cabinet/_briefing.md § Entity Types` -- All entity directories and files
 - Configuration files -- Entity type definitions, metadata files
 
 ## Portfolio Boundaries

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

@@ -9,8 +9,8 @@ description: >
   prerequisites before running anything.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
 standing-mandate: execute
 tools:
   - npm ls (Node projects -- dependency chain)
@@ -175,7 +175,7 @@ reasoning: "Summary"
 
 ### For `audit` context (findings)
 
-Standard audit findings format per `_briefing.md`.
+Standard audit findings format per `.claude/cabinet/_briefing.md`.
 
 ## Calibration Examples
 

package/templates/skills/cabinet-framework-quality/SKILL.md

@@ -12,8 +12,8 @@ description: >
   from its UI framework.
 user-invocable: false
 briefing:
-  - _briefing-architecture.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-architecture.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: audit
 tools:
   - grep (all projects -- import scanning, component inventory)
@@ -23,7 +23,7 @@ tools:
 
 # Framework Quality
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity
 
@@ -62,7 +62,7 @@ cabinet member exists.
 
 ### How You Discover the Framework
 
-Read `_briefing.md` to learn what UI framework the project uses. Then:
+Read `.claude/cabinet/_briefing.md` to learn what UI framework the project uses. Then:
 
 1. **Fetch framework documentation** — many frameworks ship LLM-optimized
    docs (llms.txt). If an MCP server or documentation source is available,
@@ -339,7 +339,7 @@ third-party packages. Check whether the app is missing opportunities:
 
 ### Scan Scope
 
-Read `_briefing.md` for the project's file structure and paths. Focus on:
+Read `.claude/cabinet/_briefing.md` for the project's file structure and paths. Focus on:
 - Framework reference documents
 - Component directories
 - Page/view files

package/templates/skills/cabinet-goal-alignment/SKILL.md

@@ -12,8 +12,8 @@ description: >
 user-invocable: false
 memory: project
 briefing:
-  - _briefing-identity.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 standing-mandate: audit
 tools: []
 topics:
@@ -31,7 +31,7 @@ topics:
 
 # Goal Alignment
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity
 
@@ -83,7 +83,7 @@ serves the mission.
 
 ### The Mission
 
-Read `_briefing-identity.md` to understand what this project is meant to
+Read `.claude/cabinet/_briefing-identity.md` to understand what this project is meant to
 be — its stated purpose, core principles, and user context. Then read
 `system-status.md` (or equivalent state file) for what's built and
 planned. These two documents define the gap you're evaluating: what the
@@ -191,7 +191,7 @@ Evaluate the health of the project's feedback loops:
 
 ### Scan Scope
 
-Read `_briefing-jurisdictions.md` for project-specific paths. Focus on:
+Read `.claude/cabinet/_briefing-jurisdictions.md` for project-specific paths. Focus on:
 - Project identity files (CLAUDE.md, README, mission statements)
 - Status and roadmap files
 - Feedback and friction capture directories

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

@@ -11,8 +11,8 @@ description: >
 user-invocable: false
 memory: user
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
 standing-mandate: plan, execute, orient, debrief
 tools:
   - grep over ~/.claude/projects/<slug>/memory/ (built-in memory retrieval)

package/templates/skills/cabinet-information-design/SKILL.md

@@ -13,9 +13,9 @@ description: >
   and visual hierarchy.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
-  - _briefing-architecture.md
-  - _briefing-jurisdictions.md
+  - .claude/cabinet/_briefing-identity.md
+  - .claude/cabinet/_briefing-architecture.md
+  - .claude/cabinet/_briefing-jurisdictions.md
 tools: []
 topics:
   - layout
@@ -34,7 +34,7 @@ topics:
 
 # Information Design
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity
 
@@ -314,7 +314,7 @@ usability critiques its interaction model.
 ### Before Designing
 
 1. **Read the project's architecture** — understand the technology
-   stack, framework, and theming system from `_briefing-architecture.md`
+   stack, framework, and theming system from `.claude/cabinet/_briefing-architecture.md`
 2. **Read framework documentation** — know what components exist before
    designing with them. Don't propose custom components when the
    framework already provides one.

package/templates/skills/cabinet-interactive-storyteller/SKILL.md

@@ -14,7 +14,7 @@ description: >
   interactive artifacts.
 user-invocable: false
 briefing:
-  - _briefing-identity.md
+  - .claude/cabinet/_briefing-identity.md
 tools: [WebSearch (research emerging interactive narrative patterns)]
 topics:
   - interactive
@@ -34,7 +34,7 @@ topics:
 
 # Interactive Storyteller
 
-See `_briefing.md` for shared cabinet member context.
+See `.claude/cabinet/_briefing.md` for shared cabinet member context.
 
 ## Identity