Pre-plan design interview. Use when the user asks for a feature or change and the right shape isn't obvious yet — before writing-plans, before code. Surfaces requirements, constraints, and trade-offs so the eventual plan rests on a real spec.
Capture the *why* behind decisions as you ship — ADRs for choices that are expensive to reverse, why-comments for non-obvious code, and rules files that stay current. Use when making an architectural decision, changing a public API, or when you've had to explain the same thing twice.
Real-engineer debugging loop — reproduce, minimise, hypothesise, instrument, fix, regression-test. Use when the user reports "X is broken", "this used to work", "I'm getting error Y", or any unexplained failure. Replaces shotgun-debugging with a disciplined cycle.
Review a Dockerfile (or Containerfile) for correctness, layer caching, multi-stage opportunities, image size, security, and reproducibility. Use when the user asks "review my Dockerfile", "why is my image so large?", or "is this Dockerfile good?".
Execute an approved plan step-by-step with checkpoints, batched edits, and visible progress. Use when a plan has been approved and you're about to start implementing, or when the user says "go ahead with the plan", "implement it", or hands you a checklist of steps.
Use `git log`, `git blame`, and `git bisect` to track down when a regression was introduced or why a line of code looks the way it does. Use when the user asks "when did X break?", "who wrote this?", "find the commit that introduced Y", or any historical inquiry about the codebase.
Generate a concise handoff document that a fresh agent (or the same agent in a new session) can use to pick up where the current one left off. Use when the user asks to "summarize where we are", "make a handoff", "compact context before /clear", or any session-transition request.
Review and improve the architectural shape of a module, package, or service — coupling, cohesion, module boundaries, dependency direction, deletion testing. Use when the user asks "is this code well-structured?", "should I split this module?", or "what's wrong with this architecture?".