create-claude-cabinet 0.6.0

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

@@ -0,0 +1,93 @@
+# Build Cabinet Member — Collaborative Expertise Construction
+
+For each new technology without a matching cabinet member, run a collaborative
+conversation with the user to build project-specific expertise. The /seed
+skill reads this file when there are gaps to fill.
+
+When this file is absent or empty, the default behavior is: co-author
+a cabinet member through structured conversation following the template
+below. To explicitly skip building, write only `skip: true`.
+
+## What to Include
+
+Define your building strategy:
+- **Research steps** — how to gather information about the technology
+  before asking the user
+- **Conversation structure** — what questions to ask, in what order
+- **Output format** — where to create the cabinet member file, what template
+  to follow
+- **Wiring** — how to register the cabinet member in committees and make it
+  discoverable
+
+## Default Build Process
+
+For each gap the user wants to fill:
+
+### Step 1: Research
+
+Before asking the user anything, gather what you can:
+- Read the technology's documentation (use available MCP tools, web search)
+- Check how it's configured in this specific project (read config files,
+  look at usage patterns in the codebase)
+- Identify common pitfalls and best practices for the technology
+- Note what version is in use and any version-specific concerns
+
+This research gives you informed questions to ask rather than generic ones.
+
+### Step 2: Collaborative Conversation
+
+Walk through these areas with the user:
+
+**Identity.** "Who is this expert? What do they care about most?"
+- Draft a one-paragraph identity statement based on your research
+- Ask the user what's missing or wrong about it
+- Refine until it captures the right concerns for this project
+
+**Research Method.** "What should this cabinet member examine?"
+- Propose a scan scope based on where the technology's files live
+- Propose specific things to check (patterns, anti-patterns, config)
+- Ask: "What has bitten you before with this technology?"
+- Ask: "What do you worry about that you don't currently check?"
+
+**Boundaries.** "What does this cabinet member NOT own?"
+- Propose portfolio boundaries to prevent overlap with existing cabinet members
+- Ask: "Is there anything here that another cabinet member already covers?"
+
+**Calibration.** "What does a good finding look like?"
+- Draft 2-3 example findings at different severities
+- Ask the user to adjust the severity anchoring to their project's
+  actual risk profile
+
+### Step 3: Create the Cabinet Member
+
+Write the cabinet member's `SKILL.md` following `_lifecycle.md` guidance:
+- Place in `.claude/skills/cabinet-{name}/SKILL.md`
+- Include all sections: Identity, Convening Criteria, Research Method,
+  Boundaries, Calibration Examples
+- Set `user-invocable: false` in frontmatter (cabinet members are invoked
+  by the audit system, not directly)
+
+### Step 4: Wire It Up
+
+- Add to `committees.yaml` under the appropriate committee (unless it's
+  cross-portfolio, in which case it activates via `standing-mandate` signals)
+- Verify the cabinet member is discoverable by the audit skill
+
+### Emphasis
+
+This is co-authoring, not auto-generating. A generic cabinet member based
+solely on technology documentation catches generic issues. A cabinet member
+built with user input — their specific risks, their past incidents,
+their project's actual patterns — catches what actually matters.
+
+The user's time in this conversation is an investment. It pays off in
+every subsequent audit cycle when the cabinet member catches something
+specific to their project that a generic check would miss.
+
+## Overriding This Phase
+
+Projects override this file when they have a different conversation
+structure, additional template requirements, or non-standard cabinet member
+registration. For example, a project that requires cost-benefit analysis
+before adopting a cabinet member, or one that requires approval from
+multiple stakeholders.

package/templates/skills/seed/phases/evaluate-existing.md

