Split an implementation-ready spec into the fewest independently deliverable vertical tasks and select only risk-justified intermediate review checkpoints. Use when a spec has multiple outcomes needing separate delivery or dependency tracking; keep one coherent outcome as the spec itself.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Require docs/specs/<slug>/spec.md; if it is missing, stop before proposing
tasks.
Read the spec and current code, plus relevant project decisions, glossary terms, and an approved prototype when present. Treat missing implementation as the target gap. Pause on conflicting settled sources and present the exact decision to resolve. When the approved behavior forms one coherent user workflow, keep the spec as the sole handoff; separate operations or states inside that workflow do not create task boundaries.
For work with multiple independently deliverable outcomes, draft the complete shallow map using the fewest independently usable and verifiable outcomes. Fold prerequisite work into the first outcome that makes it useful unless that work is independently deliverable. Declare only blockers that genuinely prevent a dependent outcome.
Cover every spec outcome. For each proposed task show its title, delivered behavior, observable acceptance criteria, focused deterministic verification, task-specific constraints, blockers with reasons, and any review checkpoint. Implementation derives the active outcome's technical approach just in time from the then-current repository, so omit predicted files, functions, code structure, technical-layer steps, context boundaries, and internal sequences. Under a task's constraints record only the references scoped to that task: the approved prototype screens and states it delivers, and a decision contract only it depends on. Name what each governs and leave its rules and screen compositions in the source itself.
Add an intermediate review checkpoint only when a material error could compound through substantial dependent work, or when deterministic checks cannot adequately settle a material risk such as security, data, permission, migration, recovery, or an external contract. Name its cumulative scope and concrete risk. A checkpoint buys one review pass over that scope, not a round that repeats until it reports nothing. The implementation phase owns the single final review over the whole diff.
Present the complete proposal and iterate until the user approves it. Write no task files before that approval.
After approval, record shared settled constraints in the spec and only task-specific constraints in task files. Do not invent unsettled behavior.
Write each approved task to
docs/specs/<slug>/tasks/<NN>-<slug>.md using
templates/task.md, with blockers before dependents.
For an approved revision, remove replaced tasks that have never recorded
completion. Preserve a task with recorded completion history even if it later
returned to in-progress or blocked; after its still-required obligations and
blocker references move to the approved replacement, set it to superseded and
append revision evidence naming the replacement and reason. A superseded task
is terminal for that approved breakdown and is inactive recovery history, not
part of the current delivery map. Do not create an archive. End after writing
the current task handoff, before implementation.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Audit and establish current agent context for the technologies that define a project's stack. Use when setting up a project for agent work, after selecting or adding a framework, library, developer tool, or hosted service, or when entering an existing project whose agent context has not been audited.
The English summary is being prepared. Showing the original description.
Revise active `docs/specs/SLUG/` specs so they match what has shipped since they were written. Use when earlier work has landed and queued specs may now rest on stale assumptions, acceptance criteria, constraints, terms, or prototypes, or when implementation reports a spec as stale before changing source. Takes one or more spec folders, or every folder under `docs/specs/` when none is named. Do not use to shape a new spec from a problem and direction, which belongs to `shape-idea`, or to reconcile durable project context and retire shipped folders, which belongs to `maintain-project-context`.
The English summary is being prepared. Showing the original description.
Build a complete dummy-data HTML prototype or a temporary comparison of up to three alternatives for a specific user situation. Use to settle a screen-based product before implementation or resolve a visual or interaction decision during shaping or prototype review. Do not use for production implementation or CLI, terminal, or voice interfaces.
The English summary is being prepared. Showing the original description.
Create Git commits for the current request's in-scope changes as logical Conventional Commits. Always use this skill for an actual Git commit operation, including requests to commit or amend changes, save work in repository history, stage and record selected files, or group staged or unstaged changes into commits. Use it even when the request describes recording changes without saying "commit"; it performs the commit rather than only suggesting a message, and it does not push.
The English summary is being prepared. Showing the original description.
Interview the user to define or revise the app's overall product direction, then preserve the confirmed meaning in root PRODUCT.md. Always use for a new app direction or any app-wide change to users, usage situations, problem, promised change, core loop, durable boundaries, experience principles, success signals, assumptions, or unknowns, even when PRODUCT.md is not named. Start from an existing definition or a rough app direction. Do not use for blank-page idea discovery, architecture, or shaping or specifying one feature or work unit.
The English summary is being prepared. Showing the original description.
Render an explanation as a diagram, comparison, trace with real values, or annotated code. Use when the user asks to have a concept, decision, flow, or code explained, or says they do not follow.
The English summary is being prepared. Showing the original description.