---
description: Create technical design for a specification
allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update
argument-hint: <feature-name> [-y]
---

# Technical Design Generator

<instructions>
## Core Task
Produce a concise, implementation-ready technical design for feature **$1**.

**HARD LIMIT: design.md must be 150–200 lines maximum. Stop writing when you reach 200 lines.**

## Steps

### 1. Load Context
- Read `{{SDD_DIR}}/specs/$1/spec.json` (language + approval state)
- Read `{{SDD_DIR}}/specs/$1/requirements.md`
- Read `{{SDD_DIR}}/specs/$1/design.md` if it already exists (merge, don't discard)
- Read `{{SDD_DIR}}/steering/` directory (product.md, tech.md, structure.md + any custom files)
- Do NOT read design templates or design-principles files — use the structure below

**Approval gate**:
- If `-y` ($2 == "-y"): mark requirements approved in spec.json, continue
- Otherwise: halt if `approvals.requirements.approved` is false

### 2. Quick Discovery (local files only)
Use Grep to find: existing patterns, relevant services/routes, naming conventions, data models.
Do NOT use WebSearch or WebFetch. Keep this step under 5 file reads.

### 3. Write design.md — Exact Structure

Write the file to `{{SDD_DIR}}/specs/$1/design.md` using EXACTLY this structure. Do not add extra sections.

```
# Design: {featureName}

## Visão Geral
{2–3 sentences: what this builds, who uses it, how it fits the existing system}

## Arquitetura

```mermaid
graph LR
  {components and connections — max 15 nodes}
```

**Decisões:**
- {architectural decision 1}
- {architectural decision 2}
- {architectural decision 3 max}

## Componentes

| Componente | Camada | Responsabilidade | Requisitos |
|---|---|---|---|
| {name} | {layer} | {one line} | {req IDs} |

{For each NEW endpoint or external boundary only — skip for pass-through components:}

### {ComponentName}
**Interface:**
```js
{key type definitions or function signatures — 5–15 lines max}
```
**Endpoint:** `{METHOD} {/api/path}` → `{request body}` → `{response shape}`

## Modelos de Dados
```js
{key data types only — 10–20 lines max}
```

## Tratamento de Erros
- {scenario}: {response}
- {scenario}: {response}
```

Rules for content:
- ONE mermaid diagram maximum
- Components table: ALL components summarized in the table; only new boundaries get a detail block
- NO testing strategy section
- NO migration section
- NO security section (unless the feature handles auth or sensitive data)
- NO performance section (unless there is an explicit latency target in requirements)
- NO traceability matrix
- Each detail block: max 20 lines including code fence

### 4. Update spec.json
Set: `phase: "design-generated"`, `approvals.design.generated: true`, `approvals.design.approved: false`, `approvals.requirements.approved: true`, refresh `updated_at`.

### 5. Write research.md (optional, brief)
Only if meaningful findings from step 2 — max 30 lines. Skip if discovery was trivial.
</instructions>

## Output Description
Respond in the language from spec.json, under 100 words:
1. Confirm design.md line count and path
2. Confirm spec.json updated
3. State design is ready for review via SDD-FP interface — do NOT list CLI commands

## Safety & Fallback

**Requirements Not Approved**: Halt. Message: "Requirements not approved. Use `-y` to auto-approve."
**Requirements Missing**: Halt. Message: "Run spec-requirements first."
**Steering Absent**: Continue with warning.
**Non-Numeric Req IDs**: Halt and ask user to fix requirements.md.

**Next phase**: User proceeds via SDD-FP graphical interface — do NOT output CLI commands.