@@ -0,0 +1,61 @@
+# Evaluate Existing — Compare Signals Against Cabinet
+
+For each technology signal detected in the scan phase, check whether a
+matching cabinet member already exists and whether it is current. The /seed
+skill reads this file after scanning to determine what needs building
+versus what needs updating.
+
+When this file is absent or empty, the default behavior is: compare
+each detected signal against `.claude/skills/cabinet-*/` and report
+gaps and staleness. To explicitly skip evaluation, write only `skip: true`.
+
+## What to Include
+
+Define your evaluation strategy:
+- **How to match** — what counts as a cabinet member "covering" a technology
+  (name match, scan scope overlap, domain description)
+- **What "stale" means** — how to detect that a cabinet member exists but
+  hasn't kept up with the technology
+- **What to present** — how to show the user the gap/staleness analysis
+
+## Default Evaluation
+
+For each detected technology signal:
+
+1. **Search for matching cabinet member.** Check each cabinet member's SKILL.md
+   in `.claude/skills/cabinet-*/` for:
+   - Name or description mentioning the technology
+   - Scan scope covering directories where the technology's files live
+   - Domain coverage that would include the technology's concerns
+
+2. **Assess coverage quality.** If a match exists:
+   - Does the cabinet member's scan scope include the right directories?
+     (e.g., a data-integrity cabinet member should cover wherever the DB
+     files and migration scripts live)
+   - Does the cabinet member reference the current technology version or
+     configuration? (e.g., if the project moved from CommonJS to ESM,
+     does the boundary-man cabinet member know?)
+   - Has the cabinet member produced findings in recent audits? (A
+     cabinet member that never fires may have a stale scope)
+
+3. **Classify each signal:**
+   - **Covered** — matching cabinet member exists and is current
+   - **Gap** — no matching cabinet member covers this technology
+   - **Stale** — cabinet member exists but scope, version, or domain
+     description is outdated
+   - **Absorbed** — no dedicated cabinet member, but an existing broader
+     cabinet member covers the concern adequately
+
+4. **Present the analysis** to the user as a table:
+   | Technology | Status | Cabinet Member | Notes |
+   |------------|--------|-------------|-------|
+   Show all four categories. Let the user decide which gaps to fill
+   and which staleness to address. Not every gap needs a cabinet member.
+
+## Overriding This Phase
+
+Projects override this file when they have non-standard cabinet member
+storage, custom matching logic, or additional assessment criteria.
+For example, a project that stores cabinet members in a different location,
+or one that tracks cabinet member health metrics in a database rather
+than relying on file-level inspection.

package/templates/skills/seed/phases/maintain.md

@@ -0,0 +1,92 @@
+# Maintain — Cabinet Health Review
+
+Review existing cabinet members for health: retirement candidates, update
+needs, and coverage gaps. The /seed skill reads this file after building
+new cabinet members (or when no new cabinet members are needed).
+
+When this file is absent or empty, the default behavior is: review the
+full cabinet using the criteria below. To explicitly skip
+maintenance, write only `skip: true`.
+
+## What to Include
+
+Define your maintenance strategy:
+- **Retirement criteria** — what signals that a cabinet member should be removed
+- **Update criteria** — what signals that a cabinet member needs revision
+- **Coverage analysis** — how to detect areas of the codebase that no
+  cabinet member watches
+- **Presentation** — how to show recommendations to the user
+
+## Default Maintenance Review
+
+### Retirement Candidates
+
+Check each cabinet member for retirement signals:
+
+- **Technology removed.** The dependency, config file, or infrastructure
+  that the cabinet member watches is gone from the project. A cabinet member
+  for a framework you no longer use is dead weight.
+
+- **High rejection rate.** If more than half of a cabinet member's audit
+  findings are rejected at triage, it's miscalibrated. Either refine it
+  (adjust scope, update calibration examples) or retire it if the domain
+  isn't worth the maintenance.
+
+- **Stale scan scope.** The directories or files the cabinet member checks
+  no longer exist. The cabinet member runs but examines nothing.
+
+- **Absorbed by another.** A broader cabinet member was created that covers
+  the same concerns. The narrow one is now redundant.
+
+Apply `_lifecycle.md` criteria for formal assessment. Recommend
+retirements as readily as adoptions — a lean cabinet is healthier than
+a comprehensive one with dead weight.
+
+### Update Candidates
+
+Check each cabinet member for update signals:
+
+- **Version drift.** The technology version changed significantly
+  (major version bump, breaking changes). The cabinet member's calibration
+  examples and research method may reference outdated patterns.
+
+- **Scope expansion needed.** New directories were added that fall under
+  the cabinet member's domain but aren't in its scan scope. For example,
+  a security cabinet member that scans `routes/` but the project added an
+  `api/` directory with new endpoints.
+
+- **New features.** The technology added capabilities that the project
+  now uses but the cabinet member doesn't check. For example, SQLite added
+  JSON functions that the project started using — the data-integrity
+  cabinet member should know about JSON type coercion.
+
+### Coverage Gaps
+
+Scan the codebase for areas no cabinet member watches:
+
+- Directories with significant logic that aren't in any cabinet member's
+  scan scope
+- File types that have grown in number but lack a corresponding
+  cabinet member (e.g., many migration files but no migration-safety
+  cabinet member)
+- Patterns that recur across the codebase that no cabinet member checks
+  (e.g., error handling patterns, logging patterns)
+
+### Presentation
+
+Present maintenance recommendations as three lists:
+
+1. **Retire** — cabinet members to remove, with reasoning
+2. **Update** — cabinet members to revise, with specific changes needed
+3. **Gap** — uncovered areas that might warrant new cabinet members
+
+The user decides on each recommendation. Retirement is not failure —
+it's the system staying lean.
+
+## Overriding This Phase
+
+Projects override this file when they have additional maintenance
+criteria (e.g., cost tracking for cabinet members, team assignment
+reviews), different retirement thresholds, or non-standard health
+metrics. For example, a project that tracks cabinet member ROI based on
+bugs caught per audit cycle.

