spec-driver

Canonical reconciliation runsheet for AUD artefacts. Create or update the audit, disposition every finding, reconcile specs/contracts, and hand off to closure only when audit state supports it.

Close a delta safely - satisfy coverage gates, complete the delta command, and verify owning-record lifecycle updates.

Orchestrate parallel implementation via sub-agents. Drives an entire delta to completion across all phases — planning, dispatching, merging, and continuing automatically. Batches tasks by token budget, routes to appropriate models (sonnet/opus), and dispatches workers in isolated worktrees. Use instead of /execute-phase when a phase has parallelizable work.

Mandatory execution skill for any delta/IP implementation phase. Use it before code changes, move the owning delta to in-progress, keep notes current, reconcile structured execution docs, and surface blockers early.

Whenever you complete a task or phase - record implementation notes.

Reconcile DE/IP/phase/DR execution artefacts during delta work. Use this when implementation changes structured execution state, not just notes.

Mandatory onboarding. Every agent MUST execute this on startup, or as soon as becoming aware of it.

Invoke this skill whenever any of the following occurs during work: (1) you discover or confirm a durable fact, constraint, invariant, or “how we do X here” pattern; (2) you create a new workflow/checklist that will be reused; (3) you resolve a recurring confusion (“where is the source of truth?”); (4) you make a decision that is not an ADR/SPEC but would prevent rework; (5) you detect a sharp edge, footgun, or non-obvious dependency that future agents will hit. Do NOT rely on conversational context to persist. When the information would save ≥10 minutes for a future agent, write a memory record immediately.

Write a prompt to help the next agent continue effectively.

Plan execution for a delta - refine IP objectives/gates and create the next phase sheet with concrete tasks and verification expectations.

Lightweight spec-driver fluency for dispatch workers. Provides the minimum vocabulary, commands, and boundaries needed to navigate a spec-driver project without full boot ceremony. Loaded via skills: frontmatter in dispatch-worker agent definition.

Draft or refine a design revision (DR) for a delta. Use it when a DR needs concrete design shaping, explicit question triage, and section-by-section validation before implementation planning.

Scope intentional change as a delta. Define applies-to specs/requirements, risks, and closure targets before implementation.

Mandatory routing skill for ANY substantive work in a spec-driver project. Choose the governing skill before acting, and do not start implementation until the required delta/design/plan/phase artefacts exist.

Identify and address obstacles, significant decisions, or emergent complexity. You MUST use this skill if you encounter unanticipated obstacles during implementation.

Invoke this skill whenever you observe memory drift or when your actions would invalidate existing memories. Mandatory triggers: (1) you change a workflow/command, move files, rename modules, or change invariants; (2) you discover a memory is wrong, missing provenance, or stale; (3) you see a memory record guiding behaviour that is no longer true; (4) you find duplicates or near-duplicates; (5) you are about to add a new memory that overlaps an existing one. Core rule: if you change reality, you must change memory in the same change-set (or immediately after) so future agents do not inherit incorrect guidance.

Print a concise continuation prompt for the next agent. Use this when everything is written down and in order for the next agent, and the user has indicated they wish to continue with fresh context.

Use after routing has already happened, when the next step is bounded up-front research to understand a substantive task, surface unknowns and tensions, and assess readiness without drifting into implementation or open-ended exploration.

Invoke this skill before making non-trivial assumptions in a large codebase. Mandatory triggers: (1) you are about to modify a subsystem you have not touched in this run; (2) you are about to run, change, or suggest a command pipeline (tests, builds, releases, migrations); (3) you see conflicting cues in code/docs; (4) you are asked “what is the right way here?”; (5) you are debugging a recurring failure mode; (6) you are about to answer with “probably/usually/likely”. Default rule: if you cannot cite a source-of-truth file/doc/ADR/SPEC from the repo, you must consult memories first and then proceed.

Invoke this skill as a deliberate review pass whenever stability matters: (1) before a release/migration/large refactor; (2) at the start of work in an unfamiliar subsystem; (3) when you see repeated agent confusion; (4) when thread-type working sets accumulate; (5) when you suspect stale guidance is causing defects. This is not ad-hoc maintenance; it is a structured audit to prevent systemic drift.

Shape a spec revision when requirements/responsibilities move. Use this before delta scoping when policy/doctrine requires revision-first flow, or when audit reconciliation shows authority must move.

Use this skill any time work involves creating, listing, finding, showing, editing, completing, syncing, or otherwise interacting with spec-driver entities via the CLI. Trigger it whenever a user asks to create or inspect ADRs, specs, deltas, revisions, audits, memories, policies, standards, backlog items, or related workflow artefacts, especially if there is any temptation to guess IDs, paths, or command shapes.

Understand project governance to avoid spreading heresy. you

implement a well-defined task or implementation plan