create-claude-cabinet 0.6.0

package/templates/cabinet/lifecycle.md

@@ -0,0 +1,93 @@
+# Cabinet Member Lifecycle
+
+How cabinet members enter, evolve, and leave your project's expertise cabinet.
+Adding a cabinet member is hiring an expert. Retiring one is letting someone
+go when their expertise is no longer needed. Both decisions require judgment.
+
+## When to Adopt a Cabinet Member
+
+**Technology signal.** Adopted React? Consider accessibility and
+small-screen. Using SQLite? Consider data-integrity. Chose a
+UI framework? Consider a framework-quality cabinet member. The technology
+choice itself is the signal — you don't wait for an incident.
+
+**Incident signal.** A security breach, a data loss, a deployment that
+broke production — each reveals expertise the project lacked. Build a
+cabinet member to carry that expertise forward so the system remembers
+what the human might forget.
+
+**Growth signal.** Working with a team? Consider workflow-cop and record-keeper.
+Managing multiple areas? Consider organized-mind. Tracking complex state?
+Consider data-integrity with broader scope.
+
+**Audit gap signal.** During audit triage, you notice recurring friction
+that no cabinet member covers. Before hiring a new cabinet member, check whether
+an existing one could expand its scope. If not, that's a genuine gap.
+
+## When to Retire a Cabinet Member
+
+**No signal, no findings.** If a cabinet member hasn't caught a real issue
+(approved finding) in 3+ audit cycles, it may be dead weight. Check:
+- Has the domain it covers changed? (Migrated off the framework, removed
+  the feature)
+- Are its paths stale? (Files it checks no longer exist)
+- Has another cabinet member absorbed its concerns?
+
+**High rejection rate.** If >50% of a cabinet member's findings are rejected
+at triage, it's miscalibrated. Either refine it (via `eval-protocol.md`)
+or retire it if the domain isn't worth the maintenance.
+
+**Domain no longer relevant.** Dropped the UI framework the cabinet member
+checked. Moved to a managed database that handles integrity itself.
+Retired the feature the cabinet member watched.
+
+Retirement is healthy. A lean cabinet of active cabinet members is better
+than a large one with dead weight. The system stays lean by actively
+pruning, not just actively growing.
+
+## How to Assess
+
+Use `eval-protocol.md` for structured assessment:
+
+1. Define 3-5 assertions about what the cabinet member should catch
+2. Sample recent audit runs for evidence
+3. Score: pass / partial / fail / untestable
+4. Track over time: declining pass rate = drift
+
+**Key metric: triage acceptance rate.** What fraction of a cabinet member's
+findings does the user approve vs reject? This is the strongest signal
+of calibration quality.
+
+## Cross-Portfolio vs Committee-Assigned
+
+Most cabinet members belong in exactly one committee (see `committees-template.yaml`).
+They cover a specific domain and stay in their portfolio.
+
+**Cross-portfolio cabinet members** intentionally span domains. Their expertise
+(reasoning quality, cognitive load, test coverage) touches everything.
+These activate via `standing-mandate` in their SKILL.md frontmatter,
+not by committee membership. Examples: anti-confirmation, qa, debugger,
+organized-mind.
+
+Don't put a cross-portfolio cabinet member in a committee. It would run in committee
+audits where it doesn't belong, and miss unassigned contexts where it does.
+
+## Creating a New Cabinet Member
+
+A cabinet member is a skill with `user-invocable: false`. Create it in
+`.claude/skills/cabinet-{name}/SKILL.md` with:
+
+1. **Identity** — who is this expert? What do they care about?
+2. **Convening Criteria** — `standing-mandate`, `files`, `topics`
+3. **Research Method** — what to examine, what tools to use, what to
+   reason about
+4. **Boundaries** — what this cabinet member does NOT own (prevents overlap)
+5. **Calibration Examples** — good findings, wrong-portfolio findings, severity
+   anchors
+
+Add the cabinet member to your `committees.yaml` under the appropriate committee.
+It's automatically discovered by the audit skill.
+
+The best cabinet members emerge from real incidents and real audit findings.
+Start rough, refine through use. A cabinet member that catches one real issue
+is worth more than one that catches nothing precisely.

package/templates/cabinet/output-contract.md

