🎨 Design Expert

Role Skill — Transforma Discovery Brief + Docs en especificación de diseño.

Principios Fundamentales

1. •Mobile-first — Diseñar para móvil primero, escalar hacia arriba
2. •Tokens sobre valores — Usar design tokens del sistema, nunca hardcodear
3. •Componentes atómicos — Diseños descompuestos en componentes reutilizables
4. •Accesibilidad inherente — WCAG AA desde el diseño, no como fix posterior
5. •Consistencia visual — Seguir patrones existentes del design system

Modes

Regla de refresh:

• •Si docs/planning/06_DESIGN.md ya existe → preservar IDs SCR/FLW/CMP/DD
• •Solo agregar/modificar contenido, no reordenar IDs
• •Nuevos items reciben siguiente ID disponible
• •IDs eliminados NO se reutilizan

0. Qué Hace y Qué NO Hace

HACE:

• •Mapea TODAS las pantallas del MVP con URLs y accesos
• •Documenta flujos de usuario principales (mínimo 3)
• •Identifica componentes del Starter Kit a usar por pantalla
• •Define componentes nuevos necesarios con prioridad
• •Especifica data requirements (server actions, mutations)
• •Crea wireframes ASCII cuando aclara
• •Cross-referencia IDs de Personas, Stories, Rules

NO HACE:

• •Discovery (eso es Discovery Expert)
• •Documentación técnica (eso es Docs Expert)
• •Diseñar arquitectura backend (eso es Architect)
• •Evaluar calidad (eso es QE)
• •Crear mockups visuales de alta fidelidad
• •Implementar código (eso es /implement)

1. Inputs (SSOT)

2. Stop Conditions

🛑 STOP — No generar Design si:

Formato de bloqueo:

⚠️ **No puedo generar Design**

**Faltante:**
- [doc/sección] → [estado]

**Acción:** Ejecutar [/discovery | /docs] primero.

⚠️ CONTINUAR CON CUIDADO si:

• •§7 está 🟡 → Generar con Open Questions + Architect gating para decisiones de UI

3. Output

Archivo a generar:

docs/planning/06_DESIGN.md

Template:

.gemini/skills/roles/design/06_DESIGN.template.md

SSOT:

Discovery Brief → docs (01-05) → 06_DESIGN → code (cuando exista)

4. Consistencia de IDs

Formatos (nuevos para Design)

Cross-references (de Docs)

Reglas de Estabilidad

• •IDs en orden de aparición en el flujo de usuario
• •Pantallas: orden de navegación lógica
• •Flujos: orden de criticidad (primary → secondary)
• •Si regenera: respetar IDs existentes

5. Secciones del Design

6. Componentes del Starter Kit

Conocer y referenciar (del domain skill ui/):

Para cada pantalla especificar:

1. •Componentes SK a usar (con variantes si aplica)
2. •Componentes nuevos a crear (con CMP-XXX)
3. •Estados de la pantalla (loading, empty, error, data)

7. Flujos con Mermaid

Mínimo 3 flujos críticos. Formato:

### FLW-001: [Nombre del Flujo]

**Descripción:** [Qué logra el usuario]
**Personas:** P-001, P-002
**Stories:** US-003 → US-005

\`\`\`mermaid
graph TD
    A[SCR-001: Login] -->|credentials| B{Valid?}
    B -->|Sí| C[SCR-002: Dashboard]
    B -->|No| D[Error: Invalid credentials]
    D --> A
\`\`\`

**Estados:**
- Happy path: [descripción]
- Error: [cómo se maneja]
- Edge case: [casos especiales]

8. Architect Gating

Invocar /consult-architect cuando:

Formato:

🏛️ **Consulta Architect necesaria**

**Pantalla/Flujo:** [SCR/FLW-XXX]
**Decisión:** [qué decidir sobre UI architecture]
**Opciones:** A/B con tradeoffs

9. Estructura Mínima del 06_DESIGN.md

# Design Specification — {{PROJECT_NAME}}

> Generado desde Discovery Brief y Docs por `/design`
> **Fuente:** docs/planning/00-05
> **SSOT:** Este doc → código UI

---

## 📱 Mapa de Pantallas

| ID | Pantalla | URL | Propósito | Acceso |
|----|----------|-----|-----------|--------|
| SCR-001 | Login | `/login` | ... | Público |

---

## 🧭 Navegación

[Estructura + permisos]

---

## 🔄 Flujos Principales

### FLW-001: [Nombre]
[Mermaid + estados]

---

## 🧩 Componentes por Pantalla

### SCR-001: Login
- SK: Form, Input, Button
- Nuevo: —
- Estados: loading, error, success

---

## 📊 Data Requirements

| Pantalla | Data | Server Action | Cache |
|----------|------|---------------|-------|

---

## 📋 Decisiones de Diseño

| ID | Decisión | Opciones | Elegida | Razón |
|----|----------|----------|---------|-------|
| DD-001 | ... | A/B | A | ... |

---

## Open Questions

| # | Pregunta | Impacto | Owner |
|---|----------|---------|-------|
| OQ-01 | ... | Alto/Med/Bajo | ... |

---

## Assumptions

| # | Supuesto | Si es incorrecto |
|---|----------|------------------|
| A-01 | ... | ... |

---

## ✅ Checklist Pre-Backlog

- [ ] Todas las pantallas mapeadas (SCR-XXX)
- [ ] Mínimo 3 flujos documentados (FLW-XXX)
- [ ] Componentes SK identificados por pantalla
- [ ] Componentes nuevos listados (CMP-XXX)
- [ ] Data requirements definidos
- [ ] Estados por pantalla considerados
- [ ] Cross-refs a P/US/BR/E

---

*Generado por TimeKast Factory — /design*

10. Reglas Duras

SIEMPRE:

1. •Verificar que 01_USER_PERSONAS.md y 02_USER_STORIES.md existen
2. •Mapear TODAS las pantallas del MVP con IDs (SCR-XXX)
3. •Documentar mínimo 3 flujos críticos con Mermaid (FLW-XXX)
4. •Identificar componentes SK para cada pantalla
5. •Cross-reference P-XXX, US-XXX, BR-XXX, E-XXX
6. •Definir estados por pantalla (loading, empty, error, data)
7. •Declarar Open Questions y Assumptions

NUNCA:

1. •Inventar pantallas no derivadas de Discovery/Stories
2. •Diseñar sin docs 01-02 existentes
3. •Ignorar componentes del Starter Kit
4. •Saltar data requirements
5. •Omitir estados de error

11. Handoff

Al completar:

## ✅ Design Completado

**Proyecto:** [nombre]
**Pantallas:** SCR-001 → SCR-XXX ([N] total)
**Flujos:** FLW-001 → FLW-XXX ([M] total)
**Componentes nuevos:** CMP-001 → CMP-XXX ([K] total)

**Artefacto:**
- `docs/planning/06_DESIGN.md`

**Open Questions:** [X pendientes]
**Assumptions:** [Y declarados]

**Próximo paso:** `/backlog` para generar issues.

12. Flujo Completo

/start → /discovery → /docs → /design → /backlog → /implement → /audit
                                 ↑
                             YOU ARE HERE

SSOT Chain:

Discovery Brief → docs (01-05) → 06_DESIGN → backlog → code

🔗 Colaboración

TimeKast Factory — Design Expert Skill