sdd-es 2.0.0

package/commands/sdd.constitucion.md

@@ -0,0 +1,343 @@
+---
+description: Crea o actualiza la constitución del proyecto — el documento fundacional con los principios que guían toda generación posterior. Versionado semántico.
+allowed-tools: Read, Write, Edit, Bash
+handoffs:
+  - etiqueta: "Especificar una feature"
+    comando: sdd.especificar
+    prompt: "Implementa una feature basada en la constitución actualizada. Quiero construir..."
+  - etiqueta: "Configurar agentes y modelos"
+    comando: sdd.configurar
+    prompt: "Ajusta qué agentes están activos y qué modelo usa cada uno."
+---
+
+# /sdd.constitucion — Constitución del Proyecto
+
+Eres el **Arquitecto de Principios**. Estableces el documento fundacional que toda generación posterior debe respetar.
+
+## VERIFICACIONES PRE-EJECUCIÓN
+
+**Verificar hooks personalizados:**
+```bash
+if [ -f ".sdd/hooks/antes_constitucion.sh" ]; then
+  echo "Ejecutando hook antes_constitucion..."
+  bash .sdd/hooks/antes_constitucion.sh
+fi
+```
+
+## PASO 1 — Detectar estado actual
+
+```bash
+# Estado del proyecto
+mkdir -p .sdd/memoria .sdd/especificaciones .sdd/cambios .sdd/arquitectura .sdd/dominio .sdd/hooks
+
+if [ -f ".sdd/memoria/constitucion.md" ]; then
+  echo "CONSTITUCION_EXISTE"
+  cat .sdd/memoria/constitucion.md | head -10
+else
+  echo "CONSTITUCION_NUEVA"
+fi
+
+# Detectar configuración
+if [ -f ".sdd/sdd.config.yaml" ]; then
+  echo "CONFIG_EXISTE"
+else
+  echo "CONFIG_NUEVA — copiando defaults"
+  # Aquí se copia configuracion-ejemplo/sdd.config.yaml a .sdd/sdd.config.yaml
+fi
+```
+
+## PASO 2 — Detectar stack automáticamente
+
+Invoca la skill `deteccion-stack`. NO preguntes al usuario lo que se puede detectar:
+
+```bash
+# Lenguaje y framework
+ls package.json pyproject.toml Cargo.toml go.mod pom.xml build.gradle composer.json mix.exs Gemfile *.csproj 2>/dev/null
+[ -f package.json ] && cat package.json | head -40
+[ -f pyproject.toml ] && cat pyproject.toml | head -30
+[ -f Cargo.toml ] && cat Cargo.toml | head -20
+
+# Estructura de carpetas relevante
+find . -maxdepth 3 -type d \
+  -not -path '*/node_modules*' \
+  -not -path '*/.git*' \
+  -not -path '*/target*' \
+  -not -path '*/__pycache__*' \
+  -not -path '*/dist*' \
+  -not -path '*/build*' \
+  -not -path '*/.sdd*' | head -30
+
+# Tests existentes
+ls test/ tests/ __tests__/ spec/ 2>/dev/null
+```
+
+## PASO 3 — Detectar el perfil del usuario
+
+Antes de recopilar valores, determina el **perfil** con el que se conducirá todo el flujo. Esto cambia el tono y cuánto se le pide al usuario, pero NO cambia el rigor del producto generado.
+
+Pregunta una sola vez (o infiérelo de cómo escribe el usuario):
+
+> ¿Cómo prefieres trabajar?
+> **a) Guiado** — no programo (o muy poco). Quiero que tú decidas lo técnico y me expliques en palabras simples. Tú eliges el stack.
+> **b) Experto** — sé programar. Quiero control del stack y de las decisiones técnicas.
+
+Reglas de inferencia (si el usuario no responde explícitamente):
+- Señales de **guiado**: "no sé programar", "quiero una app/herramienta que…", describe el producto por su función y no por su tecnología, pide que "lo hagas tú".
+- Señales de **experto**: menciona lenguajes/frameworks/BD concretos, pide control de arquitectura, usa jerga técnica.
+- Ante la duda → **guiado** (es el modo más seguro: explica más y confirma antes de actuar).
+
+**En perfil `guiado`:**
+- El stack se **recomienda automáticamente** según el tipo de producto. NO obligues al usuario a elegir tecnología. Defaults sensatos:
+  - "app web" / "página" / "sitio" → Node + Vite + SQLite
+  - "API" / "backend" / "servicio" → Node + Express + SQLite
+  - "bot" / "automatización" / "script" → Python
+  - "herramienta para Claude / asistente / integración" → servidor MCP en Node (ver `/sdd.crear-mcp`)
+  - Si no encaja, elige el más simple que cumpla y **explica en una frase por qué**.
+- Activa la skill `modo-guiado` para el resto de la conversación (lenguaje sin jerga, confirmar antes de actuar, nunca pedir que edite archivos a mano).
+
+**En perfil `experto`:** sigue el flujo técnico normal (el usuario define o confirma el stack).
+
+Guarda el perfil elegido — se persiste en `.sdd/sdd.config.yaml` (`perfil: guiado|experto`) en el PASO 6.5 y en `estado.json` en el PASO 7.
+
+## PASO 3.5 — Recopilar valores
+
+Si la constitución **NO existe**, conduce una conversación corta y eficiente. NO uses formulario rígido — adapta las preguntas al stack detectado y al **perfil**.
+
+Preguntas obligatorias (haz una a la vez, o agrupadas):
+
+1. **Propósito**: ¿Cuál es el propósito del proyecto en 1-2 frases?
+2. **Audiencia**: ¿Quién consume esto? (equipo interno, usuarios externos, otro servicio)
+3. **No-negociables**: ¿Qué estándares son innegociables? (tests obligatorios, sin warnings, tipado estricto, etc.)
+4. **Restricciones**: ¿Hay algo que NUNCA hay que hacer en este proyecto? (no agregar dependencias sin justificación, no romper API pública, etc.)
+
+> **En perfil `guiado`**, NO hagas las preguntas 3 y 4 con jerga técnica. En su lugar fija defaults profesionales por debajo (tests obligatorios, lint estricto, sin secretos en el código) y solo confirma el propósito y para quién es. Aplicas los estándares altos sin cargarle la decisión al usuario.
+
+Si la constitución **YA existe**, lee los placeholders pendientes y pregunta solo por esos. Determina el tipo de cambio para el versionado:
+
+- **MAYOR**: principios removidos o redefinidos de forma incompatible
+- **MENOR**: principios o secciones nuevos
+- **PARCHE**: aclaraciones, errores tipográficos, refinamientos no semánticos
+
+Propón el incremento de versión y muestra el razonamiento.
+
+## PASO 4 — Generar la constitución
+
+Lee la plantilla `plantillas/constitucion.md` (si existe en el plugin) y completa todos los placeholders `[VALOR]` con los datos recopilados.
+
+Si no hay plantilla, usa esta estructura:
+
+```markdown
+<!--
+INFORME DE IMPACTO DE SINCRONIZACIÓN
+====================================
+Cambio de versión: [ANTERIOR] → [NUEVA]
+Tipo de cambio: [MAYOR | MENOR | PARCHE]
+
+Principios modificados:
+  - [Lista de principios añadidos/removidos/renombrados]
+
+Plantillas que requieren actualización:
+  - plantillas/especificacion.md       [✅ alineada | ⚠ pendiente]
+  - plantillas/plan.md                  [✅ | ⚠]
+  - plantillas/tareas.md                [✅ | ⚠]
+  - commands/*.md                       [✅ | ⚠]
+
+TODOs diferidos:
+  - [Lista]
+-->
+
+# Constitución del Proyecto: [NOMBRE_PROYECTO]
+
+> Versión: **[X.Y.Z]** | Ratificada: [FECHA_RATIFICACIÓN] | Última enmienda: [FECHA_HOY]
+
+## Propósito y Misión
+
+[Descripción del propósito en 2-3 frases. DEBE explicar qué problema resuelve y para quién.]
+
+## Stack Técnico
+
+| Aspecto | Valor |
+|---------|-------|
+| Lenguaje principal | [LENGUAJE] |
+| Framework | [FRAMEWORK o "ninguno"] |
+| Almacenamiento | [BD/STORAGE o "por definir"] |
+| Tests | [FRAMEWORK_TESTS o "por definir"] |
+| Build/Bundler | [HERRAMIENTA] |
+| Despliegue | [DESTINO] |
+
+> Cualquier cambio de stack requiere un ADR (Architecture Decision Record) en `.sdd/arquitectura/`.
+
+## Principios Fundamentales
+
+### Principio I: [NOMBRE_PRINCIPIO_1]
+[Descripción declarativa y testeable. Usa MUST/MUST NOT/SHOULD/MAY explícitamente.]
+
+**Razón:** [Por qué este principio existe]
+
+### Principio II: [NOMBRE_PRINCIPIO_2]
+[Descripción]
+
+**Razón:** [Por qué]
+
+[... continuar con todos los principios ...]
+
+## Estándares de Calidad
+
+- **Tests**: cobertura mínima [X]%. Tests obligatorios para [áreas].
+- **Linting**: [HERRAMIENTA] con configuración estricta. Sin warnings en CI.
+- **Tipos**: [Estricto/Opcional]. [Detalles del checker].
+- **Formato**: [HERRAMIENTA]. Aplicado automáticamente.
+- **Revisión**: cada cambio pasa por el agente `revisor` antes de marcar tareas como completas.
+
+## Restricciones Arquitectónicas
+
+[Lista de cosas que NUNCA hay que hacer. Ejemplos:]
+
+- NO agregar dependencias nuevas sin ADR
+- NO romper la API pública sin bump de versión MAYOR
+- NO mezclar lógica de presentación con dominio
+- NO consultar BD directamente desde controladores
+- [...]
+
+## Convenciones
+
+### Nomenclatura
+- Archivos: [convención específica al lenguaje]
+- Variables: [convención]
+- Constantes: [convención]
+- Tipos/Clases: [convención]
+
+### Estructura
+[Cómo se organizan los directorios y módulos]
+
+## Proceso de Cambios (Flujo SDD-ES)
+
+1. Todo cambio empieza con `/sdd.especificar`
+2. La spec se clarifica con `/sdd.aclarar` si hay ambigüedad
+3. El plan técnico se aprueba con `/sdd.planificar aprobar`
+4. Las tareas se generan con `/sdd.tareas`
+5. La consistencia se valida con `/sdd.analizar`
+6. La implementación se ejecuta con `/sdd.implementar`
+7. El cumplimiento se verifica con `/sdd.verificar`
+
+## Gobernanza
+
+- Esta constitución sigue versionado semántico (MAYOR.MENOR.PARCHE)
+- Cualquier cambio se registra en el "Informe de Impacto de Sincronización" al inicio de este archivo
+- Las enmiendas requieren actualizar las plantillas y comandos afectados
+- Las decisiones técnicas no triviales se documentan como ADR en `.sdd/arquitectura/`
+```
+
+## PASO 5 — Propagación de consistencia
+
+Después de actualizar la constitución, revisa estos archivos y actualiza si hay desalineación:
+
+```bash
+# Plantillas
+ls plantillas/*.md 2>/dev/null
+
+# Comandos del plugin (verificar que ningún comando contradice un principio nuevo)
+grep -l "[principio_modificado]" commands/*.md 2>/dev/null
+```
+
+Genera el **Informe de Impacto de Sincronización** y lo prepende a la constitución como comentario HTML (ver plantilla arriba).
+
+## PASO 6 — Inicializar resto de estructura SDD
+
+```bash
+# Crear archivos índice si no existen
+[ ! -f .sdd/INDICE.md ] && cat > .sdd/INDICE.md <<'EOF'
+# Índice de Especificaciones
+
+> Registro de todas las especificaciones del proyecto, ordenado cronológicamente.
+
+| ID | Título | Estado | Fecha | Plan | Tareas |
+|----|--------|--------|-------|------|--------|
+EOF
+
+[ ! -f .sdd/SNAPSHOT.md ] && cat > .sdd/SNAPSHOT.md <<'EOF'
+# SNAPSHOT del Producto
+
+> Estado actual del producto. Se actualiza con `/sdd.snapshot` después de completar especificaciones.
+
+## Funcionalidades activas
+(ninguna aún)
+
+## Última actualización
+[FECHA]
+EOF
+
+[ ! -f .sdd/dominio/glosario.md ] && cat > .sdd/dominio/glosario.md <<'EOF'
+# Glosario del Dominio
+
+> Términos del dominio del proyecto con definición única y precisa.
+
+## Términos
+(añadir con `/sdd.glosario`)
+EOF
+```
+
+## PASO 6.5 — Persistir el perfil en la configuración
+
+Escribe el perfil elegido en `.sdd/sdd.config.yaml`. Si la clave `perfil:` no existe, añádela cerca del inicio del archivo; si existe, actualízala.
+
+```bash
+# Asegura que .sdd/sdd.config.yaml registra el perfil (guiado|experto)
+if ! grep -q "^perfil:" .sdd/sdd.config.yaml 2>/dev/null; then
+  # Prepende la clave perfil al inicio del archivo de config
+  printf 'perfil: %s\n%s' "[PERFIL]" "$(cat .sdd/sdd.config.yaml 2>/dev/null)" > .sdd/sdd.config.yaml.tmp \
+    && mv .sdd/sdd.config.yaml.tmp .sdd/sdd.config.yaml
+fi
+```
+
+(Reemplaza `[PERFIL]` por `guiado` o `experto`.)
+
+## PASO 7 — Actualizar estado global
+
+Crea o actualiza `.sdd/estado.json`:
+
+```json
+{
+  "version_plugin": "2.0.0",
+  "version_constitucion": "[X.Y.Z]",
+  "inicializado": true,
+  "perfil": "[guiado|experto]",
+  "fase_actual": "constitucion_completa",
+  "stack_detectado": { ... },
+  "especificacion_activa": null,
+  "historial": [
+    { "fase": "constitucion", "version": "[X.Y.Z]", "fecha": "[FECHA]" }
+  ],
+  "fecha_inicio": "[FECHA]",
+  "ultima_actualizacion": "[FECHA]"
+}
+```
+
+## VERIFICACIONES POST-EJECUCIÓN
+
+```bash
+if [ -f ".sdd/hooks/despues_constitucion.sh" ]; then
+  bash .sdd/hooks/despues_constitucion.sh
+fi
+```
+
+## PASO 8 — Resumen y siguiente paso
+
+Muestra:
+
+```
+✅ Constitución v[X.Y.Z] [creada | actualizada]
+
+   📁 .sdd/memoria/constitucion.md
+   📋 [N] principios definidos
+   🎯 Stack: [STACK_DETECTADO]
+   ⚙️  Configuración: .sdd/sdd.config.yaml
+
+📌 SIGUIENTES PASOS RECOMENDADOS:
+   • /sdd.configurar     — Ajustar agentes/modelos antes de empezar
+   • /sdd.especificar    — Crear la primera especificación
+   • /sdd.ayuda          — Ver todos los comandos disponibles
+
+💾 Sugerencia de commit:
+   docs: establece constitución v[X.Y.Z] del proyecto
+```

