Instructions for Jed-Tech/spar-kit, a project described as: Specify → Plan → Act → Retain: SPAR-kit is a lightweight workflow that helps AI agents align with your intent, plan clearly, act with less drift, and retain durable project memory.
Executes plan.md for an active change under Docs/ /Specs/ /. 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/ /Specs/ /. Aligns 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 spec.md and actionable plan.md under Docs/ /Specs/ /. 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, spec.md, or plan.md…
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.
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 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…