SDD Intake

Plugin de ingesta de requerimientos de clientes para proyectos existentes. Cierra el gap entre "el cliente sabe lo que quiere" y "el equipo de desarrollo tiene Feature Specs listos para implementar", cruzando los requerimientos del cliente con todo el contexto acumulado del proyecto en Engram (decisiones de arquitectura, patrones del equipo, reglas de negocio, bugs conocidos, metricas historicas). Produce Feature Specs en formato identico a SDD-Wizards, consumibles directamente por ATL Inteliside.

Prerequisitos

• Engram instalado y configurado con contexto del proyecto
• El proyecto debe tener contexto en Engram via al menos una de estas fuentes:
• SDD-Legacy (onboarding de proyecto legacy)
• ATL Inteliside (al menos una feature implementada)
• GitHub CLI (gh) instalado y autenticado
• Acceso al repositorio de GitHub del proyecto

Importante: Si el proyecto no tiene contexto en Engram (nivel NONE), el plugin bloquea y redirige a SDD-Legacy para hacer onboarding primero.

Skills

SDD-Intake tiene 2 skills con roles complementarios. El primero es de consulta para evaluar el estado del conocimiento del equipo. El segundo es el wizard conversacional que procesa los requerimientos del cliente.

Skill	Descripcion	Invocacion	Tools permitidos
project-context-summary	Resumen rapido de todo el contexto disponible de un proyecto en Engram. Muestra fuentes (SDD-Legacy, SDD-Wizards, ATL), features conocidas, reglas de negocio y nivel de informacion del equipo.	/sdd-intake:project-context-summary	(no especificado en frontmatter — hereda defaults)
client-intake-wizard	Wizard conversacional que toma requerimientos del cliente y los cruza con contexto de Engram para producir Feature Specs enriquecidos con reglas existentes, patrones del equipo, riesgos conocidos y estimaciones basadas en metricas reales.	/sdd-intake:client-intake-wizard	(no especificado en frontmatter — hereda defaults)

Flujo de trabajo

El flujo de SDD-Intake se ejecuta en 3 pasos, generalmente en la misma sesion:

1. Consultar contexto (project-context-summary): Antes de procesar requerimientos, el PM o dev ejecuta un resumen para saber que conoce el equipo sobre el proyecto. Esto revela las fuentes disponibles (legacy audit, features completadas, patrones, reglas de negocio) y el nivel de contexto (FULL, PARTIAL o NONE).

2. Procesar requerimientos (client-intake-wizard): El wizard guia una conversacion donde el PM describe lo que el cliente quiere. Para cada requerimiento, el wizard busca automaticamente en Engram:

3. Features existentes que solapan con el requerimiento
4. Reglas de negocio del dominio afectado
5. Patrones del equipo relevantes
6. Bugs y gotchas conocidos en el area
7. Metricas de esfuerzo de features similares
8. Deuda tecnica que podria bloquear la implementacion

El resultado es un Feature Spec enriquecido con una seccion exclusiva "Context from Existing Codebase" que contiene todo el cruce de contexto.

1. Implementar con ATL (atl-inteliside:orchestrador): El Feature Spec se sube como milestone a GitHub en formato identico al de SDD-Wizards. ATL lo consume directamente sin distinguir su origen.

/sdd-intake:project-context-summary       # ver que sabemos
/sdd-intake:client-intake-wizard           # procesar requerimientos
/atl-inteliside:orchestrador feat-{name}   # implementar

Contratos de datos

Engram

SDD-Intake es principalmente un consumidor de contexto — lee lo que otros plugins escribieron en Engram y produce Feature Specs enriquecidos. Usa el mismo engram_project que el resto del ecosistema.

Fuentes que lee, organizadas por plugin de origen:

De SDD-Legacy:

topic_key	Contenido	Para que lo usa
legacy/onboard-status	Checklist de onboarding	Determinar si el proyecto fue onboarded
legacy/audit	Health score, tech debt, stack	Evaluar riesgos por area
legacy/features/{name}	Features existentes del codigo	Detectar solapamiento con requerimientos nuevos
legacy/features-index	Indice de features detectadas	Busqueda rapida de features relacionadas
legacy/rules/{domain}	Reglas de negocio por dominio	Reglas que el nuevo requerimiento debe respetar
legacy/rules-index	Indice de dominios con reglas	Busqueda por area
legacy/health-score	Scores por area	Warning si el area tiene deuda critica
legacy/baseline	Plan de deuda tecnica	Items criticos que podrian bloquear la feature
legacy/conventions	Patrones de codigo	Referencia para el Feature Spec

De ATL Inteliside (equipo):

