chore(commands): mark user-invoked commands disable-model-invocation

Add disable-model-invocation: true to the user-triggered slash commands so the harness drops their descriptions from the model's preloaded skill listing while keeping /<name> routing intact. Skills meant for model recommendation (add-tests, debug, five-whys, frontend-design, humanizer, pairwise-tests, playwright-js, playwright-py, root-cause-trace) are unchanged.

17 files changed, 30 insertions, 1 deletions

diff --git a/.claude/commands/arch-decide.md b/.claude/commands/arch-decide.md
index b0b35b8..887e082 100644
--- a/.claude/commands/arch-decide.md
+++ b/.claude/commands/arch-decide.md
@@ -1,5 +1,6 @@
 ---
 description: Create, update, and manage Architecture Decision Records (ADRs) that capture significant technical decisions — context, options, chosen approach, consequences. Five template variants (MADR, Nygard, Y-statement, lightweight, RFC). Covers ADR lifecycle (proposed → accepted → deprecated / superseded), review process, and adr-tools automation. Use when documenting an architectural choice, reviewing past decisions, or establishing a decision process. Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
+disable-model-invocation: true
 ---
 
 # Architecture Decision Records
diff --git a/.claude/commands/arch-design.md b/.claude/commands/arch-design.md
index 2d52ba3..141951d 100644
--- a/.claude/commands/arch-design.md
+++ b/.claude/commands/arch-design.md
@@ -1,5 +1,6 @@
 ---
 description: Shape the architecture of a new or restructured software project through structured intake (quality attributes, stakeholders, constraints, scale, change drivers), then propose candidate architectural paradigms with honest trade-off analysis and a recommended direction. Paradigm-agnostic — evaluates options across layered, hexagonal, microservices, event-driven, CQRS, modular-monolith, serverless, pipe-and-filter, DDD, and others. Outputs a brief at `.architecture/brief.md` that downstream skills (arch-decide, arch-document, arch-evaluate) read. Use when starting a new project or service, restructuring an existing one, choosing a tech stack, or formalizing architecture before implementation. Do NOT use for bug fixing, code review, small feature additions, documenting an existing architecture (use arch-document), evaluating an existing architecture against a brief (use arch-evaluate), or recording specific individual decisions (use arch-decide). Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
+disable-model-invocation: true
 ---
 
 # Architecture Design
diff --git a/.claude/commands/arch-document.md b/.claude/commands/arch-document.md
index 178e847..c22032a 100644
--- a/.claude/commands/arch-document.md
+++ b/.claude/commands/arch-document.md
@@ -1,5 +1,6 @@
 ---
 description: Produce a complete arc42-structured architecture document from a project's architecture brief and ADRs. Generates all twelve arc42 sections (Introduction & Goals, Constraints, Context & Scope, Solution Strategy, Building Block View, Runtime View, Deployment View, Crosscutting Concepts, Architecture Decisions, Quality Requirements, Risks & Technical Debt, Glossary). Dispatches to the c4-analyze and c4-diagram skills for building-block, container, and context diagrams. Outputs one file per section under `docs/architecture/`. Use when formalizing an architecture that already has a brief + ADRs, preparing documentation for a review, onboarding new engineers, or satisfying a compliance requirement. Do NOT use for shaping a new architecture (use arch-design), recording individual decisions (use arch-decide), auditing code against an architecture (use arch-evaluate), or for simple systems where a brief alone suffices. Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
+disable-model-invocation: true
 ---
 
 # Architecture Documentation (arc42)
diff --git a/.claude/commands/arch-evaluate.md b/.claude/commands/arch-evaluate.md
index 6024b79..5ed4450 100644
--- a/.claude/commands/arch-evaluate.md
+++ b/.claude/commands/arch-evaluate.md
@@ -1,5 +1,6 @@
 ---
 description: Audit an existing codebase against its stated architecture brief and ADRs. Runs framework-agnostic checks (cyclic dependencies, stated-layer violations, public API drift) that work on any language without setup, and opportunistically invokes language-specific linters (dependency-cruiser for TypeScript, import-linter for Python, go vet + depguard for Go) when they're already configured in the repo — augmenting findings, never replacing. Produces a report with severity levels (error / warning / info) and pointers to the relevant brief section or ADR for each violation. Use when auditing conformance before a release, during code review, when an architecture is suspected to have drifted, or as a pre-merge CI gate. Do NOT use for designing an architecture (use arch-design), recording decisions (use arch-decide), or producing documentation (use arch-document). Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
