Workflow Design Bible — un generador de constituciones para proyectos autónomos gestionados por agentes

Qué es este skill. Un meta-prompt de sistema reutilizable. Cuando el usuario quiere crear un nuevo proyecto autónomo (canal de contenido/video, libro electrónico/publicación, herramienta SEO/sitio wiki, producto web, juego casual, …), este skill ejecuta una entrevista estructurada breve, luego completa un sistema estándar de "constitución + documentación" : un CLAUDE.md raíz y ligero (la constitución del proyecto) + un documentation/configuration.json + una carpeta documentation/ con documentos de fuente única de verdad + esqueletos vacíos de .claude/agents/, .claude/skills/, reflections/, reports/.

Qué no hace este skill. No ejecuta código de negocio, no escribe lógica de aplicación y no despliega nada. Solo realiza la entrevista → genera el esqueleto de documentación + registros. La CLI real (factory.py / press.py / lo que sea), los prompts de sistema reales de los sub-agentes y cada habilidad de capacidad se desarrollan más tarde por el propio agente CEO y el agente mantenedor del proyecto.

Dos formas de usarlo. (1) Leer el documento — pega este archivo en cualquier LLM capaz y síguelo manualmente. (2) Instalar el skill — coloca esta carpeta en el directorio de skills del runtime de tu agente (por ejemplo, una ubicación global skills/) para que se active automáticamente cuando inicies un nuevo proyecto.

Las plantillas viven junto a este archivo, para que la constitución se mantenga ligera:

templates/CLAUDE.md.template — el esqueleto de constitución a rellenar.

templates/configuration.json.template — la fuente única de verdad de la marca.

A lo largo de este documento: "CEO" = el agente principal/orquestador; "el usuario" = el propietario humano/presidente que establece la dirección y aprueba. Nombres de archivo como CLAUDE.md son convenciones — sustitúyelos por lo que tu runtime lea como instrucciones de agente de nivel superior (por ejemplo, AGENTS.md).

A. Las ocho filosofías de diseño no negociables

Estas ocho son el alma de la Biblia. Cada constitución generada debe incorporar las ocho — no son opciones, son la base.

Filosofía 1 · El agente principal es un CEO, no un trabajador

La función del agente principal es orquestar, supervisar, revisar, controlar el proceso y hablar con el usuario — no hacer el trabajo manual él mismo. Dedica su contexto y razonamiento al juicio y la coordinación. Cada paso fijo y repetible se delega por defecto a un sub-agente.

Filosofía 2 · Todo es un sub-agente; la concurrencia es el poder latente por defecto

Cada paso de trabajo fijo se asigna a un sub-agente con un rol claro. Como el trabajo tiene forma de sub-agente, es nativamente paralelizable:

Pasos independientes → se distribuyen a la vez (por ejemplo, compilación / portada / redacción publicitaria en paralelo).
Muchas tareas homogéneas de un tipo → concurrencia por lotes (por ejemplo, 60 escenas, 50 en vuelo).

Expresa la concurrencia en los puntos de distribución del pipeline (una sección dedicada de "paralelismo"), no como contabilidad en cada agente individual. Precaución contra la sobre proliferación: si un motor/codebase compartido subyace a muchos artefactos, prefiere un agente mantenedor compartido sobre un mantenedor por artefacto — divide un rol solo cuando un artefacto tiene dependencias genuinamente distintas.

Filosofía 3 · Arquitectura de cuatro capas (CEO → Sub-agente SP → Habilidad → MCP/CLI)

Las capacidades están escalonadas; cada capa apunta hacia abajo, y los detalles nunca se filtran hacia arriba:

① CEO (CLAUDE.md)            — asigna trabajo, establece principios, no toca detalles
   ↓ enviar un sub-agente con un resumen de tarea autocontenido
② Sub-agente (su prompt de sistema)
   — definición de rol + "qué habilidades debe usar principalmente este rol" (punteros)
   ↓ invocar una habilidad
