create-claude-cabinet 0.29.9 → 0.29.10
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/templates/cabinet/_cabinet-member-template.md +3 -3
- package/templates/cabinet/composition-patterns.md +1 -1
- package/templates/cabinet/output-contract.md +1 -1
- package/templates/cabinet/prompt-guide.md +1 -1
- package/templates/cabinet/skill-best-practices.md +1 -1
- package/templates/site-audit-runtime/package.json +1 -1
- package/templates/site-audit-runtime/src/checks/nuclei.mjs +5 -2
- package/templates/site-audit-runtime/src/checks/unlighthouse.mjs +1 -1
- package/templates/site-audit-runtime/src/orchestrator.mjs +1 -1
- package/templates/skills/cabinet-accessibility/SKILL.md +4 -4
- package/templates/skills/cabinet-anthropic-insider/SKILL.md +4 -4
- package/templates/skills/cabinet-anti-confirmation/SKILL.md +3 -3
- package/templates/skills/cabinet-architecture/SKILL.md +6 -6
- package/templates/skills/cabinet-automation/SKILL.md +5 -5
- package/templates/skills/cabinet-boundary-man/SKILL.md +3 -3
- package/templates/skills/cabinet-cc-health/SKILL.md +10 -10
- package/templates/skills/cabinet-cc-health/calibration.md +2 -2
- package/templates/skills/cabinet-data-integrity/SKILL.md +15 -15
- package/templates/skills/cabinet-debugger/SKILL.md +3 -3
- package/templates/skills/cabinet-framework-quality/SKILL.md +5 -5
- package/templates/skills/cabinet-goal-alignment/SKILL.md +5 -5
- package/templates/skills/cabinet-historian/SKILL.md +2 -2
- package/templates/skills/cabinet-information-design/SKILL.md +5 -5
- package/templates/skills/cabinet-interactive-storyteller/SKILL.md +2 -2
- package/templates/skills/cabinet-mantine-quality/SKILL.md +5 -5
- package/templates/skills/cabinet-narrative-architect/SKILL.md +2 -2
- package/templates/skills/cabinet-organized-mind/SKILL.md +2 -2
- package/templates/skills/cabinet-process-therapist/SKILL.md +12 -12
- package/templates/skills/cabinet-qa/SKILL.md +3 -3
- package/templates/skills/cabinet-record-keeper/SKILL.md +9 -9
- package/templates/skills/cabinet-roster-check/SKILL.md +2 -2
- package/templates/skills/cabinet-security/SKILL.md +13 -13
- package/templates/skills/cabinet-small-screen/SKILL.md +2 -2
- package/templates/skills/cabinet-speed-freak/SKILL.md +4 -4
- package/templates/skills/cabinet-system-advocate/SKILL.md +3 -3
- package/templates/skills/cabinet-technical-debt/SKILL.md +2 -2
- package/templates/skills/cabinet-ui-experimentalist/SKILL.md +5 -5
- package/templates/skills/cabinet-usability/SKILL.md +4 -4
- package/templates/skills/cabinet-user-advocate/SKILL.md +6 -6
- package/templates/skills/cabinet-vision/SKILL.md +6 -6
- package/templates/skills/cabinet-workflow-cop/SKILL.md +12 -12
- package/templates/skills/cc-site-audit/SKILL.md +23 -6
- package/templates/skills/execute/SKILL.md +2 -2
- package/templates/skills/onboard/phases/generate-briefing.md +7 -0
- package/templates/skills/orient/SKILL.md +21 -0
- package/templates/skills/plan/SKILL.md +1 -1
- package/templates/skills/plan/phases/cabinet-critique.md +1 -1
package/package.json
CHANGED
|
@@ -22,9 +22,9 @@ description: >
|
|
|
22
22
|
analyst who...", "Data coherence analyst who...").
|
|
23
23
|
user-invocable: false
|
|
24
24
|
briefing:
|
|
25
|
-
- _briefing-identity.md
|
|
25
|
+
- .claude/cabinet/_briefing-identity.md
|
|
26
26
|
# Add other briefing files relevant to this member's domain
|
|
27
|
-
# Common: _briefing-architecture.md, _briefing-jurisdictions.md, _briefing-api.md
|
|
27
|
+
# Common: .claude/cabinet/_briefing-architecture.md, _briefing-jurisdictions.md, _briefing-api.md
|
|
28
28
|
standing-mandate: audit
|
|
29
29
|
# Add plan, execute, orient, debrief if this member should activate
|
|
30
30
|
# in those contexts. Most members are audit-only.
|
|
@@ -106,7 +106,7 @@ relevant standards by number where applicable (OWASP, WCAG, etc.).
|
|
|
106
106
|
|
|
107
107
|
### 4. Scan Scope
|
|
108
108
|
|
|
109
|
-
What files and directories to examine. Reference
|
|
109
|
+
What files and directories to examine. Reference `.claude/cabinet/_briefing.md` for
|
|
110
110
|
project-specific paths. Use comments to tell consuming projects where
|
|
111
111
|
to customize.
|
|
112
112
|
|
|
@@ -26,7 +26,7 @@ presents them to the user as a tension to resolve, not a bug. The
|
|
|
26
26
|
synthesis should name both cabinet members and their reasoning.
|
|
27
27
|
|
|
28
28
|
**Implementation:** Use the Agent tool with multiple agents in a
|
|
29
|
-
single message. Each agent receives: shared briefing (
|
|
29
|
+
single message. Each agent receives: shared briefing (`.claude/cabinet/_briefing.md`) +
|
|
30
30
|
cabinet member SKILL.md + output contract + input data.
|
|
31
31
|
|
|
32
32
|
---
|
|
@@ -55,7 +55,7 @@ but calibrate the severity honestly.
|
|
|
55
55
|
### Severity Calibration
|
|
56
56
|
|
|
57
57
|
Calibrate severity to actual risk in your project's context, not to
|
|
58
|
-
generic compliance frameworks. Read
|
|
58
|
+
generic compliance frameworks. Read `.claude/cabinet/_briefing.md` for the project's
|
|
59
59
|
priorities and risk profile.
|
|
60
60
|
|
|
61
61
|
<!-- Customize these anchors for your project. The examples below
|
|
@@ -86,7 +86,7 @@ shallow ones. Depth of research matters more than breadth.
|
|
|
86
86
|
|
|
87
87
|
### 10. Know Your Cabinet
|
|
88
88
|
Each cabinet member should be aware of what the others cover. The
|
|
89
|
-
shared briefing (
|
|
89
|
+
shared briefing (`.claude/cabinet/_briefing.md`) lists the full cabinet with committees.
|
|
90
90
|
Individual prompts should reference specific neighbors in "Boundaries."
|
|
91
91
|
|
|
92
92
|
## Cognitive Architecture Principles
|
|
@@ -117,7 +117,7 @@ it's reading has faded. Keep related content one link away from the
|
|
|
117
117
|
entry point.
|
|
118
118
|
|
|
119
119
|
Links to files outside the skill's directory (e.g.,
|
|
120
|
-
`templates/cabinet/skill-best-practices.md`,
|
|
120
|
+
`templates/cabinet/skill-best-practices.md`, `.claude/cabinet/_briefing.md`) don't
|
|
121
121
|
count — those are shared references available at any depth.
|
|
122
122
|
|
|
123
123
|
### Reference files over 100 lines have a TOC
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@claude-cabinet/site-audit",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.8",
|
|
4
4
|
"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.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -16,8 +16,11 @@ export async function detect(executor) {
|
|
|
16
16
|
|
|
17
17
|
export async function run(url, executor, opts = {}) {
|
|
18
18
|
const hostname = new URL(url).hostname;
|
|
19
|
-
|
|
20
|
-
|
|
19
|
+
const authorized = Array.isArray(opts.authorizedDomains)
|
|
20
|
+
? opts.authorizedDomains
|
|
21
|
+
: (opts.authorizedDomain ? [opts.authorizedDomain] : []);
|
|
22
|
+
if (!authorized.includes(hostname)) {
|
|
23
|
+
return { __skipped: true, reason: `active scan not authorized for ${hostname}` };
|
|
21
24
|
}
|
|
22
25
|
|
|
23
26
|
const r = await executor.spawn('nuclei', [
|
|
@@ -8,7 +8,7 @@ import { join } from 'node:path';
|
|
|
8
8
|
export const checkId = 'unlighthouse';
|
|
9
9
|
export const tool = 'Unlighthouse (full-site crawl)';
|
|
10
10
|
export const whyItMatters = "Runs Lighthouse on every page of your site, not just the homepage — catches performance and accessibility problems hiding on inner pages.";
|
|
11
|
-
export const defaultTimeoutMs =
|
|
11
|
+
export const defaultTimeoutMs = 900_000;
|
|
12
12
|
|
|
13
13
|
export async function detect(executor) {
|
|
14
14
|
const r = await executor.spawn('unlighthouse', ['--version'], { timeoutMs: 15_000 });
|
|
@@ -7,8 +7,8 @@ description: >
|
|
|
7
7
|
structure gaps. Activates during audits and when reviewing UI component code.
|
|
8
8
|
user-invocable: false
|
|
9
9
|
briefing:
|
|
10
|
-
- _briefing-identity.md
|
|
11
|
-
- _briefing-jurisdictions.md
|
|
10
|
+
- .claude/cabinet/_briefing-identity.md
|
|
11
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
12
12
|
tools:
|
|
13
13
|
- axe-core (web projects -- via preview_eval CDN injection)
|
|
14
14
|
- preview_snapshot (web projects -- accessibility tree inspection)
|
|
@@ -16,7 +16,7 @@ tools:
|
|
|
16
16
|
activation:
|
|
17
17
|
standing-mandate: audit
|
|
18
18
|
files:
|
|
19
|
-
# Adjust to your component paths. See _briefing.md § Scan Scopes — App Source
|
|
19
|
+
# Adjust to your component paths. See .claude/cabinet/_briefing.md § Scan Scopes — App Source
|
|
20
20
|
- src/**/*.tsx
|
|
21
21
|
- src/components/**/*.tsx
|
|
22
22
|
topics:
|
|
@@ -203,7 +203,7 @@ Interpret Stage 1 results + manual evaluation for what automation misses.
|
|
|
203
203
|
|
|
204
204
|
### Scan Scope
|
|
205
205
|
|
|
206
|
-
<!-- Adjust these paths to your project. See _briefing.md § Scan Scopes — App Source -->
|
|
206
|
+
<!-- Adjust these paths to your project. See .claude/cabinet/_briefing.md § Scan Scopes — App Source -->
|
|
207
207
|
- Live app (via preview_start) — primary testing artifact
|
|
208
208
|
- `src/components/` — All components
|
|
209
209
|
- `src/pages/` — All pages
|
|
@@ -9,8 +9,8 @@ description: >
|
|
|
9
9
|
platform alignment and surface ecosystem developments worth adopting.
|
|
10
10
|
user-invocable: false
|
|
11
11
|
briefing:
|
|
12
|
-
- _briefing-identity.md
|
|
13
|
-
- _briefing-architecture.md
|
|
12
|
+
- .claude/cabinet/_briefing-identity.md
|
|
13
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
14
14
|
standing-mandate: audit, plan, orient, seed
|
|
15
15
|
tools:
|
|
16
16
|
- 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
|
|
|
45
45
|
they exist, and stays aligned with ecosystem conventions so it doesn't break
|
|
46
46
|
on updates or miss new capabilities.
|
|
47
47
|
|
|
48
|
-
Read
|
|
48
|
+
Read `.claude/cabinet/_briefing.md` for the project's architecture and stack. Understand what
|
|
49
49
|
the project builds on top of Claude Code before evaluating it.
|
|
50
50
|
|
|
51
51
|
You bring three kinds of expertise:
|
|
@@ -270,7 +270,7 @@ prompt hooks can/cannot Z" is verification.
|
|
|
270
270
|
- `hooks/` — hook configurations
|
|
271
271
|
- `.lsp.json` — LSP server configurations
|
|
272
272
|
- `CLAUDE.md`, `**/CLAUDE.md` — memory and context files
|
|
273
|
-
-
|
|
273
|
+
- `.claude/cabinet/_briefing*.md` — project briefing files
|
|
274
274
|
- Claude Code docs (via framework-docs MCP) — authoritative reference
|
|
275
275
|
- `changelog.md` / `whats-new/` (via docs) — release tracking
|
|
276
276
|
|
|
@@ -12,7 +12,7 @@ description: >
|
|
|
12
12
|
user-invocable: false
|
|
13
13
|
memory: project
|
|
14
14
|
briefing:
|
|
15
|
-
- _briefing-identity.md
|
|
15
|
+
- .claude/cabinet/_briefing-identity.md
|
|
16
16
|
topics:
|
|
17
17
|
- decision
|
|
18
18
|
- tradeoff
|
|
@@ -28,7 +28,7 @@ tools: []
|
|
|
28
28
|
|
|
29
29
|
# Anti-Confirmation
|
|
30
30
|
|
|
31
|
-
See
|
|
31
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
32
32
|
|
|
33
33
|
## Identity
|
|
34
34
|
|
|
@@ -59,7 +59,7 @@ Your value is lowest when:
|
|
|
59
59
|
### The Portfolio Exception
|
|
60
60
|
|
|
61
61
|
You are the ONE cabinet member exempted from the strict portfolio rule documented
|
|
62
|
-
in
|
|
62
|
+
in `.claude/cabinet/_briefing.md`. Every other cabinet member stays in its portfolio. You
|
|
63
63
|
intentionally cross portfolios — because reasoning quality touches every
|
|
64
64
|
domain. However, when you surface a domain-specific concern, you **flag
|
|
65
65
|
it for the relevant cabinet member** rather than developing the argument
|
|
@@ -10,9 +10,9 @@ description: >
|
|
|
10
10
|
infrastructure leverage.
|
|
11
11
|
user-invocable: false
|
|
12
12
|
briefing:
|
|
13
|
-
- _briefing-identity.md
|
|
14
|
-
- _briefing-architecture.md
|
|
15
|
-
- _briefing-jurisdictions.md
|
|
13
|
+
- .claude/cabinet/_briefing-identity.md
|
|
14
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
15
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
16
16
|
standing-mandate: audit, plan, investigate
|
|
17
17
|
tools:
|
|
18
18
|
- 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
|
|
|
37
37
|
make sense, and whether the Claude Code / markdown OS setup is being
|
|
38
38
|
leveraged to its full potential.
|
|
39
39
|
|
|
40
|
-
Read
|
|
40
|
+
Read `.claude/cabinet/_briefing.md` for the project's architecture, stack, and design
|
|
41
41
|
principles. Understand the system before evaluating it.
|
|
42
42
|
|
|
43
43
|
You bring two kinds of expertise:
|
|
@@ -80,7 +80,7 @@ capabilities that would strengthen the architecture.
|
|
|
80
80
|
|
|
81
81
|
#### Layer 2: Project Design Vision
|
|
82
82
|
|
|
83
|
-
Read
|
|
83
|
+
Read `.claude/cabinet/_briefing.md` for the project's design principles, architectural
|
|
84
84
|
decisions, and inspirations. Every project has deliberate choices --
|
|
85
85
|
understand them before critiquing them. Check system status or equivalent
|
|
86
86
|
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:
|
|
|
254
254
|
- `.claude/skills/` -- Skill definitions
|
|
255
255
|
- `.claude/settings*.json` -- Claude Code configuration
|
|
256
256
|
- `.mcp.json` -- MCP server configuration
|
|
257
|
-
-
|
|
257
|
+
- `.claude/cabinet/_briefing.md` -- Project context (if present)
|
|
258
258
|
- Server/API entry points -- Express, FastAPI, etc.
|
|
259
259
|
- Frontend app structure -- React, Vue, etc.
|
|
260
260
|
- Schema/model definitions
|
|
@@ -10,8 +10,8 @@ description: >
|
|
|
10
10
|
and scheduled-task robustness.
|
|
11
11
|
user-invocable: false
|
|
12
12
|
briefing:
|
|
13
|
-
- _briefing-identity.md
|
|
14
|
-
- _briefing-architecture.md
|
|
13
|
+
- .claude/cabinet/_briefing-identity.md
|
|
14
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
15
15
|
standing-mandate: audit, plan, execute
|
|
16
16
|
tools:
|
|
17
17
|
- 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
|
|
|
45
45
|
automation is built to survive this reality or whether it's one upstream
|
|
46
46
|
change away from silent failure.
|
|
47
47
|
|
|
48
|
-
Read
|
|
48
|
+
Read `.claude/cabinet/_briefing.md` for the project's architecture and what it automates.
|
|
49
49
|
|
|
50
50
|
Your expertise spans four domains:
|
|
51
51
|
|
|
@@ -103,7 +103,7 @@ The threat model is **fragility and silent failure**, not security:
|
|
|
103
103
|
|
|
104
104
|
## Investigation Protocol
|
|
105
105
|
|
|
106
|
-
See
|
|
106
|
+
See `.claude/cabinet/_briefing.md` for shared codebase context and principles.
|
|
107
107
|
|
|
108
108
|
**Two stages: measure first, then reason.** Run automated checks to
|
|
109
109
|
establish a baseline, then manual review for what automation misses.
|
|
@@ -379,7 +379,7 @@ or elaborate stealth against an unprotected target (wasted complexity).
|
|
|
379
379
|
- State files and persistence layer
|
|
380
380
|
- Retry/error handling utilities
|
|
381
381
|
- Dockerfile and deployment config
|
|
382
|
-
- See
|
|
382
|
+
- See `.claude/cabinet/_briefing.md` for project-specific paths
|
|
383
383
|
|
|
384
384
|
## Portfolio Boundaries
|
|
385
385
|
|
|
@@ -10,9 +10,9 @@ description: >
|
|
|
10
10
|
exclusions in implementations.
|
|
11
11
|
user-invocable: false
|
|
12
12
|
briefing:
|
|
13
|
-
- _briefing-identity.md
|
|
14
|
-
- _briefing-architecture.md
|
|
15
|
-
- _briefing-jurisdictions.md
|
|
13
|
+
- .claude/cabinet/_briefing-identity.md
|
|
14
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
15
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
16
16
|
standing-mandate: execute
|
|
17
17
|
tools: []
|
|
18
18
|
directives:
|
|
@@ -9,9 +9,9 @@ description: |
|
|
|
9
9
|
health.
|
|
10
10
|
user-invocable: false
|
|
11
11
|
briefing:
|
|
12
|
-
- _briefing-identity.md
|
|
13
|
-
- _briefing-cabinet.md
|
|
14
|
-
- _briefing-jurisdictions.md
|
|
12
|
+
- .claude/cabinet/_briefing-identity.md
|
|
13
|
+
- .claude/cabinet/_briefing-cabinet.md
|
|
14
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
15
15
|
standing-mandate: audit
|
|
16
16
|
tools:
|
|
17
17
|
- grep/file scanning (all projects -- config validation)
|
|
@@ -47,7 +47,7 @@ related:
|
|
|
47
47
|
|
|
48
48
|
# CC Health
|
|
49
49
|
|
|
50
|
-
See
|
|
50
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
51
51
|
|
|
52
52
|
## Identity
|
|
53
53
|
|
|
@@ -219,7 +219,7 @@ consolidation, promotion bottlenecks.
|
|
|
219
219
|
The project evolves. The CC configuration should evolve with it. Check for
|
|
220
220
|
drift between the two:
|
|
221
221
|
|
|
222
|
-
-
|
|
222
|
+
- **`.claude/cabinet/_briefing.md` freshness.** Compare the briefing files against the
|
|
223
223
|
actual project state. Do NOT trust what the briefing says — verify it
|
|
224
224
|
against the filesystem. Concrete cross-references to make:
|
|
225
225
|
- `.ccrc.json` modules vs briefing claims about what's installed.
|
|
@@ -237,7 +237,7 @@ drift between the two:
|
|
|
237
237
|
section references. New directories that aren't mentioned? Referenced
|
|
238
238
|
paths that no longer exist?
|
|
239
239
|
- Split vs monolithic briefing: if the project has enough content for
|
|
240
|
-
split files but is still using a monolithic
|
|
240
|
+
split files but is still using a monolithic `.claude/cabinet/_briefing.md`, flag it.
|
|
241
241
|
Stale context means cabinet members are making decisions based on
|
|
242
242
|
outdated information.
|
|
243
243
|
- **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
|
|
|
286
286
|
perspectives directory." You need to read each file and understand what
|
|
287
287
|
it's saying.
|
|
288
288
|
|
|
289
|
-
**Method:** Read each non-manifest file (phase files,
|
|
289
|
+
**Method:** Read each non-manifest file (phase files, `.claude/cabinet/_briefing.md`,
|
|
290
290
|
custom skills, memory files, custom cabinet members). For each file,
|
|
291
291
|
assess whether its content assumes the current CC world or the old one.
|
|
292
292
|
You're looking for three categories of staleness:
|
|
293
293
|
|
|
294
294
|
**1. Broken references** — content that points to things that no longer
|
|
295
295
|
exist. A phase file that says "read `perspectives/_context.md`" will
|
|
296
|
-
fail silently because that file is now
|
|
296
|
+
fail silently because that file is now `.claude/cabinet/_briefing.md`. A hook
|
|
297
297
|
reference to `cor-upstream-guard.sh` points to a deleted file. These
|
|
298
298
|
cause real failures — the system tries to do something and can't.
|
|
299
299
|
|
|
300
300
|
To help you recognize these, the v0.5 → v0.6 transition changed:
|
|
301
301
|
- `perspectives/` directory → `cabinet-*/` directories + `briefing/`
|
|
302
|
-
- `_context.md` →
|
|
302
|
+
- `_context.md` → `.claude/cabinet/_briefing.md`
|
|
303
303
|
- `_context-template.md` → `_briefing-template.md`
|
|
304
304
|
- `_groups.yaml` → `committees.yaml`
|
|
305
305
|
- `cor-upstream-guard.sh` → `cc-upstream-guard.sh`
|
|
@@ -361,7 +361,7 @@ directory structure:
|
|
|
361
361
|
**Directory structure:**
|
|
362
362
|
- `cabinet-*/` directories exist for active cabinet members (not
|
|
363
363
|
`perspectives/`)
|
|
364
|
-
- `briefing/` directory exists with
|
|
364
|
+
- `briefing/` directory exists with `.claude/cabinet/_briefing.md` (not `_context.md`
|
|
365
365
|
in `perspectives/`)
|
|
366
366
|
- `cabinet/` directory exists for infrastructure files (committees,
|
|
367
367
|
lifecycle, etc.)
|
|
@@ -16,12 +16,12 @@ over from a template and never removed. Recommend retirement per
|
|
|
16
16
|
`_lifecycle.md` criteria."
|
|
17
17
|
Severity: info. Evidence: triage history + project type mismatch.
|
|
18
18
|
|
|
19
|
-
**Stale context:** "
|
|
19
|
+
**Stale context:** "`.claude/cabinet/_briefing.md` lists Express.js 4.x as the server
|
|
20
20
|
framework, but `package.json` shows the project migrated to Hono three weeks
|
|
21
21
|
ago. Three cabinet members reference Express middleware patterns in their scan
|
|
22
22
|
scopes. These cabinet members are partially blind to the current server
|
|
23
23
|
architecture."
|
|
24
|
-
Severity: warn. Evidence:
|
|
24
|
+
Severity: warn. Evidence: `.claude/cabinet/_briefing.md` content vs `package.json` delta.
|
|
25
25
|
|
|
26
26
|
**Telemetry gap:** "Hook telemetry JSONL hasn't been written to in 12 days,
|
|
27
27
|
but the project had 8 Claude Code sessions in that period (per git log).
|
|
@@ -10,10 +10,10 @@ description: >
|
|
|
10
10
|
consistency.
|
|
11
11
|
user-invocable: false
|
|
12
12
|
briefing:
|
|
13
|
-
- _briefing-identity.md
|
|
14
|
-
- _briefing-architecture.md
|
|
15
|
-
- _briefing-jurisdictions.md
|
|
16
|
-
- _briefing-api.md
|
|
13
|
+
- .claude/cabinet/_briefing-identity.md
|
|
14
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
15
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
16
|
+
- .claude/cabinet/_briefing-api.md
|
|
17
17
|
standing-mandate: audit
|
|
18
18
|
tools:
|
|
19
19
|
- sqlite3 (SQLite projects -- data coherence queries)
|
|
@@ -29,8 +29,8 @@ entities reference each other correctly, whether state transitions make
|
|
|
29
29
|
sense, whether the filesystem and database agree about what exists, and
|
|
30
30
|
whether the API enforces the rules the schema implies.
|
|
31
31
|
|
|
32
|
-
This project's data stores must stay consistent. See
|
|
33
|
-
for the specific stores in use, and
|
|
32
|
+
This project's data stores must stay consistent. See `.claude/cabinet/_briefing.md § Data Store`
|
|
33
|
+
for the specific stores in use, and `.claude/cabinet/_briefing.md § Entity Types` for what
|
|
34
34
|
lives where. Common patterns include:
|
|
35
35
|
|
|
36
36
|
1. **Structured database** (production canonical) -- Actions, projects,
|
|
@@ -46,7 +46,7 @@ integrity risk.
|
|
|
46
46
|
## Convening Criteria
|
|
47
47
|
|
|
48
48
|
- **standing-mandate:** audit
|
|
49
|
-
- **files:** See
|
|
49
|
+
- **files:** See `.claude/cabinet/_briefing.md § API / Server` and `.claude/cabinet/_briefing.md § App Source` for server routes and type definitions
|
|
50
50
|
- **topics:** database, schema, referential integrity, orphan, identity, consistency, migration, API contract
|
|
51
51
|
|
|
52
52
|
## Research Method
|
|
@@ -60,7 +60,7 @@ this prompt was written. Instead:
|
|
|
60
60
|
```bash
|
|
61
61
|
# Get the current DB schema
|
|
62
62
|
# Use the appropriate client for your data store
|
|
63
|
-
# See _briefing.md § Data Store for connection details
|
|
63
|
+
# See .claude/cabinet/_briefing.md § Data Store for connection details
|
|
64
64
|
```
|
|
65
65
|
|
|
66
66
|
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:
|
|
|
92
92
|
can go stale.
|
|
93
93
|
|
|
94
94
|
#### Step 4: Check API Contract Integrity
|
|
95
|
-
Read your API server (see
|
|
95
|
+
Read your API server (see `.claude/cabinet/_briefing.md § API / Server`) and check:
|
|
96
96
|
|
|
97
97
|
- **Validation** -- Do API endpoints validate input before writing to the
|
|
98
98
|
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:
|
|
|
101
101
|
records cleaned up? (e.g., deleting a project -- what happens to its
|
|
102
102
|
actions and comments?)
|
|
103
103
|
- **Response contracts** -- Do API responses match what the frontend's
|
|
104
|
-
type definitions expect? (Check types in
|
|
104
|
+
type definitions expect? (Check types in `.claude/cabinet/_briefing.md § App Source`
|
|
105
105
|
against actual API responses)
|
|
106
106
|
|
|
107
107
|
#### Step 5: Check Identity Integrity
|
|
@@ -113,7 +113,7 @@ or similar), verify:
|
|
|
113
113
|
- Comments or references pointing to IDs that no longer exist in any file
|
|
114
114
|
- Identity format consistency -- are all IDs using the correct patterns?
|
|
115
115
|
|
|
116
|
-
The specific identity scheme is project-dependent -- see
|
|
116
|
+
The specific identity scheme is project-dependent -- see `.claude/cabinet/_briefing.md § Entity
|
|
117
117
|
Types` for what your project uses.
|
|
118
118
|
|
|
119
119
|
#### Step 6: Check Composite Entity Integrity
|
|
@@ -128,10 +128,10 @@ have internal consistency requirements:
|
|
|
128
128
|
|
|
129
129
|
### Scan Scope
|
|
130
130
|
|
|
131
|
-
- See
|
|
132
|
-
- See
|
|
133
|
-
- See
|
|
134
|
-
- See
|
|
131
|
+
- See `.claude/cabinet/_briefing.md § Data Store` -- Database (discover schema first, then query)
|
|
132
|
+
- See `.claude/cabinet/_briefing.md § API / Server` -- API endpoints (validation, consistency)
|
|
133
|
+
- See `.claude/cabinet/_briefing.md § App Source` -- Type definitions (API contracts)
|
|
134
|
+
- See `.claude/cabinet/_briefing.md § Entity Types` -- All entity directories and files
|
|
135
135
|
- Configuration files -- Entity type definitions, metadata files
|
|
136
136
|
|
|
137
137
|
## Portfolio Boundaries
|
|
@@ -9,8 +9,8 @@ description: >
|
|
|
9
9
|
prerequisites before running anything.
|
|
10
10
|
user-invocable: false
|
|
11
11
|
briefing:
|
|
12
|
-
- _briefing-identity.md
|
|
13
|
-
- _briefing-architecture.md
|
|
12
|
+
- .claude/cabinet/_briefing-identity.md
|
|
13
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
14
14
|
standing-mandate: execute
|
|
15
15
|
tools:
|
|
16
16
|
- npm ls (Node projects -- dependency chain)
|
|
@@ -175,7 +175,7 @@ reasoning: "Summary"
|
|
|
175
175
|
|
|
176
176
|
### For `audit` context (findings)
|
|
177
177
|
|
|
178
|
-
Standard audit findings format per
|
|
178
|
+
Standard audit findings format per `.claude/cabinet/_briefing.md`.
|
|
179
179
|
|
|
180
180
|
## Calibration Examples
|
|
181
181
|
|
|
@@ -12,8 +12,8 @@ description: >
|
|
|
12
12
|
from its UI framework.
|
|
13
13
|
user-invocable: false
|
|
14
14
|
briefing:
|
|
15
|
-
- _briefing-architecture.md
|
|
16
|
-
- _briefing-jurisdictions.md
|
|
15
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
16
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
17
17
|
standing-mandate: audit
|
|
18
18
|
tools:
|
|
19
19
|
- grep (all projects -- import scanning, component inventory)
|
|
@@ -23,7 +23,7 @@ tools:
|
|
|
23
23
|
|
|
24
24
|
# Framework Quality
|
|
25
25
|
|
|
26
|
-
See
|
|
26
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
27
27
|
|
|
28
28
|
## Identity
|
|
29
29
|
|
|
@@ -62,7 +62,7 @@ cabinet member exists.
|
|
|
62
62
|
|
|
63
63
|
### How You Discover the Framework
|
|
64
64
|
|
|
65
|
-
Read
|
|
65
|
+
Read `.claude/cabinet/_briefing.md` to learn what UI framework the project uses. Then:
|
|
66
66
|
|
|
67
67
|
1. **Fetch framework documentation** — many frameworks ship LLM-optimized
|
|
68
68
|
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:
|
|
|
339
339
|
|
|
340
340
|
### Scan Scope
|
|
341
341
|
|
|
342
|
-
Read
|
|
342
|
+
Read `.claude/cabinet/_briefing.md` for the project's file structure and paths. Focus on:
|
|
343
343
|
- Framework reference documents
|
|
344
344
|
- Component directories
|
|
345
345
|
- Page/view files
|
|
@@ -12,8 +12,8 @@ description: >
|
|
|
12
12
|
user-invocable: false
|
|
13
13
|
memory: project
|
|
14
14
|
briefing:
|
|
15
|
-
- _briefing-identity.md
|
|
16
|
-
- _briefing-jurisdictions.md
|
|
15
|
+
- .claude/cabinet/_briefing-identity.md
|
|
16
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
17
17
|
standing-mandate: audit
|
|
18
18
|
tools: []
|
|
19
19
|
topics:
|
|
@@ -31,7 +31,7 @@ topics:
|
|
|
31
31
|
|
|
32
32
|
# Goal Alignment
|
|
33
33
|
|
|
34
|
-
See
|
|
34
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
35
35
|
|
|
36
36
|
## Identity
|
|
37
37
|
|
|
@@ -83,7 +83,7 @@ serves the mission.
|
|
|
83
83
|
|
|
84
84
|
### The Mission
|
|
85
85
|
|
|
86
|
-
Read
|
|
86
|
+
Read `.claude/cabinet/_briefing-identity.md` to understand what this project is meant to
|
|
87
87
|
be — its stated purpose, core principles, and user context. Then read
|
|
88
88
|
`system-status.md` (or equivalent state file) for what's built and
|
|
89
89
|
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:
|
|
|
191
191
|
|
|
192
192
|
### Scan Scope
|
|
193
193
|
|
|
194
|
-
Read
|
|
194
|
+
Read `.claude/cabinet/_briefing-jurisdictions.md` for project-specific paths. Focus on:
|
|
195
195
|
- Project identity files (CLAUDE.md, README, mission statements)
|
|
196
196
|
- Status and roadmap files
|
|
197
197
|
- Feedback and friction capture directories
|
|
@@ -11,8 +11,8 @@ description: >
|
|
|
11
11
|
user-invocable: false
|
|
12
12
|
memory: user
|
|
13
13
|
briefing:
|
|
14
|
-
- _briefing-identity.md
|
|
15
|
-
- _briefing-architecture.md
|
|
14
|
+
- .claude/cabinet/_briefing-identity.md
|
|
15
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
16
16
|
standing-mandate: plan, execute, orient, debrief
|
|
17
17
|
tools:
|
|
18
18
|
- grep over ~/.claude/projects/<slug>/memory/ (built-in memory retrieval)
|
|
@@ -13,9 +13,9 @@ description: >
|
|
|
13
13
|
and visual hierarchy.
|
|
14
14
|
user-invocable: false
|
|
15
15
|
briefing:
|
|
16
|
-
- _briefing-identity.md
|
|
17
|
-
- _briefing-architecture.md
|
|
18
|
-
- _briefing-jurisdictions.md
|
|
16
|
+
- .claude/cabinet/_briefing-identity.md
|
|
17
|
+
- .claude/cabinet/_briefing-architecture.md
|
|
18
|
+
- .claude/cabinet/_briefing-jurisdictions.md
|
|
19
19
|
tools: []
|
|
20
20
|
topics:
|
|
21
21
|
- layout
|
|
@@ -34,7 +34,7 @@ topics:
|
|
|
34
34
|
|
|
35
35
|
# Information Design
|
|
36
36
|
|
|
37
|
-
See
|
|
37
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
38
38
|
|
|
39
39
|
## Identity
|
|
40
40
|
|
|
@@ -314,7 +314,7 @@ usability critiques its interaction model.
|
|
|
314
314
|
### Before Designing
|
|
315
315
|
|
|
316
316
|
1. **Read the project's architecture** — understand the technology
|
|
317
|
-
stack, framework, and theming system from
|
|
317
|
+
stack, framework, and theming system from `.claude/cabinet/_briefing-architecture.md`
|
|
318
318
|
2. **Read framework documentation** — know what components exist before
|
|
319
319
|
designing with them. Don't propose custom components when the
|
|
320
320
|
framework already provides one.
|
|
@@ -14,7 +14,7 @@ description: >
|
|
|
14
14
|
interactive artifacts.
|
|
15
15
|
user-invocable: false
|
|
16
16
|
briefing:
|
|
17
|
-
- _briefing-identity.md
|
|
17
|
+
- .claude/cabinet/_briefing-identity.md
|
|
18
18
|
tools: [WebSearch (research emerging interactive narrative patterns)]
|
|
19
19
|
topics:
|
|
20
20
|
- interactive
|
|
@@ -34,7 +34,7 @@ topics:
|
|
|
34
34
|
|
|
35
35
|
# Interactive Storyteller
|
|
36
36
|
|
|
37
|
-
See
|
|
37
|
+
See `.claude/cabinet/_briefing.md` for shared cabinet member context.
|
|
38
38
|
|
|
39
39
|
## Identity
|
|
40
40
|
|