@@ -0,0 +1,148 @@
+# Audit Output Contract
+
+This file defines how cabinet members produce output when consumed by the
+audit system. Cabinet members themselves are domain-neutral expert lenses;
+this contract adds the audit-specific framing.
+
+## Your Role
+
+You are a system auditor producing structured findings. You are NOT
+fixing anything — you are observing, reasoning, and proposing. Every
+finding is a suggestion that the user will confirm, modify, or reject.
+
+### Audit vs Review
+
+An audit examines **the tool** — is it healthy, maintainable, delivering
+on its promises? A review examines **the user's work** — what needs
+attention, what's stalled, where is energy? You are doing an audit,
+not a review.
+
+You may observe usage patterns as evidence. But the finding must land
+on the tool: "the routing workflow creates friction that discourages
+processing" — not on the user: "the inbox hasn't been processed in
+two weeks."
+
+Every finding should answer: **what should the tool do differently?**
+
+## Finding Quality Standards
+
+**Good finding:** States what was observed, what assumption was made
+about intent, what the concern is, and asks a question the human can
+answer.
+
+**Bad finding:** "This code doesn't follow best practices" — whose
+practices? Why do they matter here? What's the actual risk?
+
+Every finding MUST include:
+- `assumption`: What you think the code/system was trying to do
+- `evidence`: What you actually observed
+- `question`: What you're uncertain about (invites human judgment)
+
+These three fields are what make a finding useful. Without them, the
+finding is just an opinion.
+
+### Finding Hygiene
+
+Group related issues into a single finding when they share a root cause
+(e.g., "5 files duplicate the AREAS constant" is one finding, not five).
+
+Trivial style issues, minor inconsistencies, and "technically correct
+but contextually irrelevant" observations waste triage energy. Every
+finding the user rejects is a tax on their trust in the audit system.
+When in doubt about whether something is worth flagging, include it
+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
+priorities and risk profile.
+
+<!-- Customize these anchors for your project. The examples below
+     illustrate the calibration pattern — replace with your own. -->
+
+- **critical** — Something is broken right now, or data loss /
+  corruption is actively possible. A broken API endpoint, a sync that
+  silently fails, a constraint violation. The user would want to know
+  immediately.
+- **warn** — Degradation, drift, or a real risk that hasn't
+  materialized yet but will if the system grows. A pattern that becomes
+  a problem at 2x current scale. A convention violation that causes
+  confusion.
+- **info** — A genuine improvement opportunity. The system works but
+  could work better. Consolidation of duplicated code, better component
+  usage, clearer documentation.
+- **idea** — A strategic suggestion or opportunity. Not a problem at all.
+
+### Positive Findings (Health Confirmations)
+
+Not everything an audit discovers is a problem. When a subsystem is
+working well, confirming that health is valuable ongoing signal. Mark
+these with `"type": "positive"`:
+
+```json
+{
+  "id": "{cabinet-member}-p{NNNN}",
+  "type": "positive",
+  "perspective": "{cabinet-member-name}",
+  "severity": "info",
+  "title": "Healthy subsystem confirmation",
+  "description": "What was checked and found healthy",
+  "evidence": "Specific checks that passed",
+  "autoFixable": false
+}
+```
+
+**When to emit positive findings:**
+- A subsystem you checked is healthy and functioning as intended
+- A previously-flagged area has been fully resolved
+- Infrastructure (sync, backups, pipelines) is operating normally
+
+**Guidelines:**
+- Keep positive findings concise — one per healthy subsystem
+- Positive findings do NOT enter the triage queue (no approve/reject/defer)
+- They are never suppressed by triage history (generated fresh each run)
+- Use `severity: "info"` for positive findings
+
+### The `autoFixable` Field
+
+Mark `autoFixable: true` ONLY when a fix agent could resolve the
+finding in under 5 minutes with zero design decisions:
+
+- **True:** Add an aria-label, fix a typo, add a missing column to
+  an INSERT, add .env to .gitignore, update a stale string.
+- **False:** Extract a shared component, split a monolith file,
+  redesign a workflow, choose between architectural approaches,
+  anything requiring "should this be X or Y?"
+
+When in doubt, mark false.
+
+## Output Format
+
+Return valid JSON matching `scripts/finding-schema.json`.
+
+```json
+{
+  "findings": [
+    {
+      "id": "{cabinet-member}-{NNNN}",
+      "type": "finding",
+      "perspective": "{cabinet-member-name}",
+      "severity": "critical|warn|info|idea",
+      "title": "Short description (max 120 chars)",
+      "description": "Full explanation",
+      "assumption": "What you think the intent was",
+      "evidence": "What you actually observed",
+      "question": "What you're uncertain about",
+      "autoFixable": false
+    }
+  ],
+  "meta": {
+    "perspective": "{cabinet-member-name}",
+    "timestamp": "ISO-8601"
+  }
+}
+```
+
+Your response must be ONLY the JSON object — no markdown fences, no
+commentary outside the JSON.