package/templates/skills/seed/phases/scan-signals.md

@@ -0,0 +1,86 @@
+# Scan Signals — Where to Look for Technology Adoption
+
+Define what files and patterns to scan for technology signals, and what
+expertise each signal implies. The /seed skill reads this file first to
+build a picture of the project's technology landscape.
+
+When this file is absent or empty, the default behavior is: scan standard
+locations using the default signal-to-expertise mappings below. To
+explicitly skip signal scanning, write only `skip: true`.
+
+## What to Include
+
+For each signal source, provide:
+- **Where** — the file or glob pattern to check
+- **What** — what to extract (dependency names, config keys, file presence)
+- **Maps to** — what expertise the signal implies
+
+## Default Signal Sources
+
+### Package Manifests
+- `package.json` — `dependencies` and `devDependencies` keys
+- `requirements.txt` / `pyproject.toml` — Python dependencies
+- `Cargo.toml` — Rust dependencies
+- `go.mod` — Go modules
+- `Gemfile` — Ruby dependencies
+
+### Configuration Files
+- `.eslintrc*`, `eslint.config.*` — linting configuration
+- `tailwind.config.*` — utility CSS framework
+- `tsconfig.json` — TypeScript
+- `docker-compose.yml` — container orchestration
+- `.prettierrc*` — code formatting
+- `webpack.config.*`, `vite.config.*` — build tooling
+- `jest.config.*`, `vitest.config.*` — test configuration
+
+### Infrastructure
+- `Dockerfile` — containerization
+- `.github/workflows/` — CI/CD via GitHub Actions
+- `railway.json` / `railway.toml` — Railway deployment
+- `vercel.json` — Vercel deployment
+- `fly.toml` — Fly.io deployment
+- `netlify.toml` — Netlify deployment
+
+### Database
+- `*.db` files — SQLite databases
+- `migrations/` directory — schema migration system
+- `prisma/` directory — Prisma ORM
+- `drizzle.config.*` — Drizzle ORM
+- `knexfile.*` — Knex query builder
+
+## Default Signal-to-Expertise Mappings
+
+| Signal | Suggested Cabinet Member |
+|--------|----------------------|
+| React / Vue / Svelte in deps | usability, accessibility, small-screen |
+| UI framework (Mantine, MUI, Chakra, etc.) | usability, framework-quality (project-specific) |
+| SQLite / PostgreSQL / MySQL | data-integrity |
+| Docker / Railway / Fly.io / Vercel | architecture, security |
+| Express / Fastify / Hono | security, speed-freak |
+| Test framework (jest, vitest, mocha) | qa |
+| TypeScript | boundary-man |
+| CI/CD configs (.github/workflows, etc.) | workflow-cop |
+| Complex architecture (3+ services, monorepo) | architecture |
+| Long-running project (6+ months of git history) | historian |
+| Many skills (5+ in .claude/skills/) | roster-check |
+| Features shipping regularly | system-advocate |
+
+These mappings are starting points, not prescriptions. A project may
+already cover a signal through an existing broader cabinet member (e.g.,
+a "code-quality" cabinet member that subsumes boundary-man). The
+evaluate-existing phase handles that deduplication.
+
+## Overriding This Phase
+
+Projects override this file to add domain-specific signals. Examples:
+
+- A healthcare project adds: HIPAA-related libraries map to a
+  compliance cabinet member
+- A financial project adds: payment processing libraries (Stripe,
+  Square) map to a financial-integrity cabinet member
+- A data pipeline project adds: ETL tools (dbt, Airflow) map to a
+  data-quality cabinet member
+
+Keep the default mappings and add project-specific ones below them.
+The more signals the scan detects, the better the gap analysis in the
+evaluate-existing phase.