③ Habilidad (su SKILL.md)
   — cómo se usa una capacidad; declara qué servidores MCP y qué comandos CLI la componen
   ↓ ejecutar
④ Servidores MCP + herramientas de línea de comandos (ejecutados, nunca cargados en contexto)

Disciplina clave: un sub-agente puede ver una gran pila de habilidades globales y locales, pero ver ≠ debería usar. Su prompt de sistema debe limitar explícitamente ("tu trabajo usa principalmente la habilidad X / Y") para que no tome herramientas al azar.

Filosofía 4 · Fuente única de verdad + punteros; la constitución nunca se infla

CLAUDE.md mantiene solo las cosas más críticas y claras: definiciones de roles, principios de operación/gestión/orquestación, la columna vertebral del pipeline (paso a paso) y el mapa de archivos. Todo el conocimiento común concreto / las fuentes únicas de verdad se hunden en documentos independientes bajo documentation/; la constitución solo tiene un puntero + una línea de contexto. Del mismo modo, empuja los detalles de los roles hacia abajo en el prompt de sistema de cada sub-agente — el CEO no necesita saber cómo funciona un rol, solo que existe; lee ese SP cuando necesita el detalle.

Por qué: CLAUDE.md reside en el contexto en cada interacción. El detalle escrito dentro de él = se lleva como sobrecarga, quemando tokens, en cada turno.

Filosofía 5 · Capas de capacidad de dos niveles: global (reutilización) vs. local (construcción)

Cada constitución divide las capacidades en dos y les dice a los sub-agentes el límite:

Global (reutilización, no construido aquí): habilidades / MCP / sub-agentes compartidos en todos tus proyectos (una capacidad de mensajería, un generador de imágenes, un ayudante de investigación, varios agentes operadores). Llámalos directamente, costo de construcción cero.
Local (construido/bifurcado para este proyecto): la CLI específica del proyecto, las habilidades del proyecto, los sub-agentes del proyecto.
⚠️ Trampa de ámbito: una habilidad con ámbito en el directorio de otro proyecto no se cargará automáticamente aquí; bifurca una copia recortada o llama al equivalente global. Declara esto en la constitución generada.

Filosofía 6 · La reflexión y la auto-iteración son siempre el último paso — y hay dos bucles

La columna vertebral de cada pipeline termina con Reflexión y Auto-Iteración: revisa los defectos y la eficiencia de este ciclo → atribuye causas raíz → envía el agente mantenedor para mejorar el proceso → consolida. El objetivo es convertir constantemente "todavía decidido sobre la marcha" en "ahora congelado en una función determinista." Sin revisión de auto-iteración = el bucle no se cerró. Existen dos bucles distintos; la constitución debe mantenerlos separados:

Bucle A — reflexión por ciclo (al final de cada ejecución del pipeline) → escribe en reflections/ (permanente; nunca en un directorio de compilación que se limpie).
Bucle B — revisión asíncrona entre sesiones: un trabajo programado escribe un informe de datos/análisis en reports/; el ritual de inicio de la siguiente sesión escanea reports/, adopta/descarta, luego archiva. Además, una nota HANDOFF lleva el trabajo inconcluso entre sesiones.

Filosofía 7 · Constitución como código: una auto-verificación determinista mantiene las afirmaciones == realidad

Una constitución se desvía: afirma "9 sub-agentes, 7 habilidades" mientras que el sistema de archivos dice lo contrario. Por lo tanto, cada proyecto incluye un comando determinista doctor / lint de consistencia que verifica lo que los documentos afirman contra lo que realmente existe (agentes, habilidades, subcomandos CLI, recuentos de activos, la base de datos lifeline) y sale con código no cero en caso de desviación. Este es el respaldo automático para la regla de "consistencia de propagación": cualquier cambio en una hoja (CLI / habilidad / SP / plantilla) debe, antes de completarse, reconfirmar los contratos de las capas superiores — y doctor lo aplica mecánicamente.

Filosofía 8 · Forma estándar (constitución raíz + documentation/)

La carpeta del proyecto tiene una forma fija desde el nacimiento:

<project>/                   # Directorio raíz del proyecto
├── CLAUDE.md                ← constitución: principios / columna vertebral / punteros / mapa (residente en contexto)
├── documentation/           ← cada fuente única de verdad / conocimiento común / configuración (cargado bajo demanda)
│   ├── configuration.json        configuración estructurada de la marca (fuente única de verdad)
│   ├── INITIALIZATION.md         configuración única de primer despliegue
│   ├── reflection_playbook.md    el paso a paso para el paso de reflexión
│   ├── <playbook>.md             libros de jugadas temáticos (puerta de calidad / SOP de tema / cumplimiento / …)
│   └── …
├── .claude/agents/         ← prompts de sistema de sub-agentes (definiciones de roles)
├── .claude/skills/         ← cada SKILL.md (definiciones de capacidades)
├── <core>.py / <core>/     ← código CLI determinista (ejecutado, nunca en contexto)
├── reflections/            ← informes de reflexión por ciclo (permanentes)
├── reports/                ← informes de datos/análisis asíncronos (consumidos al inicio de la sesión)
├── HANDOFF.md              ← traspaso entre sesiones de trabajo inconcluso
├── CHANGELOG.md
└── <lifeline>.db           ← almacén de memoria lifeline (gitignorado)

B. Lo que una ejecución de este skill entrega

Entregable	Ruta	Contenidos
Constitución del proyecto	`<project>/CLAUDE.md`	Rellenado desde `templates/CLAUDE.md.template` (ligero, basado en punteros).
Configuración de la marca	`<project>/documentation/configuration.json`	Rellenado desde `templates/configuration.json.template`.
Documento de inicialización	`<project>/documentation/INITIALIZATION.md`	Lista de verificación de credenciales + pasos de despliegue único (esqueleto).
Documentos de fuente única por tema	`<project>/documentation/<topic>.md`	Las reglas identificadas en la entrevista que no pertenecen a la constitución (un archivo cada una).
Esqueletos vacíos	`.claude/agents/`, `.claude/skills/`, `reflections/`, `reports/`, `HANDOFF.md`	Crear directorios + un `.gitkeep` o marcador de posición README cada uno..

No generado: código de negocio, contenidos reales de los SP de sub-agentes, implementaciones reales de habilidades — esos crecen después de que el proyecto existe. Este skill produce solo los registros + esqueleto + marcadores de posición, registrando de antemano qué roles y capacidades deberían existir dentro de CLAUDE.md.

C. Protocolo de interacción (la entrevista de admisión)

Completa la entrevista antes de generar. Pregunta por rondas; ofrece opciones múltiples siempre que sea posible para minimizar la escritura del usuario. Después de cada ronda, repite la respuesta para confirmar, luego continúa. El objetivo: llenar cada {{placeholder}} en las plantillas.

Reglas de eficiencia para el entrevistador:

El modelo CEO, las cinco/seis reglas principales y la arquitectura de cuatro capas son constantes en todos los proyectos — no entrevistes para ellos; vienen pre-completados de la plantilla.

Para capacidades globales, inspecciona automáticamente el entorno anfitrión primero (inspecciona las habilidades / tipos de sub-agentes / servidores MCP disponibles que expone tu runtime) y propón una lista de reutilización para que el usuario confirme o recorte — no le pidas al usuario que las recuerde de memoria.

Agrupa preguntas relacionadas (hasta ~4 a la vez). Apunta a terminar en 3–4 rondas, no 7.

Ronda 0 · Arquetipo del proyecto (selecciona la rama de plantilla del pipeline)

Pregunta qué arquetipo es el proyecto; cada uno precarga un borrador de columna vertebral diferente:

Arquetipo	Columna vertebral típica (borrador precargado, luego ajustar con el usuario)
Contenido — video/canal	tema → guión → renderizar → publicar → interactuar/comentarios → reflexionar
Contenido — libro electrónico/publicación	tesis → escribir → compilar → distribución multicanal → marketing → optimizar → reflexionar
Activo de tráfico SEO (sitio wiki/herramienta)	tema → construir → enviar → monetizar → SEO/monitorear → reflexionar
Producto/sitio web	requisitos → diseñar → construir → probar → desplegar → monitorear → reflexionar
Juego casual	concepto → producción de activos (concurrencia por lotes pesada) → construir → probar → publicar → ajustar con datos → reflexionar
Otro (personalizado)	co-diseñar el paso a paso desde cero

Ronda 1 · Misión, Estrella Polar y líneas rojas

Misión en una oración (se convierte en la Estrella Polar del CEO).
3–5 restricciones ordenadas por prioridad no negociables (la anterior siempre supera a la posterior). Guía al usuario para pensar en la cadena (por ejemplo, "seguridad de la cuenta > calidad del contenido > cantidad > velocidad > ingresos por unidad").
La #1 ley de hierro / línea roja de cumplimiento, si la hay ("violarla y todo se desperdicia" — por ejemplo, anti-spam de la plataforma, anti-slop de IA del mercado, Términos de Servicio).
No haceres (dos niveles): lo que está Prohibido (acciones de línea roja que pueden anular todo el proyecto) vs Desaconsejado (evitar a menos que esté justificado). Estos pueblan la sección No haceres de la plantilla, en paralelo a las Reglas.

Ronda 2 · Marca (→ configuration.json)

¿Marca/nombre en clave? ¿Entidad de atribución (nombre real? ¿seudónimo? ¿empresa?)? ¿Por idioma?
¿Eslogan / lema?
¿Activos de logotipo (existentes)?
Lenguaje de diseño: colores primarios, fuentes, palabras clave de tono, estilo visual, tabúes.
¿Ancla de confianza / E-E-A-T (sitio / identidad del autor)?
¿Entidad de pago / cuenta (si está monetizado)?

Ronda 3 · Columna vertebral del pipeline (paso a paso)

Partiendo del borrador del arquetipo, define cada paso: qué hace → su salida → el rol principal.
Marca qué pasos pueden ejecutarse en paralelo (los puntos de distribución).
Confirma que el último paso = reflexión y auto-iteración.

Ronda 4 · Roles (división de sub-agentes) + capacidades globales/locales

Un sub-agente por paso fijo: nombre + rol de una línea + qué paso.
Siempre debe haber un dev-maintainer (posee todos los cambios de código/SP/habilidad).
Aplica la regla anti-proliferación: prefiere un mantenedor compartido a menos que un artefacto tenga dependencias distintas.
Confirma la lista de reutilización global inspeccionada automáticamente; enumera las habilidades locales a construir/bifurcar — y para cada habilidad local, qué servidores MCP + qué comandos CLI la componen (Filosofía 3, capa ③).
Para cada sub-agente, nombra qué habilidades debería usar principalmente (el puntero en su SP).

Ronda 5 · Memoria lifeline + documentos de fuente única + fase/credenciales

¿Qué almacén de memoria a largo plazo necesita el proyecto (DB de cartera de activos / almacén de vectores para deduplicación / libro de contabilidad de progreso…)? ¿Qué campos?
¿Qué reglas son de "fuente única de verdad" y deberían convertirse cada una en un documentation/<topic>.md? (cumplimiento, SOP de tema, puerta de calidad, precios, disciplina de aumento gradual…) Registrar cada una.
¿Fase actual? ¿Cadencia de aumento gradual / disciplina de riesgo?
¿Qué credenciales privadas / cuentas externas debe proporcionar el usuario (→ INITIALIZATION.md)?
El límite para "solo dos razones para detenerse y preguntar al usuario" (credencial faltante / juicio empresarial subjetivo).

Cuando la entrevista haya terminado, repite cada campo clave rellenado y confirma antes de escribir cualquier archivo.

D. Reglas de generación

Copia templates/CLAUDE.md.template, reemplaza cada {{…}}, elimina las secciones opcionales que no

… [truncado para traducción]

preangelleo/workflow-design-bible

¿Qué es workflow-design-bible?

Preguntar en tu IA favorita

Documentación