architecture-case-study
Use when studying the architecture of an open-source codebase for the case-study series — "case study", "architecture study", "study how X is built", adding a subject under ~/devel/case-studies. Not for reviewing our own projects' code.
commit-decomposition
Use when breaking one or more oversized git commits into a series of logical commits — "decompose this commit", "break up this history", "atomic commits for this range". Lead-orchestrated - fresh subagent per patch, diff-parity gate, state file as cursor.
consulting-agents
Use when you need information you don't have, expertise outside your comfort zone, or a single fresh perspective on code — even if you think you already know the answer. Also triggered by "I'm not sure about", "what's the best approach", "second opinion", "research how X works", or any need for discovery, expertise, or review. For multi-perspective reviews where agents discuss and converge, use design-meeting instead. NOT for implementation delegation (see subagent-driven-development).
evidence-and-claims
Use when performing investigative work that produces reports or analysis for others to verify — root cause analysis, bug investigation, crash analysis, sosreport analysis, or any task making factual claims about system behavior. Also triggered by "investigate", "root cause", "analyze", "RCA", "figure out why", "what's causing", "track down", "write a report", "write up findings", "document what you found". Do NOT activate for quick lookups, code reviews, implementation tasks, or design work.
git-anchoring
Use before any git surgery — history rewriting, commit decomposition, rebase-heavy work, or any task that moves refs around. Establishes anchor refs, on-disk state, and worktree isolation so work cannot be orphaned and any fresh context can re-orient. Also use when recovering seemingly lost commits.
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
interactive-rebase
Use when you need to amend a non-HEAD commit in git history without an interactive editor — automates rebase via fixup, autosquash, and GIT_SEQUENCE_EDITOR=true
project-insights
Generate a Claude Code usage-insights report for a single project by analyzing its session transcripts. Use when the user wants per-project insights, a session-history retrospective, "what have I been doing in this repo", or a homegrown/markdown version of the built-in /insights. Mirrors the built-in /insights pipeline (per-session facet extraction -> aggregate facets -> at-a-glance) but scoped to one project and emitting markdown.
retro
Use when Jerry asks for a retrospective, a weekly review, a summary of the past week's work, or "what kept getting in our way"; also when /wakey reports a retro is due.
sandbox-research
Run a research task in an isolated sandbox container with deterministic + semantic validation, retry-on-block (max 2 retries), and auto-archival to the research-vault. Use when the user asks to "research X with the sandbox", invokes /sandbox-research, or wants a structured research artifact rather than ad-hoc browsing.
stgit-stack-editing
Use when amending, reordering, or splitting commits in an in-progress patch series — especially fixing reviewer findings inside the offending commit instead of stacking fixup commits. Stacked Git (stg) alternative to interactive-rebase.
sync-devcontainer
Sync a project's .devcontainer/ files with the canonical template at ~/.claude/scratchpad/devcontainer-template/, or scaffold a new .devcontainer/ from the template. Triggers on /sync-devcontainer with optional arguments — no args (current project), <path> (specific project), or 'all' (sweep ~/devel/*).
using-claude-design
Use when creating or iterating on a design in a claude.ai/design project via the claude-design MCP server, before calling any mcp__claude-design__ tools.
writing-rubrics
Use when creating an evaluator or judge prompt for agent outputs — a rubric, scoring scheme, quality score, acceptance criteria for a generate-critique-revise loop, or a Workflow verify stage. Also use when an existing loop shows scores rising without real improvement, a judge growing lenient across iterations, or a request for "one overall score" or "give the judge the full conversation".