Design types, interfaces, module boundaries, and ownership before implementing a non-trivial feature or structural change. Use when an early design choice would constrain several files or components. Do not use for a small local edit or when an approved design already exists.
Assemble the smallest trustworthy context needed for an active engineering task. Use when resuming long work, switching subsystems, handing work between agents, or when stale or excessive context is degrading decisions. Do not activate for a small self-contained request.
Prepare and assign one bounded, independently verifiable subtask to a subagent. Use when delegation is available and authorized, one work unit can proceed without shared mutable state, and parallel or specialized work will materially help. Do not use merely to avoid doing a small task locally.
Reproduce a failure, regression, or performance problem and identify its root cause with evidence. Use when the user asks why something is broken, failing, crashing, flaky, or slow. Do not modify the implementation unless the request also asks for a fix.
Transfer active engineering work to another agent or session without losing decisions, evidence, or the next executable step. Use when the user requests a handoff, work must continue elsewhere, or context limits threaten continuity. Do not use as a generic session summary.
Determine what a proposed or completed change could break outside its immediate diff. Use for blast-radius analysis, shared contracts, migrations, risky refactors, and changes to public interfaces or persistent data. Do not use for a general code review with no cross-boundary risk.
Make an authorized code or configuration change from a settled request, specification, or task. Use when the user asks to build, fix, add, or change something and the implementation scope is clear. Do not use for diagnosis-only, review-only, or planning-only requests.
Maintain a compact evidence-backed decision trail for long-running, unattended, or high-risk engineering work. Use when later reviewers must understand what changed, why, and what proved it. Do not activate for routine short tasks or duplicate ordinary progress narration.
Move code, callers, data, configuration, or dependencies from an old contract to a new one with explicit compatibility and rollback decisions. Use for API, schema, framework, dependency, or storage migrations. Do not use for a simple isolated replacement with no consumers.
Simplify existing code, improve module depth, or reduce reader load while preserving observable behavior. Use when the user explicitly requests restructuring or when a behavior-preserving cleanup is the task. Do not activate for ordinary feature work that merely touches imperfect code.
Extract reusable, evidence-supported improvements after a completed engineering session, repeated failure, or explicit retrospective request. Use when the goal is to improve future agent behavior or an existing workflow. Do not activate automatically after every task or create new rules from a single preference.
Review a diff, branch, pull request, or work-in-progress change for correctness, requirement fit, regressions, and maintainability. Use when the user asks for code review or assessment of completed changes. Report findings without editing unless a fix is also requested.
Break a large or multi-session engineering objective into ordered, verifiable stages with dependencies and checkpoints. Use when the work spans several components or cannot be safely held in one execution pass. This skill plans but does not implement.
Map an unfamiliar codebase, trace runtime flow, locate ownership, and identify the files that matter. Use for codebase orientation, onboarding, placement questions, and investigation before planning. This is a read-only skill and does not design or implement changes.
Turn settled requirements or an existing conversation into an implementation-ready specification with testable behavior and explicit scope. Use when the desired outcome is mostly known and needs consolidation. Do not use for open-ended discovery or implementation.
Apply language, framework, database, HTML, CSS, accessibility, and responsive UI quality standards when writing, editing, refactoring, reviewing, or organizing source code, tests, schemas, migrations, queries, and web interfaces. Detect the active stack and load only its references. Do not use for prose-only or…
Fan out several independent investigations or candidate solutions and synthesize them into one judged result. Use when broad coverage, competing designs, or separable evidence lanes justify parallel agents and delegation is authorized. Do not use for dependent steps or shared mutable state.
Develop a feature or bug fix through a focused failing-test, minimal-implementation, and refactor loop. Use when the user requests TDD, asks for a regression test, or the bug has an obvious cheap local test target. Do not force TDD when the useful test path is unclear, expensive, or integration-heavy.
Classify an incoming issue, bug report, alert, or external pull request and turn it into an actionable engineering brief. Use when work needs validation, priority, ownership, or missing-information assessment before implementation. Do not solve the issue unless separately requested.
Prove that completed engineering work satisfies its requirements using the real artifact, focused tests, and diff inspection. Use before declaring implementation complete or when the user asks whether a change actually works. Do not replace diagnosis or code review.