+disable-model-invocation: true
 ---
 
 # Architecture Evaluation
diff --git a/.claude/commands/brainstorm.md b/.claude/commands/brainstorm.md
index b18d606..b22196d 100644
--- a/.claude/commands/brainstorm.md
+++ b/.claude/commands/brainstorm.md
@@ -1,5 +1,6 @@
 ---
 description: Refine a vague idea into a validated design through structured one-question-at-a-time dialogue, diverse option exploration (three conventional + three tail samples), and chunked validation (200-300 words at a time). Produces `docs/design/<topic>.md` as the output artifact. Use when shaping a new feature, service, or workflow before implementation begins — or when a "we should probably…" idea needs to become concrete enough to build. Do NOT use for mechanical well-defined work (renames, reformats, dependency bumps), for system-level architecture choices (use arch-design), for recording a single decision that has already been made (use arch-decide), or for debugging an existing error (use root-cause-trace or debug). Synthesized from the Agentic-Context-Engineering / SDD brainstorm pattern — probabilistic diversity sampling originated there.
+disable-model-invocation: true
 ---
 
 # Brainstorm
diff --git a/.claude/commands/c4-analyze.md b/.claude/commands/c4-analyze.md
index 1e20985..d0e5f69 100644
--- a/.claude/commands/c4-analyze.md
+++ b/.claude/commands/c4-analyze.md
@@ -1,6 +1,7 @@
 ---
 description: Analyze a codebase or git repo and generate C4 architecture diagrams (System Context, Container, Component). Use when the user wants to visualize or document the architecture of an existing project. Dispatched by arch-document for building-block and container views; usable standalone for quick architecture visualization. Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
 argument-hint: "[path-or-container-name]"
+disable-model-invocation: true
 ---
 
 # /c4-analyze — Generate C4 Architecture Diagrams from Code
diff --git a/.claude/commands/c4-diagram.md b/.claude/commands/c4-diagram.md
index 3979966..07519ed 100644
--- a/.claude/commands/c4-diagram.md
+++ b/.claude/commands/c4-diagram.md
@@ -1,6 +1,7 @@
 ---
 description: Generate C4 architecture diagrams from a textual description of a software system. Use when the user describes a system they want to diagram, or wants to create architecture diagrams for a planned/proposed system. Dispatched by arch-document for context and container views; usable standalone when the system is described in prose rather than existing code. Part of the architecture suite (arch-design / arch-decide / arch-document / arch-evaluate + c4-analyze / c4-diagram for notation-specific diagramming).
 argument-hint: "[description or diagram level]"
+disable-model-invocation: true
 ---
 
 # /c4-diagram — Generate C4 Architecture Diagrams from Description
diff --git a/.claude/commands/codify.md b/.claude/commands/codify.md
index 414d831..4c3496f 100644
--- a/.claude/commands/codify.md
+++ b/.claude/commands/codify.md
@@ -1,5 +1,6 @@
 ---
 description: Codify concrete, actionable insights from recent session work into the project's `CLAUDE.md` so they survive across sessions and compound over time. Harvests patterns that worked, anti-patterns that bit, API gotchas, specific thresholds, and verification checks. Filters against quality gates (atomic, evidence-backed, non-redundant, verifiable, safe, stable). Writes into a dedicated `## Codified Insights` section rather than scattering entries. Use after a productive session, a bug fix that revealed a non-obvious pattern, or an explicit review where you want learnings preserved as rules. Supports `--dry-run` to preview, `--max=N` to cap output, `--target=<path>` to write elsewhere, `--section=<name>` to override the destination section. Flags insights that look cross-project and suggests promotion to `~/code/rulesets/claude-rules/` instead. Do NOT use for session wrap-up / progress summaries (not insights), for private personal context (auto-memory handles that, not a tracked file), or for formal rules that belong in `.claude/rules/`. Informed by Agentic Context Engineering (ACE, arXiv:2510.04618) — grow-and-refine without context collapse.
+disable-model-invocation: true
 ---
 
 # Codify
