create-claude-cabinet 0.6.0

package/templates/skills/triage-audit/phases/load-findings.md

@@ -0,0 +1,38 @@
+# Load Findings — Where to Get Findings for Triage
+
+Define where the triage skill loads audit findings from. The /triage-audit
+skill reads this file before presenting findings.
+
+When this file is absent or empty, the default behavior is: query pib-db
+for findings with `triage_status = 'open'`, fall back to the most recent
+`reviews/*/run-summary.json`. To explicitly skip, write only `skip: true`.
+
+## What to Include
+
+Define your finding source:
+- **Primary source** — where findings live (database, API, filesystem)
+- **Fallback** — what to do if the primary source is unavailable
+- **Filtering** — which findings to include (all open, specific run, etc.)
+
+## Example Override
+
+Uncomment and adapt if your project stores findings elsewhere:
+
+<!--
+### External API
+```bash
+curl -s https://your-api.example.com/api/audit/findings?status=open \
+  -H "Authorization: Bearer $API_TOKEN"
+```
+Returns JSON array of findings in the same format as run-summary.json.
+
+### Specific Run
+Load findings from a specific audit run instead of all open findings:
+```bash
+node scripts/pib-db.js query "SELECT * FROM audit_findings WHERE run_id = 'run-2026-04-01'"
+```
+
+### Multiple Sources
+Merge findings from pib-db (local) and an external API (team findings)
+before presenting for triage.
+-->

package/templates/skills/triage-audit/phases/triage-ui.md

@@ -0,0 +1,66 @@
+# Triage UI — How to Present Findings
+
+Define how findings are presented for human triage judgment. The
+/triage-audit skill reads this file after loading findings.
+
+When this file is absent or empty, the default behavior is: start the
+local triage server, POST findings with commentary, tell the user to
+open the browser UI. Fallback: present in conversation. To explicitly
+skip UI presentation, write only `skip: true`.
+
+## What to Include
+
+Define your triage interface:
+- **Primary UI** — how findings are presented (browser, CLI, external tool)
+- **Commentary** — how Claude's assessment is included with each finding
+- **Fallback** — what to do if the primary UI isn't available
+
+## Default Behavior
+
+1. **Prepare commentary** for each finding:
+   - Your assessment of severity and importance
+   - Suggested fix approach and estimated effort
+   - Relationship to other findings (shared root cause?)
+   - Relationship to open work (already being addressed?)
+
+2. **Start triage server:**
+   ```bash
+   node scripts/triage-server.mjs --port 3847
+   ```
+
+3. **POST findings** to `http://localhost:3847/api/findings` with
+   commentary attached to each finding
+
+4. **Tell user** to open `http://localhost:3847` in their browser
+
+5. **Wait for verdicts** — poll `GET /api/verdicts` until the user
+   submits their decisions
+
+## Important
+
+Never summarize away findings. Every item must be visible with full
+context: title, description, assumption, evidence, question, and
+commentary. The user needs the complete picture to make good triage
+decisions. Abbreviated or summarized findings lead to uninformed
+verdicts.
+
+## Example Override
+
+Uncomment and adapt for your project:
+
+<!--
+### CLI-Only Triage
+Present findings in the conversation, grouped by cabinet member.
+For each group, show findings severity-ordered and ask for verdicts.
+Useful when browser access isn't available.
+
+### External Triage Tool
+POST findings to an external triage dashboard:
+```bash
+curl -X POST https://your-app.example.com/api/triage/session \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $API_TOKEN" \
+  -d @findings-with-commentary.json
+```
+Tell user to open the external dashboard URL.
+-->

package/templates/skills/unlink/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: unlink
+description: |
+  Remove local development linking for Claude Cabinet. Returns the
+  project to using the published npm version. Use when: "unlink",
+  "stop using local CoR", "use published version", "/unlink".
+---
+
+# /unlink — Remove Local Development Link
+
+## Purpose
+
+Disconnect from a local Claude Cabinet checkout and return to using
+the published npm version.
+
+## Context Detection
+
+**CoR source repo** (`package.json` has `name: "create-claude-cabinet"`):
+- Run `npm unlink` to remove the global registration
+- Warn: "This will break the link for all consuming projects that depend
+  on it. They'll need to `npm unlink create-claude-cabinet` too, or
+  they'll get resolution errors."
+
+**Any other project**:
+- Run `npm unlink create-claude-cabinet`
+- The project returns to using the published npm version
+- Tell the user: "Unlinked. `npx create-claude-cabinet` will now pull
+  from npm instead of your local checkout."
+
+## When to Use
+
+- Before testing against the published npm version
+- When done with a local development cycle
+- When the local CoR checkout is moving to a branch you don't want
+  consuming projects to track

