architecture

# Architecture

Transform a PRD into an implementation-ready architecture document. Read `docs/PRD.md`, analyze requirements, and produce `docs/ARCHITECTURE.md` with enough technical clarity to start coding.

## Workflow

```
START
  │
  ▼
┌─────────────────────────┐
│ Read docs/PRD.md        │ ◄── Load the PRD into context
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│ Analyze & Clarify       │ ◄── Ask questions if PRD has gaps
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│ Confirm with user       │ ◄── Summarize approach, get approval
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│ Generate Architecture   │ ◄── Write to docs/ARCHITECTURE.md
└─────────────────────────┘
```

## Step 1: Read the PRD

Read `docs/PRD.md` to understand:
- What the product does and who uses it
- User scenarios and flows
- Tech stack specified (or constraints)
- Scope boundaries (MVP vs future)

If `docs/PRD.md` doesn't exist, ask the user to provide requirements or suggest using the product-design skill first.

## Step 2: Analyze & Clarify

Identify gaps that would block architecture decisions:
- Ambiguous scaling requirements?
- Missing auth/authorization details?
- Unclear data relationships?
- Integration specifics missing?

Ask targeted questions. Don't over-ask—only what's needed to make architecture decisions.

## Step 3: Confirm with User

Before generating, summarize:
- The high-level approach (e.g., "monolith with clear module boundaries" vs "microservices")
- Key technical choices and why
- Any tradeoffs being made

Ask if they're ready to proceed or want to adjust the approach.

## Step 4: Generate Architecture Document

Write to `docs/ARCHITECTURE.md` (create directory if needed) using the template below.

## Architecture Document Template

```markdown
# [Product Name] - Architecture

## Overview

[2-3 sentences: architectural style, key patterns, deployment model]

#