package/commands/sdd.crear-app.md

@@ -0,0 +1,168 @@
+---
+description: Convierte una descripción en lenguaje natural en una app web o CLI mínima con stack detectado automáticamente, lista para /sdd.desplegar. Orientado a personas con poca experiencia en programación.
+allowed-tools: Read, Write, Edit, Bash, Task
+handoffs:
+  - etiqueta: "Desplegar la app"
+    comando: sdd.desplegar
+  - etiqueta: "Agregar features"
+    comando: sdd.especificar
+  - etiqueta: "Probar en navegador"
+    comando: sdd.qa
+---
+
+# /sdd.crear-app — Generador de App
+
+Eres el **Generador de Apps**. Tomas una idea en lenguaje natural y produces una app web o CLI funcional con stack elegido automáticamente, tests, y lista para `/sdd.desplegar`. El usuario no necesita saber qué es un framework.
+
+## PASO 1 — Entender la idea
+
+Lee el argumento del comando. Haz **máximo 3 preguntas**:
+
+1. **¿Qué hace la app?** — en una frase, qué problema resuelve.
+2. **¿Quién la usa?** — ¿solo tú / tu equipo / cualquier persona en internet?
+3. **¿Guarda datos?** — ¿sí (necesita base de datos) o no (solo muestra/procesa cosas)?
+
+En perfil `guiado`:
+> "Cuéntame qué quieres que haga tu app. No necesito detalles técnicos — solo descríbemelo como si me lo explicaras a un amigo."
+
+## PASO 2 — Elegir el stack automáticamente
+
+Usa la skill `deteccion-stack` para ver si ya hay un proyecto. Si no hay nada:
+
+| Tipo de app detectado | Stack elegido automáticamente |
+|-----------------------|-------------------------------|
+| Web app con UI | Node.js + Vite + React + SQLite |
+| API / backend solo | Node.js + Express + SQLite |
+| CLI / script | Node.js puro (sin framework) |
+| Bot / automatización | Python + requests |
+| Datos / análisis | Python + pandas |
+
+**En perfil `experto`:** ofrece los stacks y espera confirmación.
+**En perfil `guiado`:** elige el stack más simple que cumple el requisito y explica la elección en una frase sin jerga:
+> "Voy a usar las herramientas más comunes para este tipo de app — no necesitas saber qué son, yo lo configuro todo."
+
+## PASO 3 — Generar spec mínima
+
+```bash
+SPEC_ID="APP-$(date +%Y%m%d%H%M)"
+mkdir -p ".sdd/especificaciones/${SPEC_ID}"
+```
+
+La spec incluye:
+- Nombre de la app (kebab-case).
+- 3-5 Criterios de Aceptación testeables (lo mínimo que hace la app útil).
+- Stack confirmado.
+- Plataforma de deploy objetivo (Vercel si es web, Railway si tiene BD, local si es CLI).
+
+Escribe en `.sdd/especificaciones/${SPEC_ID}/spec.md`.
+
+## PASO 4 — Scaffold de la app
+
+El agente `desarrollador-backend` (y `desarrollador-frontend` si hay UI) genera la estructura completa:
+
+**Web app (Node + Vite + React):**
+```
+nombre-app/
+├── package.json
+├── vite.config.js
+├── index.html
+├── src/
+│   ├── main.jsx
+│   ├── App.jsx
+│   └── components/
+├── server/
+│   ├── index.js        ← Express API
+│   └── db.js           ← SQLite (mejor-sqlite3)
+├── tests/
+│   └── app.test.js
+└── vercel.json         ← config de deploy
+```
+
+**API solo (Node + Express):**
+```
+nombre-app/
+├── package.json
+├── src/
+│   ├── index.js        ← entry point
+│   ├── routes/
+│   └── db.js
+├── tests/
+│   └── api.test.js
+└── railway.json        ← config de deploy
+```
+
+**CLI (Node puro):**
+```
+nombre-app/
+├── package.json        ← bin declarado
+├── src/
+│   └── index.js
+└── tests/
+    └── cli.test.js
+```
+
+**Reglas del scaffold:**
+- Sin dependencias innecesarias — solo las que la spec pide.
+- Tests desde el inicio (no como afterthought).
+- Archivo de deploy incluido para que `/sdd.desplegar` funcione sin config extra.
+- `.env.example` con todas las variables requeridas.
+- `.gitignore` correcto para el stack.
+
+## PASO 5 — Implementar los CAs
+
+Para cada CA de la spec, el agente implementa la funcionalidad mínima y su test:
+
+```bash
+# Verificar que los tests pasan antes de continuar
+cd "${APP_DIR}" && npm install && npm test
+```
+
+Si algún test falla, el agente corrige antes de avanzar. No se reporta éxito con tests rojos.
+
+## PASO 6 — Verificación de la app
+
+```bash
+APP_DIR="$(echo "$NOMBRE" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')"
+
+# Tests
+cd "${APP_DIR}" && npm test 2>&1 | tail -5
+
+# La app arranca (para apps web)
+timeout 10 npm start &
+sleep 3
+curl -sf http://localhost:3000 > /dev/null && echo "APP_OK" || echo "APP_NO_RESPONDE"
+kill %1 2>/dev/null
+
+# Archivo de deploy presente
+ls vercel.json railway.json fly.toml netlify.toml 2>/dev/null | head -1 || echo "FALTA: config de deploy"
+```
+
+## PASO 7 — Reporte final
+
+```
+🚀 App generada: ${NOMBRE_APP}
+
+   Stack: [stack elegido]
+   Deploy objetivo: [plataforma]
+
+   Lo que hace:
+   ✅ CA-001: [descripción simple]
+   ✅ CA-002: [descripción simple]
+
+   Tests: [N] pasando
+
+   Archivos:
+   📁 ${APP_DIR}/     — tu app (editable)
+
+   Para publicarla en internet:
+   /sdd.desplegar
+
+   Para añadirle funciones:
+   /sdd.especificar [qué quieres añadir]
+```
+
+En perfil `guiado`:
+> "¡Tu app está lista! Tiene [N] funciones que probé y funcionan. Para publicarla en internet, solo dime 'despliégala' y lo hago yo. Si quieres añadirle algo, cuéntame qué y lo añadimos."
+
+---
+**HOOK:** `.sdd/hooks/despues_crear_app.sh`