topic_key	Contenido	Para que lo usa
team/completed/*	Features implementadas	Precedentes reutilizables
team/patterns/*	Patrones por area	Patrones a referenciar en el Feature Spec
team/decisions/*	Decisiones de arquitectura	Restricciones a respetar
team/bugs/*	Gotchas resueltos	Riesgos conocidos a documentar
team/metrics/*	Metricas por feature	Estimacion de esfuerzo

De ATL Inteliside (pipeline):

topic_key	Contenido	Para que lo usa
project/config	Stack, convenciones, env vars	Contexto tecnico para el Feature Spec
project/github-context	owner, repo, milestone activo	Donde crear los milestones

Lo que escribe:

topic_key	Contenido	Quien lo lee
intake/{feature_name}/enrichment	Analisis cruzado: requerimiento + contexto	Solo interno (debug)
sdd/{feature_name}/feature-spec	Feature Spec generado (mismo formato SDD-Wizards)	ATL sdd-from-github
project/github-context	Actualiza si no existe	ATL sdd-init

Regla critica: El Feature Spec se guarda en el mismo topic_key que usa SDD-Wizards (sdd/{feature}/feature-spec). ATL no distingue si fue generado por SDD-Wizards o por SDD-Intake.

Niveles de contexto

El plugin clasifica automaticamente el estado del proyecto en 3 niveles que determinan como procede:

Nivel	Condicion	Accion
FULL	legacy/onboard-status existe + team/completed tiene entries	Cross-reference completo con todas las fuentes
PARTIAL	project/config existe (ATL corrio al menos una vez)	Procede con contexto limitado, advierte gaps
NONE	No hay nada en Engram para este proyecto	Bloquea — redirige a SDD-Legacy

GitHub

SDD-Intake crea milestones y issues en GitHub con el mismo formato que SDD-Wizards. Los milestones feat-{nombre} son consumibles directamente por ATL sin cambios.

Formato del Feature Spec

El Feature Spec generado sigue el formato estandar del ecosistema (identico a SDD-Wizards) con una seccion adicional exclusiva de SDD-Intake:

## Context from Existing Codebase
- Features relacionadas: [lista de features legacy/ATL que solapan]
- Reglas de negocio existentes: [reglas del codigo que aplican]
- Patrones a reutilizar: [patrones del equipo relevantes]
- Riesgos conocidos: [bugs, deuda tecnica, gotchas]
- Esfuerzo estimado: [basado en metricas de features similares]

Esta seccion es el valor agregado de SDD-Intake sobre SDD-Wizards. ATL la lee en sdd-from-github y la pasa a sdd-explore como contexto adicional, reduciendo el tiempo de exploracion y mejorando la calidad de la propuesta.

Hooks

SDD-Intake incluye un hook para validar que los Feature Specs generados cumplan con el formato esperado.

Evento	Matcher	Hook	Timeout	Proposito
PostToolUse	Write	feature-spec-validator.sh	10s	Valida que los Feature Specs escritos cumplan con el schema del formato estandar

Configuracion para proyectos

Agregar al CLAUDE.md del repositorio del proyecto:

## ATL Inteliside
engram_project: "nombre-proyecto-dev"
github_owner: "org-o-usuario"
github_repo: "nombre-repo"

## SDD Intake
# Este proyecto acepta requerimientos de clientes via sdd-intake.
# Prerequisito: el proyecto debe haber pasado por SDD-Legacy o tener
# al menos una feature completada con ATL para tener contexto.
#
# Flujo:
#   1. /sdd-intake:project-context-summary  → ver que sabe el equipo
#   2. /sdd-intake:client-intake-wizard     → procesar requerimientos
#   3. /atl-inteliside:orchestrador feat-X  → implementar

El template completo incluye ademas: nombre del proyecto, stack, comandos frecuentes, y references a rules de Engram y equipo.

Integracion con Doc-Gen

Despues de generar Feature Specs enriquecidos con client-intake-wizard, se recomienda correr doc-gen para mantener la documentacion del proyecto actualizada.

Cuando	Comando
Despues de generar Feature Specs enriquecidos	/doc-gen:doc-modulo {path-de-la-feature}
Verificacion periodica	/doc-gen:doc-sync

Limitaciones conocidas

• Requiere contexto previo en Engram: Sin onboarding (SDD-Legacy) o al menos una feature completada (ATL), el plugin bloquea. No puede funcionar en frio.
• Calidad del Feature Spec depende del contexto disponible: En nivel PARTIAL, el cruce de contexto es limitado. Los Feature Specs tendran menos informacion de riesgos y estimaciones que en nivel FULL.
• No reemplaza al PM: El wizard necesita un humano que describa los requerimientos del cliente. No genera requerimientos automaticamente.
• Formato de Feature Spec fijo: El output siempre sigue el formato estandar del ecosistema. No soporta formatos personalizados.
• Busqueda en Engram por keywords: La busqueda de contexto relevante se basa en mem_search por keywords del requerimiento. Puede perder contexto si los topic keys usan terminologia diferente a la del cliente.
• Un requerimiento a la vez: El wizard procesa requerimientos secuencialmente. Para multiples features del cliente, ejecutar el wizard una vez por feature.

---

SDD-Intake v1.0.0 — Marketplace Inteliside