arielelevy/fdd

Una ficha por feature. Un mapa del dominio. Cuatro hitos. Nada se cierra sin evidencia.
Para Claude Code, Codex, Kiro y cualquier agente que lea skills en Markdown.
> EN · Feature-Driven Development rebuilt for AI coding agents: one card per feature inside the
> project's constitution, a living domain map, four milestones and file ownership, so a fresh session
> can pick the work up without the chat. In a pilot, the domain map cut the tokens needed to resume
> a feature by 43 % with the same accuracy.
## El problema
Un agente trabaja en sesiones cortas. Cuando una feature pasa de una sesión a otra (se cortó el
contexto, se repartió entre agentes, se retoma al otro día), la sesión nueva reconstruye todo de cero:
qué se pidió, qué se decidió, qué archivos toca, qué está hecho y qué sólo fue afirmado.
Las metodologías para agentes tiran a dos extremos:
Spec-driven development (SDD): especificación, diseño, plan y tareas antes de tocar código.
Sirve para lo grande; para el trabajo de todos los días es ceremonia.
Sin proceso: rápido, hasta que hay que retomar, repartir o verificar.
## La idea
FDD (Jeff De Luca y Peter Coad, 1997) resolvía algo parecido para equipos humanos grandes: un modelo
del dominio compartido y el trabajo partido en features chicas con valor para el usuario, cada una con
dueño y avance visible. Esta skill toma esas piezas, deja afuera lo que no le sirve a un agente y les
suma la ficha y la exigencia de evidencia de FTD.
📜 FDD original, en un minuto (la teoría completa está en docs/fdd-1997.md )
Nació en 1997 en un proyecto de un banco de Singapur: unas 50 personas, 15 meses. De Luca armó el
proceso y Coad aportó el modelado de objetos y la idea de feature.
Feature: función chica con valor para el cliente, nombrada «\ el \ de un
\ » («calcular el total de una venta»), de dos semanas como máximo.
Cinco procesos: (1) desarrollar un modelo general, (2) construir la lista de features,
(3) planificar por feature, una vez cada uno; (4) diseñar por feature y (5) construir por feature,
en iteraciones.
Seis hitos con peso: recorrido del dominio 1 %, diseño 40 %, inspección del diseño 3 %,
código 45 %, inspección del código 10 %, promoción al build 1 %. El avance se cuenta, no se estima.
Roles: arquitecto jefe, programadores jefe que arman equipos por feature, dueños de clase
(sólo el dueño toca su clase) y expertos del dominio.
Prácticas: modelado del dominio, desarrollo por feature, propiedad de clases, inspecciones,
builds regulares y avance visible para todos (el diagrama de estacionamiento).
| | Pieza | Qué resuelve |
| ⚖️ | Constitución y arquitectura | Las reglas y la estructura que ningún cambio rompe, ni el más chico (AGENTS.md, decisiones, contratos, capas y patrones). FDD trabaja dentro de ellas y no pide otro archivo |
| 🗺️ | Mapa del dominio (docs/dominio.md) | La sesión nueva sabe qué entidades hay y dónde vive cada una sin explorar el repo |
| 🏷️ | Feature con nombre de resultado | «avisar cuando una regla queda apagada», no «arreglar rules.py»: se entiende sola |
| 🗂️ | Una ficha por feature | Objetivo, alcance, criterios, dominio, archivos, decisiones, evidencia y próximo paso en un lugar |