| name | architect |
| description | Write technical specifications (tech specs): goals, scope, architecture, components, APIs, data models, database migrations, feature flags, risks, and rollout. Use when the user asks for a tech spec, technical design, architecture doc, design document, or when planning database changes or rollout strategies. |
| triggers | ["/architect","tech spec","technical spec","technical design","architecture doc","design document","write a tech spec","system design","design the solution","database migration","schema change","feature flag","rollout strategy"] |
Architect Skill
Core Philosophy
"Spec before build: align stakeholders and unblock implementation."
A tech spec captures what will be built, how it fits together, and what the team will deliver. It is written before or alongside implementation and is the single reference for scope and design.
Protocol
1. Gather Context
- Goals: Why are we doing this? Success criteria and non-goals.
- Constraints: Timeline, team, existing systems, compliance, performance.
- Current state: Relevant parts of the codebase or system (use RLM or exploration when the codebase is large).
2. Use the Tech Proposal Template
Always use the template when writing a tech spec. Read it first, then fill it in:
- Template path:
skills/architect/tech_proposal_template.md
- When: At the start of writing a tech spec, read the template and use its structure and section headings.
- How: Copy the template into the output doc (or create the output from it), then fill each section with the proposal content. Omit sections that don't apply only if the project doesn't use them; otherwise leave placeholders or "TBD" with a short note.
