dev-spec-kit

Plugin dev-spec-kit in Pratiyush/dev-spec-kit. Commands read from the repo's manifest — 1 month ago.

Skills (15)

• dev-spec-kit-analyze

  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.

• dev-spec-kit-architect

  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.

• dev-spec-kit-clarify

  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.

• dev-spec-kit-finish

  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-spe

• dev-spec-kit-graph

  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 engi

• dev-spec-kit-graphify

  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 verifi

• dev-spec-kit-intake

  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.

• dev-spec-kit-judge

  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).

• dev-spec-kit-research

  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.

• dev-spec-kit-retro

  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.

• dev-spec-kit-review

  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.

• dev-spec-kit-revitify

  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 Veri

• dev-spec-kit-spec-author

  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.

• dev-spec-kit-test-author

  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.

• dev-spec-kit-workflow

  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

Slash commands (1)

• /dev-spec-kit:dev-spec-kit

  Run the dev-spec-kit spec-driven loop on a request — route, spec (EARS), evidence-bound tasks, TDD, proofs, graph, approval, PR.

Hooks (5)

• PreCompact

  node "${CLAUDE_PLUGIN_ROOT}/hooks/resume-save.mjs"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/guard-pr.mjs"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/guard-protect.mjs"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/hooks/guard-facts.mjs"

• Stop

  node "${CLAUDE_PLUGIN_ROOT}/hooks/guard-lint.mjs"