How do I install the Dev Spec Kit Architect skill?

Run npx skillmds@latest add pratiyush/dev-spec-kit-architect in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dev Spec Kit Architect safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dev Spec Kit Architect?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dev Spec Kit Architect free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Dev Spec Kit Architect?

pratiyush (@pratiyush) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dev Spec Kit Architect by pratiyush

Name: Dev Spec Kit Architect
Author: pratiyush

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.

pratiyush 50da3ed 1.9 KB Updated Sep 17, 2026

File contents

dev-spec-kit architect — design just enough, record the why

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.

HLD (one short doc)

The components/seams the requirements force, and the data that crosses them.
For each seam, the one requirement it serves (derived-from). No seam without a requirement.
Reuse first: before proposing a new component, check the code graph / existing specs for one that already does the job (Böckeler's "regenerated existing classes as duplicates" is the failure).

ADRs (a record, not a unit test)

Emit an ADR only for a decision a reasonable engineer could disagree with (a tradeoff, a library choice, a boundary). Skip the obvious.
Each ADR is a first-class spec node id ADR_<AREA>-NN — a decision record with no @check obligation (decisions are recorded, not tested). Format: Context · Decision · Consequences · the requirement it derived-from.
An ADR MUST state the alternative considered and why it lost — a decision with no rejected option isn't a decision.

Rules (RFC-2119)

You MUST NOT introduce a component, layer, or dependency no requirement asks for; flag scope creep rather than build it.
Architectural conflicts (two designs claiming the same seam incompatibly) MUST be surfaced, not silently merged.
Hand the seams + ADRs to dev-spec-kit-spec-author / dev-spec-kit-test-author; every seam becomes a bound criterion downstream.

---name: dev-spec-kit-architectdescription: 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 architect — design just enough, record the *why*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 speculativeabstractions — the research lesson is that over-design sinks these tools.## HLD (one short doc)- The components/seams the requirements force, and the data that crosses them.- For each seam, the one requirement it serves (`derived-from`). No seam without a requirement.- **Reuse first:** before proposing a new component, check the code graph / existing specs for one that already does the job (Böckeler's "regenerated existing classes as duplicates" is the failure).## ADRs (a record, not a unit test)- Emit an ADR **only** for a decision a reasonable engineer could disagree with (a tradeoff, a library choice, a boundary). Skip the obvious.- Each ADR is a first-class spec node id `ADR_<AREA>-NN` — a decision record with **no @check obligation** (decisions are recorded, not tested). Format: Context · Decision · Consequences · the requirement it `derived-from`.- An ADR MUST state the alternative considered and why it lost — a decision with no rejected option isn't a decision.## Rules (RFC-2119)- You MUST NOT introduce a component, layer, or dependency no requirement asks for; flag scope creep rather than build it.- Architectural conflicts (two designs claiming the same seam incompatibly) MUST be surfaced, not silently merged.- Hand the seams + ADRs to `dev-spec-kit-spec-author` / `dev-spec-kit-test-author`; every seam becomes a bound criterion downstream.

Frequently asked questions