How do I install the Speckit.architecture skill?

Run npx skillmds@latest add wedabro/speckit-architecture 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 Speckit.architecture 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 Speckit.architecture?

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 Speckit.architecture free to use?

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

Who published Speckit.architecture?

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

Speckit.architecture by wedabro — Agent Skill

Name: Speckit.architecture
Author: wedabro

File contents

Mission

Turn product constraints into the simplest architecture that can meet them. Use this skill for significant technical decisions; use speckit.plan for the feature implementation plan, speckit.ddd for domain modeling, and specialist skills for security, data, frontend, backend, and DevOps decisions.

Protocol

0. Context Discovery

Establish users, critical journeys, data classification, scale/latency, availability, integration, compliance, team capability, budget, deployment, and migration constraints. Separate verified facts from assumptions.
Map current modules, ownership, dependencies, data flows, trust boundaries, failure modes, and operational signals before proposing a rewrite.

1. Option and Boundary Design

Start with the simplest viable option. Compare at least the baseline and alternatives against requirements, operational cost, consistency, security, latency, changeability, and team expertise.
Define module/service responsibilities, public contracts, data ownership, dependency direction, synchronous/asynchronous boundaries, and failure or retry behavior. Avoid distributed systems unless independently deployable ownership or a measured non-functional need justifies them.
Design security and reliability at boundaries: authentication/authorization, validation, rate limits, secret handling, timeouts, idempotency, observability, degradation, backup/recovery, and capacity assumptions.

2. Decision Records

Write an ADR before material, difficult-to-reverse choices. Include status, context, drivers, considered options, decision, consequences, risks, rollback/reversal path, implementation owner, and links to evidence.
Never rewrite an accepted ADR to hide a changed decision; create a superseding ADR and preserve the original rationale. Keep a searchable ADR index.

3. Validation and Handoff

Turn the chosen architecture into measurable quality attributes, explicit contracts, migration slices, test/load/DR gates, and operational runbooks.
Run a constitution check and threat/data/operability review. Record unknowns, rejected options, and decisions requiring user approval.
Hand approved boundaries to speckit.plan and atomic tasks; update mapping artifacts after significant implementation changes.

Outputs

Context diagram, module/service boundaries, interface/data-flow summary, ADRs, trade-off table, quality-attribute tests, and migration roadmap.

Guard Rails

Do not select technology from fashion, turn every module into a service, or hide cost/operational consequences.
Do not make irreversible architecture or data decisions without the required user approval and a documented reversal strategy.

---name: speckit-architecturedescription: Software Architect - Make evidence-based system design decisions, document trade-offs and ADRs, and define modular, reliable implementation boundaries.---## MissionTurn product constraints into the simplest architecture that can meet them.Use this skill for significant technical decisions; use `speckit.plan` for thefeature implementation plan, `speckit.ddd` for domain modeling, and specialistskills for security, data, frontend, backend, and DevOps decisions.## Protocol### 0. Context Discovery- Establish users, critical journeys, data classification, scale/latency, availability, integration, compliance, team capability, budget, deployment, and migration constraints. Separate verified facts from assumptions.- Map current modules, ownership, dependencies, data flows, trust boundaries, failure modes, and operational signals before proposing a rewrite.### 1. Option and Boundary Design- Start with the simplest viable option. Compare at least the baseline and alternatives against requirements, operational cost, consistency, security, latency, changeability, and team expertise.- Define module/service responsibilities, public contracts, data ownership, dependency direction, synchronous/asynchronous boundaries, and failure or retry behavior. Avoid distributed systems unless independently deployable ownership or a measured non-functional need justifies them.- Design security and reliability at boundaries: authentication/authorization, validation, rate limits, secret handling, timeouts, idempotency, observability, degradation, backup/recovery, and capacity assumptions.### 2. Decision Records- Write an ADR before material, difficult-to-reverse choices. Include status, context, drivers, considered options, decision, consequences, risks, rollback/reversal path, implementation owner, and links to evidence.- Never rewrite an accepted ADR to hide a changed decision; create a superseding ADR and preserve the original rationale. Keep a searchable ADR index.### 3. Validation and Handoff- Turn the chosen architecture into measurable quality attributes, explicit contracts, migration slices, test/load/DR gates, and operational runbooks.- Run a constitution check and threat/data/operability review. Record unknowns, rejected options, and decisions requiring user approval.- Hand approved boundaries to `speckit.plan` and atomic tasks; update mapping artifacts after significant implementation changes.## Outputs- Context diagram, module/service boundaries, interface/data-flow summary, ADRs, trade-off table, quality-attribute tests, and migration roadmap.## Guard Rails- Do not select technology from fashion, turn every module into a service, or hide cost/operational consequences.- Do not make irreversible architecture or data decisions without the required user approval and a documented reversal strategy.

Frequently asked questions

Speckit.architecture