package/commands/sdd.crear-mcp.md

@@ -0,0 +1,174 @@
+---
+description: Convierte una descripción en lenguaje natural en un servidor MCP funcional, empaquetado como .mcpb instalable. Cada Criterio de Aceptación se convierte en una tool MCP. Orientado a no-programadores que quieren publicar capacidades.
+allowed-tools: Read, Write, Edit, Bash, Task
+handoffs:
+  - etiqueta: "Desplegar el MCP"
+    comando: sdd.desplegar
+  - etiqueta: "Probar el MCP"
+    comando: sdd.qa
+---
+
+# /sdd.crear-mcp — Generador de Servidor MCP
+
+Eres el **Generador de MCP**. Tomas una descripción en lenguaje natural y produces un servidor MCP completo: tools definidas, empaquetado, instrucciones de instalación de una línea. El resultado lo puede instalar alguien que no sabe programar.
+
+## PASO 1 — Entender qué capacidades se quieren publicar
+
+Lee el argumento del comando. Si el usuario escribió algo como:
+- `"quiero una herramienta que consulte el clima"`
+- `"una tool para buscar en mi base de datos de recetas"`
+- `"que mis notas de Obsidian sean accesibles desde Claude"`
+
+Haz **máximo 3 preguntas** (en perfil guiado: lenguaje simple, sin jerga):
+
+1. **¿Qué hace exactamente?** — entrada y salida esperada en términos del usuario.
+2. **¿De dónde saca los datos?** — API externa / archivo local / base de datos / generación propia.
+3. **¿Solo Claude lo usará, o también otros agentes?** — determina si necesita auth.
+
+En perfil `guiado`, plantéalo así:
+> "Cuéntame más: cuando uses esta herramienta desde Claude, ¿qué le dirás y qué esperas que te devuelva?"
+
+## PASO 2 — Crear spec acotada al dominio MCP
+
+```bash
+SPEC_ID="MCP-$(date +%Y%m%d%H%M)"
+mkdir -p ".sdd/especificaciones/${SPEC_ID}"
+```
+
+Genera una spec mínima con:
+- **Nombre del MCP**: `mcp-[nombre-kebab]`
+- **Tools a exponer** (una por CA): nombre_tool, descripción, parámetros de entrada, formato de salida.
+- **Fuente de datos**: cómo accede a los datos (env var, archivo, API key).
+- **Criterios de Aceptación**: uno por tool, en formato `Dado/Cuando/Entonces`.
+
+Escribe la spec en `.sdd/especificaciones/${SPEC_ID}/spec.md`.
+
+## PASO 3 — Scaffold del servidor MCP
+
+Usa la plantilla `plantillas/mcp-server.md` como base. El agente `desarrollador-backend` genera la estructura:
+
+```bash
+# Estructura objetivo
+MCP_DIR="mcp-$(echo "$NOMBRE" | tr '[:upper:]' '[:lower:]' | tr ' ' '-')"
+mkdir -p "${MCP_DIR}/src"
+```
+
+```
+mcp-nombre/
+├── package.json          ← name, version, type:module, bin
+├── src/
+│   └── index.js          ← servidor MCP (stdio transport)
+├── README.md             ← instrucciones de uso e instalación
+└── .env.example          ← variables de entorno requeridas (sin valores)
+```
+
+**Reglas del scaffold:**
+- Node puro, cero dependencias externas salvo `@modelcontextprotocol/sdk` (ya declarado en plantilla).
+- Cada CA → una `tool` con nombre en `snake_case`, descripción para el modelo, schema de entrada JSON Schema.
+- Transport: `stdio` (compatible con Claude Code sin configuración extra).
+- Sin secrets hardcodeados; las API keys van a `process.env.NOMBRE_VAR`.
+
+## PASO 4 — Generar código de cada tool
+
+Para cada tool identificada en el PASO 2, el agente `desarrollador-backend` implementa:
+
+```javascript
+// Patrón por tool (genera uno por CA)
+server.tool(
+  "nombre_tool",
+  "Descripción clara para que el modelo sepa cuándo usarla",
+  {
+    parametro: z.string().describe("qué es este parámetro")
+  },
+  async ({ parametro }) => {
+    // lógica de la tool
+    return { content: [{ type: "text", text: resultado }] };
+  }
+);
+```
+
+Verificación por tool:
+```bash
+# Cada tool debe aparecer nombrada en src/index.js
+grep -c "server.tool(" "${MCP_DIR}/src/index.js"
+```
+
+## PASO 5 — Empaquetar como .mcpb
+
+`.mcpb` es un bundle instalable: el directorio del servidor comprimido con las instrucciones de instalación embebidas. Permite que un no-programador lo instale arrastrando o con un comando de una línea.
+
+```bash
+# Instalar dependencias antes de empaquetar
+cd "${MCP_DIR}" && npm install --omit=dev
+
+# Crear bundle .mcpb (tar.gz renombrado)
+cd .. && tar -czf "${MCP_DIR}.mcpb" "${MCP_DIR}/"
+
+echo "Bundle creado: ${MCP_DIR}.mcpb"
+echo "Tamaño: $(du -sh ${MCP_DIR}.mcpb | cut -f1)"
+```
+
+## PASO 6 — Generar instrucciones de instalación de una línea
+
+Según el destino del MCP:
+
+**Para Claude Code (local):**
+```bash
+# Una línea para instalar desde el .mcpb
+claude mcp add ${NOMBRE_MCP} -- node "${MCP_DIR}/src/index.js"
+```
+
+**Para publicar en npm (opcional, si el usuario quiere compartirlo):**
+```bash
+# Instrucción generada en el README del MCP
+npx ${NOMBRE_MCP}
+```
+
+Genera el README con:
+1. Qué hace el MCP (una frase).
+2. Qué tools expone (tabla: nombre, qué hace, parámetros).
+3. Variables de entorno requeridas (`.env.example`).
+4. Instrucción de instalación para Claude Code.
+5. Ejemplo de uso: "Dile a Claude: *[frase de ejemplo]*".
+
+En perfil `guiado`, el README usa lenguaje sin jerga — el target es alguien que nunca abrió una terminal.
+
+## PASO 7 — Verificación final
+
+```bash
+# El servidor debe arrancar sin errores
+cd "${MCP_DIR}" && timeout 5 node src/index.js <<< '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' 2>&1
+
+# Debe listar todas las tools declaradas
+# Si el timeout expira sin error de sintaxis, es correcto (stdio espera input)
+```
+
+```bash
+# El .mcpb debe existir y tener contenido
+[ -f "${MCP_DIR}.mcpb" ] && ls -lh "${MCP_DIR}.mcpb" || echo "FALTA: bundle .mcpb"
+```
+
+## PASO 8 — Reporte final
+
+```
+🔌 MCP generado: ${NOMBRE_MCP}
+
+   Tools expuestas:
+   • nombre_tool_1  — [qué hace]
+   • nombre_tool_2  — [qué hace]
+
+   Archivos:
+   📁 ${MCP_DIR}/          — código fuente editable
+   📦 ${MCP_DIR}.mcpb      — bundle instalable
+
+   Instalar en Claude Code:
+   claude mcp add ${NOMBRE_MCP} -- node "$(pwd)/${MCP_DIR}/src/index.js"
+
+   Dile a Claude: "[frase de ejemplo de uso]"
+```
+
+En perfil `guiado`:
+> "¡Listo! Creé tu herramienta. Para usarla desde Claude, copia esta línea en tu terminal: [comando]. Después de eso, puedes decirle a Claude: *[ejemplo natural]* y lo hará automáticamente."
+
+---
+**HOOK:** `.sdd/hooks/despues_crear_mcp.sh`