package/templates/skills/triage-audit/SKILL.md

@@ -0,0 +1,251 @@
+---
+name: triage-audit
+description: |
+  Audit finding triage. Loads findings, prepares commentary, presents for
+  human judgment via local web UI or CLI, then applies verdicts — updating
+  triage status, attempting auto-fixes, and creating actions for approved
+  findings. The loop-closer: without triage, audit findings accumulate and
+  are never acted on. Use when: "triage", "/triage-audit", after an audit
+  run, or when untriaged findings exist.
+related:
+  - type: file
+    path: .claude/skills/triage-audit/phases/load-findings.md
+    role: "Project-specific: where to load findings from"
+  - type: file
+    path: .claude/skills/triage-audit/phases/triage-ui.md
+    role: "Project-specific: how to present findings for triage"
+  - type: file
+    path: .claude/skills/triage-audit/phases/apply-verdicts.md
+    role: "Project-specific: how to act on triage decisions"
+  - type: file
+    path: scripts/triage-server.mjs
+    role: "Local HTTP server for triage UI"
+  - type: file
+    path: scripts/triage-ui.html
+    role: "Browser-based triage interface"
+  - type: file
+    path: scripts/pib-db.js
+    role: "Reference data layer for finding persistence"
+  - type: file
+    path: cabinet/_briefing.md
+    role: "Project identity and configuration"
+---
+
+# /triage-audit — Audit Finding Triage
+
+## Purpose
+
+Close the audit loop. The audit generates findings; triage presents them
+for human judgment. Without triage, findings accumulate in JSON files
+and are never acted on — or worse, the same findings regenerate every
+audit run because they were never explicitly dismissed.
+
+Triage is where human judgment enters the system. Claude can observe
+patterns and flag concerns, but only the user knows which concerns
+matter for this project at this time. A finding that looks critical in
+isolation might be irrelevant given the project's priorities. A finding
+that looks minor might be the canary for a deeper issue the user
+recognizes. Triage captures that judgment.
+
+This is a **skeleton skill** using the `phases/` directory pattern. The
+orchestration is generic. Your project defines the specifics — where to
+load findings, how to present them, how to apply verdicts — in phase
+files under `phases/`.
+
+### 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 |
+
+## Identity
+
+You are the facilitator. You don't make triage decisions — you prepare
+the context so the user can make good ones quickly. For each finding,
+you add commentary: what you think about it, what the fix might involve,
+how it relates to other findings or to work already in progress. Your
+commentary is a suggestion. The user's verdict is the decision.
+
+Your job is to minimize triage friction. Every finding should be
+presented with enough context that the user can decide in seconds, not
+minutes. Group related findings. Highlight the ones that matter most.
+Make the verdict buttons (Fix / Defer / Reject) the easiest thing to
+click.
+
+## Verdicts
+
+Three verdicts, plus a question escape hatch:
+
+| Verdict | Meaning | Effect |
+|---------|---------|--------|
+| **Fix** | This finding is real and should be addressed | Creates an action or triggers auto-fix |
+| **Defer** | Real but not now — revisit later | Suppressed in future audits until explicitly resurfaced |
+| **Reject** | Not a real problem for this project | Permanently suppressed in future audits |
+| **?** (Question) | Need more information before deciding | Finding stays open, question is recorded |
+
+**Fix** doesn't mean "fix right now." It means "this is approved for
+action." The action goes into the work tracker; when it gets done is a
+scheduling decision.
+
+**Defer** needs a reason. "Not now" is acceptable if the user has a
+clear sense of when. "Maybe someday" is a reject in disguise — push
+back gently.
+
+**Reject** means "this is noise for our project." A high rejection rate
+for a cabinet member is signal that the cabinet member's calibration is off.
+
+## Workflow
+
+### 1. Load Findings (core)
+
+Read `phases/load-findings.md` for where to get the findings to triage.
+
+**Default (absent/empty):** Query the reference data layer (pib-db) for
+findings with `triage_status = 'open'`. If pib-db is not initialized or
+has no findings, fall back to reading the most recent
+`reviews/*/run-summary.json` file.
+
+Present a summary before triage: how many findings, breakdown by
+severity and cabinet member, how many are new vs previously seen.
+
+### 2. Present for Triage (core)
+
+Read `phases/triage-ui.md` for how to present findings for human judgment.
+
+**Default (absent/empty):**
+1. Prepare commentary for each finding — your assessment of importance,
+   suggested approach, relationship to other findings or open work
+2. Start the local triage server: `node scripts/triage-server.mjs`
+3. POST findings with commentary to the server's API
+4. Tell the user to open the triage UI in their browser
+5. Wait for the user to complete triage (verdicts come back via the
+   server's API)
+
+**IMPORTANT:** Never summarize away findings. Every finding must be
+visible in the triage UI with its full context — title, description,
+assumption, evidence, question, and your commentary. The user needs to
+see everything to make good decisions.
+
+**Fallback (no browser available):** Present findings in the conversation
+grouped by cabinet member, severity-ordered within each group. Ask for
+verdicts one group at a time to avoid overwhelming.
+
+### 3. Apply Verdicts (core)
+
+Read `phases/apply-verdicts.md` for how to act on the user's triage
+decisions.
+
+**Default (absent/empty):** For each verdict:
+
+**Fix verdicts:**
+1. Update finding's triage_status to 'approved' in pib-db
+2. If the finding is marked `autoFixable: true`, attempt the fix
+   immediately. Verify the fix works before marking it done.
+3. If not auto-fixable, create an action in pib-db with:
+   - Text: the finding title
+   - Notes: finding description, evidence, suggested fix
+   - Area: derived from cabinet member or finding metadata
+
+**Defer verdicts:**
+1. Update finding's triage_status to 'deferred' in pib-db
+2. Record the user's reason in triage_notes
+3. The finding will be suppressed in future audit runs
+
+**Reject verdicts:**
+1. Update finding's triage_status to 'rejected' in pib-db
+2. Record the user's reason in triage_notes
+3. The finding will be permanently suppressed in future audit runs
+
+**Question verdicts:**
+1. Finding stays open (triage_status remains 'open')
+2. Record the question in triage_notes
+3. The finding will appear again in the next triage
+
+If pib-db is not initialized, write verdicts to
+`reviews/<run-dir>/triage.json` as a fallback. The next audit's
+`load-triage-history.js` will find them there.
+
+After applying all verdicts, present a summary: how many fixed
+(auto-fixed vs action created), deferred, rejected, questioned.
+
+### 4. Discover Custom Phases
+
+After running the core phases above, check for any additional phase
+files in `phases/` that the skeleton doesn't define. Execute them at
+their declared position.
+
+## Phase Summary
+
+| Phase | Absent = | What it customizes |
+|-------|----------|-------------------|
+| `load-findings.md` | Default: query pib-db, fall back to run-summary.json | Where findings come from |
+| `triage-ui.md` | Default: local triage server + browser UI | How findings are presented |
+| `apply-verdicts.md` | Default: update pib-db + auto-fix + create actions | How verdicts are applied |
+
+## How Triage Connects to Other Skills
+
+**Audit** generates findings; **triage** presents them for judgment and
+applies the decisions. They form a closed loop: audit → triage → suppression
+→ next audit skips triaged items.
+
+**Fix verdicts create actions** that appear in orient's work scan and
+debrief's close-work phase. The triage finding becomes a tracked work
+item through the standard work lifecycle.
+
+**Reject/defer verdicts feed back** into future audits via the triage
+suppression list. Cabinet members learn what this project cares about by
+seeing what gets rejected — persistent rejections from a cabinet member
+signal calibration drift (see `cabinet/_lifecycle.md`).
+
+**The enforcement pipeline** watches for recurring approved findings.
+If the same type of finding keeps getting approved across multiple
+audits, it's a candidate for promotion to a rule or hook — structural
+prevention instead of repeated detection.
+
+## Extending
+
+To customize a phase: write content in the corresponding `phases/` file.
+To skip a phase: write only `skip: true` in the file.
+To add a phase: create a new file in `phases/`.
+
+Examples of phases mature projects add:
+- Batch auto-fix (attempt all auto-fixable findings before presenting
+  the rest for manual triage)
+- Trend surfacing (show how this run compares to previous runs)
+- Deferred resurfacing (periodically bring back deferred findings for
+  re-evaluation based on time or project changes)
+- Team notification (alert team members about findings in their area)
+
+## Calibration
+
+**Core failure this targets:** Audit findings that are generated but
+never acted on, creating a growing backlog of untriaged items that makes
+the entire audit system feel useless.
+
+### Without Skill (Bad)
+
+An audit runs and produces 30 findings. They sit in a JSON file. The
+next audit runs and produces 35 findings — including 25 of the same
+ones. The user glances at the list, feels overwhelmed, and ignores it.
+After three audit runs with no triage, the audit itself gets skipped
+because "it just generates noise."
+
+The system has a learning mechanism (audit) but no judgment mechanism
+(triage). Without judgment, the learning is wasted.
+
+### With Skill (Good)
+
+An audit runs and produces 30 findings. Triage presents them in a
+browser UI, grouped by cabinet member, with commentary on each. The user
+works through them in 15 minutes: fixes 5 (2 auto-fixed, 3 become
+actions), defers 8, rejects 17. The next audit produces 12 new
+findings — the 17 rejected and 8 deferred are suppressed. The triage
+queue stays manageable.
+
+Over time, the system learns what matters to this project. Cabinet members
+that consistently produce rejected findings get retired or recalibrated.
+The audit becomes more precise with each cycle.

package/templates/skills/triage-audit/phases/apply-verdicts.md

@@ -0,0 +1,90 @@
+# Apply Verdicts — Acting on Triage Decisions
+
+Define how triage verdicts are applied. The /triage-audit skill reads
+this file after receiving the user's verdicts.
+
+When this file is absent or empty, the default behavior is: update
+pib-db triage status, attempt auto-fix for fixable findings, create
+actions for approved non-fixable findings. Fallback: write verdicts
+to `triage.json`. To explicitly skip, write only `skip: true`.
+
+## What to Include
+
+Define your verdict application strategy:
+- **Persistence** — where triage decisions are stored
+- **Fix workflow** — what happens when a finding is approved for fixing
+- **Action creation** — how approved findings become tracked work items
+- **Suppression** — how rejected/deferred findings are excluded from
+  future audits
+
+## Default Behavior
+
+### Fix Verdicts
+1. Update `triage_status = 'approved'` in pib-db
+2. If `autoFixable: true`:
+   - Attempt the fix based on the finding's `suggestedFix`
+   - Verify the fix (run relevant tests or checks)
+   - If successful, update `triage_status = 'fixed'`
+   - If failed, create an action instead
+3. If not auto-fixable:
+   - Create an action via `node scripts/pib-db.js create-action`
+   - Include finding details in action notes
+
+### Defer Verdicts
+1. Update `triage_status = 'deferred'` in pib-db
+2. Record reason in `triage_notes`
+3. Finding suppressed in future audits via triage history
+
+### Reject Verdicts
+1. Update `triage_status = 'rejected'` in pib-db
+2. Record reason in `triage_notes`
+3. Finding permanently suppressed in future audits
+
+### Question Verdicts
+1. Finding stays `triage_status = 'open'`
+2. Record question in `triage_notes`
+3. Finding reappears in next triage
+
+### Fallback (no pib-db)
+Write verdicts to `reviews/<run-dir>/triage.json`:
+```json
+{
+  "verdicts": [
+    {
+      "id": "finding-id",
+      "cabinet_member": "...",
+      "title": "...",
+      "verdict": "fix|defer|reject",
+      "notes": "user's reason or question"
+    }
+  ]
+}
+```
+
+## Example Override
+
+Uncomment and adapt for your project:
+
+<!--
+### External Work Tracker
+Instead of creating actions in pib-db, create issues in your
+project tracker:
+```bash
+gh issue create --title "Audit: ${finding.title}" \
+  --body "${finding.description}" \
+  --label "audit-finding"
+```
+
+### External Triage Storage
+POST verdicts to an external API:
+```bash
+curl -X POST https://your-api.example.com/api/triage/verdicts \
+  -H "Content-Type: application/json" \
+  -H "Authorization: Bearer $API_TOKEN" \
+  -d @verdicts.json
+```
+
+### Custom Action Creation
+Create actions with specific formatting, project assignment,
+or area derivation logic based on your project's structure.
+-->