package/templates/skills/validate/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: validate
+description: |
+  Run structural validation checks and present a unified summary. The
+  orchestration pattern is generic; the specific validators are project-defined
+  in phases/validators.md. Use when: "validate", "run checks", "/validate",
+  or after any structural changes.
+related:
+  - type: file
+    path: .claude/skills/validate/phases/validators.md
+    role: "Project-specific validator definitions"
+  - type: file
+    path: cabinet/_briefing.md
+    role: "Scan scopes for validation targets"
+---
+
+# /validate — Run All Validation Checks
+
+## Purpose
+
+Run every configured validator and report results in a unified summary.
+Zero errors is the standard.
+
+This is a **skeleton skill** using the `phases/` directory pattern. The
+orchestration (run → collect → report) is generic. Your project defines
+which validators to run in `phases/validators.md`.
+
+### Phase File Protocol
+
+Phase files have three states:
+
+| State | Meaning |
+|-------|---------|
+| Absent or empty | Use this skeleton's **default behavior** for the phase |
+| Contains only `skip: true` | **Explicitly opted out** — skip this phase entirely |
+| Contains content | **Custom behavior** — use the file's content instead |
+
+## Workflow
+
+### 1. Read Validators
+
+Read `phases/validators.md` for the list of project-specific checks.
+Each validator has a name, command, and description of what it catches.
+
+If `phases/validators.md` is empty or missing, report that no validators
+are configured and suggest the user define some.
+
+### 2. Run Each Validator
+
+Execute each validator command in sequence. For each:
+- Run the command
+- Capture stdout/stderr and exit code
+- Record pass (exit 0) or fail (non-zero) with output
+
+If a validator fails, continue running the rest — don't stop at the
+first failure. The point is a complete picture.
+
+### 3. Report
+
+Present a unified summary:
+
+```
+## Validation Results
+
+| Check | Status | Details |
+|-------|--------|---------|
+| {name} | PASS/FAIL | {error count or "clean"} |
+| ... | ... | ... |
+
+### Errors
+{For each failed check, list the specific errors}
+```
+
+If errors found:
+- For quick fixes (obvious typo, missing tag): propose the fix
+- For complex issues: suggest creating a plan via /plan
+- Never silently skip errors
+
+### 4. Terminal State
+
+- All pass → ready to commit and deploy
+- Any fail → fix errors and re-validate
+
+## Extending
+
+To add a new validator:
+1. Add an entry to `phases/validators.md`
+2. Ensure the script/command exists and returns exit 0 on success
+3. Run `/validate` to confirm it works
+
+To skip a validator temporarily: comment it out in `phases/validators.md`.
+
+To add a phase the skeleton doesn't define: create a new file in `phases/`
+(e.g., `phases/pre-validate.md` for setup steps). Claude reads whatever
+phase files exist at runtime.
+
+## Calibration
+
+**Core failure this targets:** Committing or deploying code that has
+structural problems (broken references, type errors, lint violations)
+because checks weren't run or results weren't reviewed.
+
+### Without Skill (Bad)
+
+Developer makes changes across several files, commits, and deploys.
+The deploy fails because of a type error that local checking would have
+caught. Or worse: the deploy succeeds but a broken cross-reference
+causes a runtime error that isn't discovered for days.
+
+### With Skill (Good)
+
+Developer runs `/validate` after changes. The unified summary shows
+one type error and one structural issue. Both are fixed before commit.
+The deploy succeeds cleanly. The structural issue would have caused a
+subtle bug that wouldn't have surfaced until a user hit a specific
+code path.

package/templates/skills/validate/phases/validators.md

@@ -0,0 +1,53 @@
+# Validators
+
+Define your project-specific validation checks here. Each validator is
+a named check with a command to run. The /validate skill reads this file
+and executes each check in sequence.
+
+## Format
+
+For each validator, provide:
+- **Name** — short label for the summary table
+- **Command** — shell command that returns exit 0 on success, non-zero on failure
+- **What it catches** — brief description of what this validator detects
+
+## Example Validators
+
+Uncomment and adapt these for your project:
+
+<!--
+### Type Check
+```bash
+cd your-app-dir && npx tsc --noEmit
+```
+Catches type errors before they reach production.
+
+### Lint
+```bash
+cd your-app-dir && npx eslint src/
+```
+Catches style violations and common code quality issues.
+
+### Production Build
+```bash
+cd your-app-dir && npx vite build
+```
+Catches what the type checker misses: bare catch blocks, runtime-only
+errors, bundle resolution failures. A type check pass + build fail =
+broken deploy.
+
+### Structural Validation
+```bash
+./scripts/validate-structure.sh
+```
+Project-specific structural checks (e.g., required files exist, cross-references
+are valid, configuration is consistent). Write these scripts for your
+project's invariants.
+
+### Memory/Docs Validation
+```bash
+./scripts/validate-docs.sh
+```
+Checks that documentation references (memory index, CLAUDE.md links) point
+to files that actually exist.
+-->