Desarrollo IA Dirigido por Specs

Qué incluye este pack

Este pack reúne las cinco herramientas dirigidas por spec que hacen el coding con IA auditable. Cada una ataca una parte distinta del loop spec → agente → review, y componen bien en un solo proyecto.

OpenSpec y Planning with Files son el par estructural. OpenDeepWiki da al agente el contexto del codebase que necesita para escribir una spec competente, y Rivet es la capa visual para equipos que prefieren grafos de nodos en vez de markdown.

Por qué dirigido por specs

"Vibe coding" — decirle al agente lo que quieres y esperar lo mejor — funciona para tareas chicas y se cae en cualquier cosa multi-día. Tres problemas se acumulan:

• Drift. El agente pierde el rastro de la intención a través de muchos turnos. Cada turno nuevo re-deriva metas del historial de chat, lo cual tiene pérdida.
• Auditoría. Cuando el PR aterriza no puedes decir qué pensaba el agente que estaba construyendo. Los reviewers ingenierizan inversamente la intención desde diffs de código.
• Branching. Tres intentos concurrentes en la misma feature no tienen fuente de verdad compartida.

Una spec arregla las tres. La intención vive en un archivo markdown que el agente lee en cada turno (sin drift). El diff entre versiones de spec es la pista de auditoría (sin ingeniería inversa). Los intentos concurrentes forkean la spec del mismo modo que forkean código (branching limpio).

Instala en un comando

# Instala el pack completo
tokrepo install pack/spec-driven-ai-dev

# O elige el par núcleo
tokrepo install openspec
tokrepo install planning-with-files

OpenSpec aterriza como un directorio specs/ más un subagente Claude Code que la lee y actualiza. Planning with Files instala un hook que prompta al agente a emitir un PLAN.md antes de editar código. OpenDeepWiki corre como proceso separado que rastrea tu repo y sirve un wiki consultable. Rivet es app de escritorio y se instala con npm install -g @ironclad/rivet.

Errores comunes

• Specs demasiado gruesas. "Construye un flujo de checkout" es una meta, no una spec. Una spec usable lista criterios de aceptación, casos borde, y items fuera-de-alcance. La plantilla OpenSpec impone esta estructura; resiste la urgencia de borrar las secciones que te resulten incómodas.
• Specs demasiado finas. Una spec de 500 líneas para un patch de 20 líneas es sobre-ingeniería. Empareja la profundidad con el riesgo: patches chicos un párrafo, features multi-semana la plantilla completa.
• Pudrición de spec. Cuando la implementación diverge de la spec, la spec se vuelve mentira. El agente seguirá la mentira. Mantén la spec viva: cada PR la actualiza o nota explícitamente la desviación.
• Confundir archivos de planificación con specs. PLAN.md es la traza de razonamiento del agente para el próximo lote de trabajo; la spec es el artefacto durable. No los confundas; el archivo de plan es desechable.
• Rivet para todo. Rivet brilla en flujos prompt ramificados; es exagerado para tareas de coding de un solo tiro. Úsalo cuando el grafo agregue claridad, no por defecto.

Relación con otros packs

• Anthropic Builders entrega el runtime del agente; este pack añade la capa de spec encima.
• Toolkit Prompt Engineering afila el lenguaje usado dentro de specs y planes.
• Eval & Guardrails LLM te deja aseverar que la salida del agente matchea los criterios de aceptación de la spec.

Cuándo este pack solo no alcanza

El desarrollo dirigido por specs asume que ya sabes qué quieres. Para trabajo exploratorio — "¿qué debería ser este producto siquiera?" — empieza con un proceso de descubrimiento (entrevistas, prototipos, sketches), luego traduce hallazgos a specs. Saltarse ese paso produce specs bellamente formateadas para el producto equivocado. El pack es un multiplicador de fuerza para la claridad, no un sustituto.