Use this skill whenever code-review feedback already exists and may affect a code decision or change. This includes PR comments, findings returned by invoke or any external model or review tool, and delegated-review results—even when the user simply says to fix, address, apply, or resolve them. Do not use to perform a new review, diagnose an unrelated bug, implement a new requirement, or merely summarize or explain feedback without deciding about code.
Interview the user to resolve material branches of a decision tree and converge on a shared plan before acting. Use when multiple reasonable choices would materially change scope, cost, reversibility, or outcome, or when the user asks to brainstorm, shape, or grill an idea. Do not use when facts can resolve the ambiguity or a reversible assumption would not materially affect the result.
Draft or review minimal, testable goals. Use only when the user explicitly asks to write, revise, or review a goal.
Create or improve agent skills from concrete behavior and evidence. Use when building or revising SKILL.md, or testing whether a skill earns its context. Do not use for ordinary documentation or one-off prompts.
Diagnose and fix bugs, failures, and performance regressions. Read this skill BEFORE touching any code whenever the user reports a bug, broken behavior, a crash, wrong output, or a regression — even when the cause looks obvious and the user only asked for a fix. Do not use for a simple explanation of a known error when no diagnosis is requested.
Research with parallel agents, independent evidence angles, and cross-validation. Use when the user explicitly asks for parallel or delegated research, or when a high-cost question materially benefits from independent evidence.
Teach with adaptive guidance, retrieval practice, and Socratic questioning. Use when the user wants to study a topic, build durable understanding, practice, or be coached. Do not use for one-off factual answers, quick explanations, or ordinary task guidance.
Test-driven development for production behavior. Use whenever implementing a feature, fixing a bug, or otherwise changing observable production behavior, and before refactoring to establish or verify a green safety net. Do not use for docs-only changes, test-only maintenance, generated artifacts, or exploratory prototypes unless the user asks for TDD.