diff --git a/.claude/commands/create-v2mom.md b/.claude/commands/create-v2mom.md
index f1add2f..a63ca50 100644
--- a/.claude/commands/create-v2mom.md
+++ b/.claude/commands/create-v2mom.md
@@ -1,5 +1,6 @@
 ---
 description: Create a V2MOM (Vision, Values, Methods, Obstacles, Metrics) strategic framework for any project, goal, or domain — personal infrastructure, business strategy, health goals, financial planning, software development, career planning, or life goals. Walks the user through the five sections in order: Vision first (aspirational picture of success), then Values (2-4 principles that guide decisions), Methods (4-7 prioritized approaches with concrete actions), Obstacles (honest personal and external challenges), and Metrics (measurable outcomes, not vanity metrics). Includes an optional task-migration phase that consolidates an existing todo list under the defined Methods. Use when the user asks to create a V2MOM, build a strategic plan, set goals for a significant project, or apply ruthless prioritization without an existing framework. Do NOT use for simple todo lists, single-decision prompts (use /arch-decide), quick task brainstorming (use /brainstorm), or daily/weekly planning of routine tasks. Produces a document that becomes the project's decision-making source of truth.
+disable-model-invocation: true
 ---
 
 # /create-v2mom — Create a V2MOM Strategic Framework
diff --git a/.claude/commands/finish-branch.md b/.claude/commands/finish-branch.md
index b65a7f0..9638f5b 100644
--- a/.claude/commands/finish-branch.md
+++ b/.claude/commands/finish-branch.md
@@ -1,5 +1,6 @@
 ---
 description: Complete a feature branch with a forced-choice menu of outcomes (merge locally / push + open PR / keep as-is / discard). Runs verification before offering options (tests, lint, typecheck per the project's conventions — delegates to `verification.md`). Requires typed confirmation for destructive deletion (no accidental work loss). Handles git worktree cleanup correctly: tears down for merge and discard, preserves for keep and push (where the worktree may still be needed for follow-up review or fixes). References existing rules for commit conventions (`commits.md`), review discipline (`review-code`), and verification (`verification.md`) — this skill is the workflow scaffold, not a re-teach of the underlying standards. Use when implementation is complete and you need to wrap up a branch. Do NOT use for mid-development merges (that's normal git flow), for the wrap-up *of a whole session* (different scope — session-end is narrative + handoff, not branch integration), for creating a new branch (no skill for that — just `git checkout -b`), or when review hasn't happened yet (run `/review-code` first, then this).
+disable-model-invocation: true
 ---
 
 # /finish-branch
diff --git a/.claude/commands/prompt-engineering.md b/.claude/commands/prompt-engineering.md
index f2c240a..8e03367 100644
--- a/.claude/commands/prompt-engineering.md
+++ b/.claude/commands/prompt-engineering.md
@@ -1,5 +1,6 @@
 ---
 description: Craft prompts (commands, hooks, skill descriptions, sub-agent instructions, system prompts, one-shot requests to other LLMs) that do what they're meant to and resist common failure modes. Covers four moves that determine whether a prompt holds up: classify the prompt type (discipline-enforcing / guidance / collaborative / reference) to pick the right tone and techniques; apply the persuasion framework appropriate to that type (seven principles from Meincke et al. 2025, including which to avoid — notably Liking, which breeds sycophancy); match task fragility to degrees of freedom (high/medium/low); and spend the context window like a shared resource. Also contains a brief reference for classical techniques (few-shot, chain-of-thought, system prompts, templates). Use both in design mode (asking for help writing a new prompt from scratch) and critique mode (paste a draft, get it rewritten to resist common failure modes). Do NOT use for prose editing unrelated to LLM prompts (use a writing skill), for implementing application code that uses an LLM (different scope), or for content moderation / prompt-injection defense (adjacent but separate domain).
+disable-model-invocation: true
 ---
 
 # Prompt Engineering
diff --git a/.claude/commands/refactor.md b/.claude/commands/refactor.md
index 57acd5e..ce3aaaa 100644
--- a/.claude/commands/refactor.md
+++ b/.claude/commands/refactor.md
@@ -1,6 +1,7 @@
 ---
