skills

Execute the tasks of a plan at .dev/{plan-name}/, test-first across unit/integration/e2e, running independent tasks in parallel and looping until every task is done and the e2e suite passes. Use when the user asks to implement a plan or its tasks, work through task files, or wants red-green TDD with an e2e report.

Turn a feature request, spec, or problem statement into a reviewable plan at .dev/{plan-name}/plan.md. Use when the user wants work planned before implementation.

Run the pre-implementation moves that reduce unknowns before planning starts - a blind spot pass over unfamiliar territory, a brainstorm/prototype pass for an undecided shape, and a one-question-at-a-time interview for ambiguities that would change architecture. Use before to-plan when the request touches unfamiliar code, an undecided UX/architecture direction, or open ambiguities; skip straight to to-plan when the work is already well understood.

Package a completed change - its plan, implementation notes, and verification evidence - into a shareable buy-in doc published as an Artifact. Use once implementation is done and the change needs buy-in or visibility beyond the author, not for trivial one-line fixes.

Concern-based fan-out review of a branch or PR where every finding is adversarially verified before it is reported, producing .dev/{plan-name}/review_N.md. Use when the user asks for a code review of their changes or before opening a PR.

Split a plan at .dev/{plan-name}/plan.md into numbered task files (task_1.md, task_2.md, ...) sized for individual implementation. Use after to-plan when execution spans multiple tasks, or to break an existing plan into tasks.

Render a context/intuition/what-was-done doc with a graded comprehension quiz on finished work, published as an Artifact for a reviewer or author to read before merging. Use when the user wants a comprehension check on a change before it merges.