From 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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-spec-kit:dev-spec-kit-graphThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
dev-spec-kit's graph has two layers fused into one artifact:
dev-spec-kit's graph has two layers fused into one artifact:
graphify-out/graph.json (derived, gitignored)..dev-spec-kit/graph.json.The provider answers "what is the code?"; the overlay answers "what is proven about it?". Your job is to keep both fresh and to read the second one — never to hand-author either.
Two engines can feed the same graphify-out/graph.json contract, so the graph loop below is
identical no matter which is configured (via graphify.provider):
dev-spec-kit-revitify skill.dev-spec-kit-graphify skill.Picking or switching a provider is just a config change plus a rebuild; it never touches specs or proofs. Everything below is provider-agnostic.
dev-spec-kit init seeds the provider config (defaults to revitify) and gitignores the derived
output. Skip it on an already-initialized project.dev-spec-kit graph build is both create and update: it re-indexes the code graph when HEAD
has moved since the last index (freshness is tracked in .dev-spec-kit/graph-state.json), then
fuses specs + journal + code graph into .dev-spec-kit/graph.json. It is idempotent — run it as
often as you like. --no-refresh skips the re-index and only re-fuses.dev-spec-kit affected.source → requirement, derived from the code graph's test→source imports
and carrying that requirement's worst-of-chain proof. An implements edge is never greener than
the checks behind it; a widely-imported module links broadly by design (structural tie, not
line-coverage).implements edge, criteria with no green
validates edge. A live "what isn't provably built/tested yet?" list.dev-spec-kit drift.dev-spec-kit trace prints the full traceability table; dev-spec-kit status the summary.A proof's identity is the working-tree content hash minus .dev-spec-kit/. So ANY code or doc
change after a proof turns that proof stale. To get back to green:
dev-spec-kit verify --stamp — re-run the suites and stamp fresh proofs.dev-spec-kit graph build — re-fuse and confirm green..dev-spec-kit/ state.State-only commits do not re-stale (they are excluded from the hash), so the dance terminates.
You MUST NOT hand-edit .dev-spec-kit/graph.json, .dev-spec-kit/graph-state.json, or
graphify-out/ to force green — they are derived; regenerate them. NEVER fake a proof: a green graph
built on an unexecuted check defeats the entire tool.
dev-spec-kit graph build after any code change that could move a proof.graphify-out/ — it is gitignored, derived, and regenerated from code.dev-spec-kit-revitify / dev-spec-kit-graphify; this skill stays
agnostic — never hard-code one provider's mechanics into the graph loop.Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub pratiyush/dev-spec-kit