dev-spec-kit

Build, refresh, and read dev-spec-kit's Verified Traceability Graph — provider-agnostic. Keep it fresh with the build wrapper, read blast radius / implements-edges / drift to answer "what breaks if this changes?", and run the staleness re-prove dance. For choosing and configuring the code-graph engine itself, see the dev-spec-kit-revitify and dev-spec-kit-graphify skills.

dev-spec-kit's optional code-graph provider — the external Python graphify tool (multi-modal: indexes PDFs, images, and video alongside code). Opt-in only. Use to decide when graphify is worth its install over the bundled revitify default, how to install and configure it, and how dev-spec-kit verifies and falls back when it is absent. For the build/read loop itself, see dev-spec-kit-graph.

dev-spec-kit's default code-graph provider — the bundled revitify engine (native TypeScript, tree-sitter multi-language). Zero install, zero API key, always available. Use to understand when revitify is the right provider, how it is configured, what it can and cannot index, and how it feeds the Verified Traceability Graph. For the build/read loop itself, see dev-spec-kit-graph.

Drive spec-driven development with dev-spec-kit — route the request, write EARS specs with @check bindings, derive evidence-bound tasks, TDD, prove checks with real test runs, build the Verified Traceability Graph, record approvals, and generate graph-derived PR bodies. Use whenever the user asks to build/change code in a dev-spec-kit-initialized project (.dev-spec-kit/ present) or mentions rivet, specs, EARS, or traceability.

Score each requirement's complexity 1–10 and recommend a subtask breakdown, then expand the over-scoped ones into bound sub-criteria. Use after a spec is drafted and before implementation, to catch requirements that are too big to prove as a single unit.

Turn approved requirements into a thin high-level design and the Architecture Decision Records (ADRs) that justify the non-obvious choices. Use after requirements are clarified and before implementation, or when a change makes a load-bearing architectural decision.

Resolve ambiguity in a raw intake or draft spec by asking the user ≤5 high-value questions, each with a recommended default. Use before finalizing a full-spec route, or when `spec.onVague` is "clarify", or whenever a requirement is under-specified.

The completion ritual — run when a feature's tasks are done and it's time to land the branch. Fresh-evidence entry gate, a fixed option menu, typed confirmation for destructive paths, provenance-checked cleanup, every step journaled. Use when the user says finish/land/merge/wrap up, or after dev-spec-kit pr is ready.

Turn a raw idea, voice-dump, or ticket into a dev-spec-kit intake file and route it. Use when the user brain-dumps a request, pastes a Jira/GitHub/GitLab ticket, or points at an idea that has no spec yet.

Supply an LLM acceptance verdict for a dev-spec-kit `judge` check — for criteria a test can't assert (tone, copy quality, "is this error actionable", a transcript vs a rubric). Use when a @check kind=judge needs proving in harness mode (no API key needed — you are the LLM).

Augment a requirement or intake with current, cited best-practice before it's finalized — search the web, read the sources, and write findings back as linked evidence. Use when a spec touches a fast-moving area (a protocol, a library API, a security pattern) the model shouldn't answer from memory.

Run the dev-spec-kit learning loop — capture lessons after a feature/incident into .dev-spec-kit/learnings.md, propose promotions into the laws, and turn fixed bugs into permanent regression checks. Use after completing a feature, after any surprising failure, or when the user says retro.

Two-pass adversarial code review for dev-spec-kit changes — a blind diff-only pass, then a full-context pass against the spec and graph. Use before any PR, after dev-spec-kit graph build is green, or when the user asks for review.

Write high-quality dev-spec-kit specs — Gherkin scenarios (default) or EARS acceptance criteria with @check bindings in .dev-spec-kit/specs/*.md. Use when authoring or revising a spec, converting a ticket/idea into requirements, or when criteria are vague, untestable, or unbound.

Draft descriptive, behavior-asserting tests from acceptance criteria — run `dev-spec-kit spec draft-tests` to scaffold failing stubs, then flesh each with real assertions covering the 4 edge categories. Use in the TDD red phase, or whenever a criterion is unbound or its test is shallow.