spar-kit

After install or on demand, complete the repo-local spar-kit setup by checking version freshness, AGENTS.md, .spar-kit/.local/tools.yaml, and .gitignore hygiene; make safe repairs or recommendations, then finish with a short handoff to spar-specify.

Use after the initial spec exists and the user is ready to turn it into an implementation plan. Complete the spec, define testable success criteria, settle important decisions, create an ordered plan with approach, execution constraints, tasks, validation strategy, and risks, then ask before starting implementation.

Use after the user has approved implementation. Execute the active plan sequentially, follow the plan's approach, execution constraints, validation strategy, and risks, update task progress, stop for spec drift or blockers, and ask before starting retention.

Use after implementation when the user approves closeout. Reconcile the active spec and plan with what shipped, propose broader documentation updates for approval, then move the whole change folder from specs/active to specs/completed.

Use this skill when the user wants to define a new feature, bug fix, or significant change before planning or implementation. Clarify intent, problem, scope, out-of-scope boundaries, success picture, important unknowns, and a folder-safe change name; create the initial SPAR spec without drafting implementation tasks or build steps.

Executes plan.md for an active change under Docs/<scope>/Specs/<change-name>/. Use after plan-change when the user approves implementation. Follows tasks in order, validates each step, retries obvious failures once, and stops to ask if blocked. Does not change spec intent without approval.

Finalizes documentation for a completed change under Docs/<scope>/Specs/<change-name>/. Aligns <change-name>_spec.md with final behavior, proposes broader doc updates for approval, and moves the change folder to Archive. Use after implement-change when implementation is done and the user wants cleanup and durable docs.

Turns a change idea into a stable <change-name>_spec.md and actionable plan.md under Docs/<scope>/Specs/<change-name>/. Opens with a fixed prompt for goals/context, then conversationally resolves scope and naming; proceeds through workflow steps in order. Tone: concise, cheerful, inquisitive. Does not create the Specs folder, <change-name>_spec.md, or plan.md until scope and change-name are confirmed. Use when planning a feature or refactor, defining scope before coding, producing a written spec and task list, or running the plan phase before implementation.