package/templates/cabinet/prompt-guide.md

@@ -0,0 +1,266 @@
+# Cabinet Member Prompt Guide
+
+What makes a good cabinet member prompt. This guide is craft knowledge for
+writing and evaluating cabinet member prompts — the `SKILL.md` files in
+`.claude/skills/cabinet-{name}/` that teach Claude how to think about a
+dimension of quality. It's not generic prompt engineering advice. It's
+patterns specific to this system.
+
+## Principles
+
+### 1. Teach Thinking, Not Checklists
+A good prompt gives an analytical framework — *how to reason*
+about a domain. A bad prompt gives a list of things to grep for.
+
+**Good:** "Think about structural sustainability — whether the codebase
+can absorb change without accumulating hidden costs. Use Fowler's debt
+quadrant to classify what you find."
+
+**Bad:** "Check for: unused imports, any types, missing interfaces,
+TODO comments, console.log statements."
+
+The checklist approach breaks when the codebase changes. The thinking
+approach adapts because the agent understands *why* it's looking.
+
+### 2. Each Expert Owns a Domain
+Every cabinet member must have a clear "Boundaries" section that
+names which other cabinet members own adjacent concerns. This prevents
+duplicate work and keeps each expert focused.
+
+**Pattern:** "Mobile layout issues (that's small-screen)" /
+"UI framework component choices (that's framework-quality)" / "Code quality
+issues (that's technical-debt)"
+
+When two cabinet members could plausibly flag the same thing, decide which
+one owns it and update both prompts.
+
+### 3. Use Authoritative External Knowledge
+Cabinet members should go to primary sources, not rely on baked-in
+knowledge that goes stale:
+
+- **MCP documentation servers** — your project's framework docs via
+  MCP tools like `list_doc_sources` and `fetch_docs`
+- **llms.txt pattern** — fetch the docs index, then drill into specific
+  pages for detail
+- **WebSearch** — verify current standards, check for ecosystem updates
+
+**Anti-pattern:** Embedding a static list of framework components in
+the prompt. It goes stale when the framework updates.
+
+**Pattern:** Instruct the agent to fetch the framework's docs index at
+start, then consult specific component pages as needed.
+
+### 4. Preview Tools for Runtime Evaluation
+Cabinet members that evaluate the running app (usability, mobile,
+accessibility, performance) should use preview tools to actually
+interact with the app, not just read code and imagine.
+
+Mark these cabinet members as `interactive-only: true` in frontmatter.
+
+### 5. Observations Land on the Tool
+Findings are about what the *tool* should do differently, not about
+what the *user* should do differently.
+
+Usage patterns can be *evidence* ("inbox items pile up" → the routing
+workflow has too much friction). But the observation is about the tool.
+
+### 6. Flag Divergence Without Presuming Direction
+When documentation and code disagree, present both options:
+- "Update the docs to match the code" OR
+- "Update the code to match the documented convention"
+
+The human decides reconciliation direction. The expert flags the gap.
+
+### 7. Discover, Don't Prescribe
+Agents should discover the current state rather than follow hardcoded
+lists that go stale.
+
+### 8. Acknowledge the Evolving System
+Check `system-status.md` (or equivalent) and don't flag planned features
+as missing. But *do* evaluate whether planned features are the right
+priorities.
+
+### 9. Deep Over Wide
+3-5 well-researched observations with concrete evidence beat 15
+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.
+Individual prompts should reference specific neighbors in "Boundaries."
+
+## Cognitive Architecture Principles
+
+These principles, derived from Daniel Levitin's *The Organized Mind*,
+govern how the skill and cabinet member system itself is designed. They
+apply to anyone creating or modifying skills, cabinet members, or the
+consuming skills that invoke them. Consult the organized-mind cabinet member
+for the full framework.
+
+### 11. Agent Isolation as Designated Places
+Each cabinet member runs in its own agent context — a clean cognitive space
+free from contamination by other cabinet members' findings. This is
+Levitin's "designated place" principle: the hippocampus encodes fixed
+locations reliably; nomadic items get lost. A cabinet member that runs in
+a shared, cluttered context is a nomadic item. An agent is its
+designated place.
+
+Consuming skills (/plan, /execute, /audit) invoke cabinet members via the
+Agent tool, spawning them in parallel. Each agent receives: shared
+briefing + its SKILL.md + the relevant output contract + input data.
+Results are collected and synthesized by the main session.
+
+### 12. Associative Access, Not Single-Path Retrieval
+A skill or cabinet member should be findable via multiple routes — not just
+its canonical name. This is why convening criteria exist: file patterns,
+topic keywords, and standing-mandate declarations create multiple associative
+pathways to the same expert lens. If the only way to find organized-mind
+is to already know it's called "organized-mind," that's single-path
+retrieval — the failure mode Levitin identifies.
+
+When writing descriptions and convening criteria, optimize for
+discoverability from multiple angles.
+
+### 13. Functional Grouping Over Taxonomic
+The cabinet member committees (Code & Architecture, User Experience,
+System Health...) are taxonomic — useful for humans reading the list.
+But when a consuming skill selects cabinet members, it thinks functionally:
+"which lenses are relevant to *this specific change*?" The convening
+criteria are the functional index. Both indexes coexist; neither replaces
+the other.
+
+When organizing skills, ask: "Would someone looking for this by *what
+it does* find it?" not just "Is it in the right category?"
+
+### 14. Respect the Working Memory Limit
+Claude's context window is large but attention is finite. A checkpoint
+that activates 7 cabinet members is viable because each runs in its own
+agent. Within a single context, aim for 3-4 active concerns at a time.
+Escalation logic (any block stops, 3+ conditional = block) respects
+this by collapsing many verdicts into one decision.
+
+### 15. The Legitimate Junk Drawer
+Not everything fits a category. Process-therapist doesn't cleanly belong to
+any committee. Emerging cabinet members may not have clear boundaries yet.
+Forcing premature classification degrades the taxonomy. The
+"uncategorized" state is legitimate infrastructure, not technical debt.
+
+### 16. Affordances in Skill Templates
+The template structure (Identity → Convening Criteria → Research Method
+→ Boundaries → Calibration Examples) is itself an affordance system.
+Each section tells the agent *how to use the skill* without needing
+external memory. If a new skill requires reading documentation outside
+itself to be invoked correctly, the template has failed.
+
+### 17. Externalization Enables
+The cabinet member cabinet isn't just a quality-checking mechanism — its
+structure should reveal what dimensions of quality are covered and what
+aren't. When you add a new feature area and no cabinet member covers it,
+the cabinet's structure should make that gap visible. This is Levitin's
+deepest claim: externalized structure doesn't just prevent errors, it
+makes patterns visible that were invisible from the raw material.
+
+## Skill Sizing
+
+Skills should stay under **500 lines** in their primary SKILL.md file.
+This isn't arbitrary — LLMs have limited attention, and shorter skills
+get followed more reliably. (Source: Anthropic's skill-creator docs.)
+
+**When a skill approaches 500 lines:**
+- Extract detailed reference material to a `REFERENCE.md` file in the
+  skill's directory. The SKILL.md stays lean (core workflow), the
+  reference file holds the detail (API specs, exhaustive examples).
+- Extract extended examples to an `EXAMPLES.md` file.
+- Claude Code automatically loads all `.md` files in a skill's directory,
+  so the extracted files remain accessible.
+
+**When to keep a skill large (>300 lines):**
+- The workflow is genuinely sequential and splitting would lose context
+  that earlier steps need
+- The skill has multiple modes that share significant setup
+
+**When to split:**
+- A skill has 3+ independent workflows that rarely run together
+- Different sections serve different consumers (e.g., a reference section
+  that only one skill needs should be in a separate file)
+
+## Behavioral Calibration Standard
+
+Key skills should include **Without Skill (Bad) / With Skill (Good)**
+calibration pairs — concrete scenarios showing what goes wrong without
+the skill's guidance and how the guidance changes the outcome.
+
+**Format:**
+```
+## Calibration
+
+### Without Skill (Bad)
+[Concrete scenario showing what goes wrong]
+
+### With Skill (Good)
+[Same scenario, showing how the skill's guidance changes the outcome]
+```
+
+Calibration examples ground the skill's instructions in reality. They're
+especially important for skills where "following the instructions" is
+ambiguous — a /plan that produces "vague AC" vs. one that produces
+"testable AC" is the difference between a session that executes cleanly
+and one that stalls.
+
+Not every skill needs these — simple utilities (/menu) don't benefit.
+Focus calibration on skills where miscalibration has high cost: planning,
+execution, session lifecycle, inbox processing.
+
+## Structural Template
+
+Every cabinet member skill should have these sections:
+
+```
+---
+name: cabinet-{name}
+description: Rich 2-3 sentence description for ambient discovery
+user-invocable: false
+---
+
+# {Name}
+
+## Identity
+What this expert thinks about. The analytical framework.
+What makes this cabinet member unique.
+
+## Convening Criteria
+Files: glob patterns that trigger this cabinet member
+Topics: keywords that trigger this cabinet member
+Standing-mandate: which skill types always activate this cabinet member
+
+## Research Method
+Where to get information, how to investigate, what to examine.
+Merged from Knowledge Base + What to Reason About + Paths.
+
+## Boundaries
+What you do NOT examine. Which other cabinet members own it.
+
+## Calibration Examples
+Plain-text observations (not JSON) showing the kind of things
+this cabinet member notices.
+```
+
+## Common Failure Modes
+
+1. **Checklist prompt** — Lists things to grep for instead of teaching
+   how to think. Breaks when the codebase changes.
+2. **Stale references** — Mentions specific file paths, component names,
+   or conventions that no longer exist.
+3. **Boundary violation** — Produces observations that another cabinet member
+   owns. Creates duplicate work.
+4. **Static knowledge** — Embeds framework/library details that go stale.
+   Should point to live docs instead.
+5. **Vague observations** — "This could be improved" without specific
+   evidence or assumption. Not actionable.
+6. **Presumed direction** — "Fix this by doing X" when the right fix
+   might be updating the convention instead. Present options.
+7. **Passive conditional** — Uses "If this session modified X" as a gate
+   without a scan mechanism. Claude is expected to remember what it did,
+   which is exactly the kind of subjective recall that produces false
+   negatives. The fix: add a `git diff --name-only` + `git status` scan
+   before the conditional, and gate on the scan output.

package/templates/hooks/cor-upstream-guard.sh

@@ -0,0 +1,79 @@
+#!/bin/bash
+# CoR Upstream Guard — PreToolUse hook for Edit and Write tool calls
+#
+# Blocks modifications to files managed by Claude Cabinet. These files
+# are upstream-owned: updates come through /cor-upgrade, not direct edits.
+# Project-specific customization goes in briefing files and phase files.
+#
+# How it works:
+#   Reads .corrc.json manifest (list of CoR-installed files with hashes).
+#   If the target file_path is in the manifest, block the write.
+#
+# ROLLBACK: Comment out the PreToolUse entry for this hook in
+# .claude/settings.json to disable it immediately.
+#
+# Hook contract:
+#   Input: $CLAUDE_TOOL_INPUT has the tool use JSON with "file_path" field
+#   Output: JSON on stdout with { "decision": "block"|"allow", "reason": "..." }
+
+# Extract file_path from tool input
+FILE_PATH=$(echo "$CLAUDE_TOOL_INPUT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('file_path',''))" 2>/dev/null)
+
+if [ -z "$FILE_PATH" ]; then
+  echo '{"decision":"allow"}'
+  exit 0
+fi
+
+# Find the project root (where .corrc.json lives)
+# Walk up from current directory
+find_project_root() {
+  local dir="$PWD"
+  while [ "$dir" != "/" ]; do
+    if [ -f "$dir/.corrc.json" ]; then
+      echo "$dir"
+      return 0
+    fi
+    dir=$(dirname "$dir")
+  done
+  return 1
+}
+
+PROJECT_ROOT=$(find_project_root)
+
+if [ -z "$PROJECT_ROOT" ]; then
+  # No .corrc.json found — not a CoR project, allow everything
+  echo '{"decision":"allow"}'
+  exit 0
+fi
+
+# Resolve file_path to a relative path from project root
+# Handle both absolute and relative paths
+if [[ "$FILE_PATH" = /* ]]; then
+  # Absolute path — make relative to project root
+  REL_PATH="${FILE_PATH#$PROJECT_ROOT/}"
+  # If the path didn't change, the file is outside the project
+  if [ "$REL_PATH" = "$FILE_PATH" ]; then
+    echo '{"decision":"allow"}'
+    exit 0
+  fi
+else
+  REL_PATH="$FILE_PATH"
+fi
+
+# Check if this relative path is in the manifest
+IN_MANIFEST=$(python3 -c "
+import json, sys
+try:
+    with open('$PROJECT_ROOT/.corrc.json') as f:
+        data = json.load(f)
+    manifest = data.get('manifest', {})
+    print('yes' if '$REL_PATH' in manifest else 'no')
+except:
+    print('no')
+" 2>/dev/null)
+
+if [ "$IN_MANIFEST" = "yes" ]; then
+  echo "{\"decision\":\"block\",\"reason\":\"Blocked: $REL_PATH is managed by Claude Cabinet. CoR-managed files are upstream-owned — edits come through /cor-upgrade, not direct modification. Put project-specific content in briefing files or phase files instead.\"}"
+else
+  echo '{"decision":"allow"}'
+fi

package/templates/hooks/git-guardrails.sh

@@ -0,0 +1,67 @@
+#!/bin/bash
+# Git Guardrails — PreToolUse hook for Bash tool calls
+#
+# Blocks truly destructive git operations on main. Allows routine solo-dev ops.
+# Single enforcement point (replaces any deny list entries in settings.json).
+#
+# ROLLBACK: If this hook causes problems, comment out the PreToolUse entry
+# in .claude/settings.json to disable it immediately.
+#
+# Hook contract:
+#   Input: $CLAUDE_TOOL_INPUT has the tool use JSON with "command" field
+#   Output: JSON on stdout with { "decision": "block"|"allow", "reason": "..." }
+
+# Read the command from the tool input
+COMMAND=$(echo "$CLAUDE_TOOL_INPUT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('command',''))" 2>/dev/null)
+
+if [ -z "$COMMAND" ]; then
+  echo '{"decision":"allow"}'
+  exit 0
+fi
+
+# Check if command contains git operations worth blocking
+# Returns the block JSON if blocked, empty string if allowed
+check_command() {
+  local cmd="$1"
+
+  # BLOCK: force push to main/master
+  if echo "$cmd" | grep -qE 'git\s+push\s+.*--force(\s|$)' && echo "$cmd" | grep -qE '\b(main|master)\b'; then
+    echo '{"decision":"block","reason":"Blocked: force push to main/master. Use --force-with-lease for safer force push, or push to a feature branch."}'
+    return
+  fi
+
+  # BLOCK: bare force push (no explicit non-main branch)
+  if echo "$cmd" | grep -qE 'git\s+push\s+(-f|--force)(\s|$)' && ! echo "$cmd" | grep -qE '--force-with-lease'; then
+    # Allow if pushing to an explicitly named non-main branch
+    if echo "$cmd" | grep -qE 'git\s+push\s+(-f|--force)\s+\S+\s+\S+' && ! echo "$cmd" | grep -qE '\b(main|master)\b'; then
+      return  # explicit remote + non-main branch is OK
+    fi
+    echo '{"decision":"block","reason":"Blocked: git push --force without specifying a non-main branch. Use --force-with-lease or specify the branch explicitly."}'
+    return
+  fi
+
+  # BLOCK: git reset --hard on main
+  if echo "$cmd" | grep -qE 'git\s+reset\s+--hard'; then
+    local current_branch
+    current_branch=$(git branch --show-current 2>/dev/null)
+    if [ "$current_branch" = "main" ] || [ "$current_branch" = "master" ]; then
+      echo "{\"decision\":\"block\",\"reason\":\"Blocked: git reset --hard on $current_branch. This permanently discards commits. Switch to a feature branch first, or use git reset --soft.\"}"
+      return
+    fi
+  fi
+
+  # BLOCK: git clean -f (deletes untracked files permanently)
+  if echo "$cmd" | grep -qE 'git\s+clean\s+-[a-zA-Z]*f'; then
+    echo '{"decision":"block","reason":"Blocked: git clean -f permanently deletes untracked files. Use git clean -n (dry run) first to see what would be deleted."}'
+    return
+  fi
+}
+
+# Check the full command (handles compound commands since grep matches substrings)
+RESULT=$(check_command "$COMMAND")
+
+if [ -n "$RESULT" ]; then
+  echo "$RESULT"
+else
+  echo '{"decision":"allow"}'
+fi