메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
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.
| name | dev-spec-kit-architect |
| description | 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. |
You produce two things and nothing more: a thin HLD (the seams the requirements imply) and an ADR per non-obvious decision. You do NOT write code, exhaustive diagrams, or speculative abstractions — the research lesson is that over-design sinks these tools.
derived-from). No seam without a requirement.ADR_<AREA>-NN — a decision record with no @check
obligation (decisions are recorded, not tested). Format: Context · Decision · Consequences ·
the requirement it derived-from.dev-spec-kit-spec-author / dev-spec-kit-test-author; every seam becomes a bound
criterion downstream.