-description: Scan code for refactoring opportunities or perform targeted refactoring operations
+description: Scan code for refactoring opportunities or perform a targeted refactor. Six modes — `full` (default; complexity + duplication + dead-code scans), `quick` (high-severity findings only), `complexity` (length / nesting / cyclomatic / parameter count / boolean ops with severity bands and techniques like guard clauses, extract method/predicate, parameter object, decompose conditional), `duplication` (clones / logic / constants / patterns / error-handling with extract-function / parameterize / template-method strategies), `dead-code` (imports / exports / branches / feature flags / deps with high/medium/low confidence labels), `rename old new` (codebase-wide symbol rename with reference search, preview gate, atomic commit, post-apply verification). Findings render as `[SEVERITY] Category — File / Metric / Issue / Suggestion` blocks plus a summary table and quick-wins. Structure-only — no feature work mixed in, no auto-apply without confirmation, characterization tests first when coverage is missing, small focused commits. Use for cleanup or wide renames. Do NOT use for behavior changes (`fix:` or `feat:`, not refactor), green-field design (use `/arch-design`), or single-symbol single-file renames (just edit). Companion to `/add-tests` for the characterization-test prereq.
 argument-hint: "[scope: full|quick|complexity|duplication|dead-code|rename old new]"
+disable-model-invocation: true
 ---
 
 # /refactor — Code Refactoring Skill
diff --git a/.claude/commands/respond-to-cj-comments.md b/.claude/commands/respond-to-cj-comments.md
index 61cf533..35977d1 100644
--- a/.claude/commands/respond-to-cj-comments.md
+++ b/.claude/commands/respond-to-cj-comments.md
@@ -1,3 +1,8 @@
+---
+description: Scan a target file for inline `cj:` annotations (Craig's in-line questions and instructions; multi-line continuations recognized across most comment markers) and process each via subagent-delegated accuracy. Each item is classified instruction / question / both, then dispatched to an instruction subagent (proposes a file:line patch) or a question subagent (researches with explicit scope, reports answer + evidence + confidence). Main thread reviews proposals before editing — subagents don't write to the source file. Org-mode TODO parents flip to DOING; new content lands under timestamped subheadings one level deeper. Public-facing writing (commits, PRs, Slack, email, public docs) gets a humanizer pass plus `commits.md` voice rules; private writing skips humanizer. Summary lists handled instructions, answered questions with evidence + confidence, follow-ups, unresolved items, and an explicit clean / N-remain verdict. Long summaries (>6-8 items or >500 words) write to `/tmp/` and open in `emacsclient -n`. File paths render as clickable absolute org-mode links. Use when a file accumulates inline `cj:` comments. Do NOT use for general code review (`/review-code`), new work without inline comments, or trivial items.
+disable-model-invocation: true
+---
+
 # /respond-to-cj-comments — Process `cj:` Annotations in a File
 
 Scan a file for `cj:` comments (Craig's in-line instructions and questions) and handle each one with subagent-delegated accuracy. Used to batch-process notes Craig leaves in documents, code, or org files for later action.
diff --git a/.claude/commands/respond-to-review.md b/.claude/commands/respond-to-review.md
index 3508fa5..d86b1ea 100644
--- a/.claude/commands/respond-to-review.md
+++ b/.claude/commands/respond-to-review.md
@@ -1,3 +1,8 @@
+---
+description: Process pending review comments on a PR through five steps (Gather, Evaluate, Respond, Implement, Report). Each comment is verified against the actual codebase before action — restated in your own words, checked for accurate premise, YAGNI-tested if it suggests "more proper" architecture without current consumers, then categorized as correct-and-actionable, correct-but-out-of-scope, debatable, or incorrect. Disagreement is framed with code references rather than opinion. Implementation handles simple fixes first, tests each change individually, commits with conventional messages referencing the review. Final report lists what was implemented, what was deferred to follow-up issues, and what still needs discussion. Use when responding to PR review feedback. Do NOT use for proactively reviewing code (use `/review-code`), for the publish flow itself (use the Review-and-Publish steps in `commits.md`), or when the PR has no review comments yet.
+disable-model-invocation: true
+---
+
 # /respond-to-review — Evaluate and Implement Code Review Feedback
 
 Evaluate code review feedback technically before implementing. Verify suggestions against the actual codebase — don't implement blindly.
diff --git a/.claude/commands/review-code.md b/.claude/commands/review-code.md
index e7f4e18..d6501d0 100644
--- a/.claude/commands/review-code.md
+++ b/.claude/commands/review-code.md
@@ -1,5 +1,6 @@
 ---
 description: Review code changes against engineering standards. Accepts a PR number, a SHA range (BASE..HEAD), the current branch's diff against main, staged changes, or a described scope ("the last 3 commits"). Audits CLAUDE.md adherence (reads root + per-directory CLAUDE.md), intent-vs-delivery (when given a plan/ADR/ticket), security, testing (TDD evidence + three-category coverage), conventions (conventional commits + no AI attribution), root-cause discipline, architecture (layering + scope), API contracts. Produces a structured report — Strengths, per-criterion PASS/WARN/FAIL, per-issue Critical/Important/Minor severity — ending with an explicit verdict (Approve / Request Changes / Needs Discussion) plus 1-2 sentence reasoning. Self-filters low-confidence findings; never flags pre-existing issues, lint/typecheck issues (CI handles those), or changes on unmodified lines. Use before merging a PR, before pushing a branch, or when reviewing a teammate's work. Do NOT use for proposing features (use brainstorm or arch-design), drafting implementation (use start-work or add-tests), standalone security audits (use security-check), or narrow style-only checks (a linter handles those).
+disable-model-invocation: true
 ---
 
 # /review-code
diff --git a/.claude/commands/security-check.md b/.claude/commands/security-check.md
index ca431e0..0880e99 100644
--- a/.claude/commands/security-check.md
+++ b/.claude/commands/security-check.md
@@ -1,3 +1,8 @@
+---
+description: Audit staged changes (or a specific file/directory) for security issues in three categories. Hardcoded secrets — AWS keys, `sk-`/`sk_live_`/`sk_test_` patterns, password/secret assignments, private-key blocks, `.env` contents, API tokens, JWTs, bearer tokens. OWASP top-10 — SQL injection via string concatenation, XSS via unsanitized rendering, missing permission checks, unsafe deserialization (`eval`/`exec` on untrusted data), debug-mode misconfigs, PII or tokens in logs. Dependency risks — runs `pip-audit` for Python diffs, `npm audit` for JS/TS diffs, flags new unpinned deps. Scope defaults to `git diff --cached`; falls back to the last commit if nothing's staged; an explicit path overrides. Reports findings in a severity-ranked table (CRITICAL/HIGH/MEDIUM/LOW/INFO) with file:line + recommendation per row, or a "no issues detected" verdict listing what was checked. Use before committing changes touching security-sensitive paths. Do NOT use for full-codebase audits (diff-scoped — see Claude Code's `/security-review` for branch-wide review), runtime/fuzzing analysis, or as a substitute for full-lockfile dependency scanning.
+disable-model-invocation: true
+---
+
 # /security-check — Audit Changes for Security Issues
 
 Scan staged or recent changes for secrets, OWASP vulnerabilities, and dependency risks.
diff --git a/.claude/commands/start-work.md b/.claude/commands/start-work.md
index d3d9349..bf32801 100644
--- a/.claude/commands/start-work.md
+++ b/.claude/commands/start-work.md
@@ -1,5 +1,6 @@
 ---
 description: Pick up a task (Linear ticket, GitHub issue, todo.org task, or a described scope) and take it through Claim, Justify, Approach, Implement, Verify, and Hand-off. Three user-approval gates separate the phases. The Justify gate covers benefits, costs, engineer/user impact, urgency, effort, alternatives, and a ticket-quality check. The Approach gate covers root cause, risk, refactor prerequisites, test strategy (unit, integration, e2e, pairwise, characterization), migration and backwards-compat, feature-flag question, commit decomposition, and branch name. Implementation uses TDD (red, green, edge cases, refactor audit of every touched file). The audit walks the whole of each touched file against a language-agnostic checklist; every finding is either fixed on this branch or filed as a ticket — nothing is silently dropped. A verify phase exercises the feature end-to-end in the local environment (Playwright against localhost for web projects, scripted manual test otherwise) before the final gate confirms readiness and hands off to the Review-and-Publish flow in commits.md. Use when starting work on a specific task where both "should we" and "how exactly" are worth deliberating. Do NOT use for open-ended bug investigation without a clear target (use debug first), for architectural paradigm exploration (use arch-design), for architectural decision recording (use arch-decide), when the task is trivial and obvious (just do it), or when requirements are still being shaped (use brainstorm).
+disable-model-invocation: true
 ---
 
 # /start-work: pick up a task, justify it, plan it, build it