| name | doc-to-backlog |
| description | Toma un documento de análisis (PDF, Word, o un archivo en Drive/SharePoint/ClickUp vía MCP) y produce un BACKLOG CANDIDATO — un mapa de épicas y User Stories propuestas — para que el funcional lo priorice y lo valide. NO emite US ni épicas finales: extrae candidatos marcados "sin validar" y hace handoff de cada sobreviviente a grill-epic / grill-user-story (modo refinar). Es la puerta de entrada del caso "llegué con un documento y quiero sacar el backlog". Invocar como /doc-to-backlog con el path o el link del documento. Usar antes de grill-epic / grill-user-story cuando el input es un doc grande. |
doc-to-backlog
Convierte un documento de análisis en un backlog candidato (épicas + US), para
arrancar el trabajo funcional cuando el input no es una idea suelta sino un PDF/Word con
todo el proyecto adentro.
Llena templates/backlog-candidato.md — es la única
fuente de verdad de la forma del mapa. Nunca lo reescribas inline.
El principio que NO se negocia
El documento SIEMBRA el grilling, no lo reemplaza. Un doc tienta a "genera 40 US de
una" — eso es vibe coding de requerimientos: salen US que nadie validó, de features que
quizás nadie necesita. Por eso esta skill no publica nada final: produce candidatos,
el humano prioriza, y recién ahí cada ítem pasa por su grill (Art. 4 y Art. 5).
Input
- El documento: path a un PDF/Word local, o un link a Drive/SharePoint/ClickUp
(traelo por MCP si está conectado). Claude lee PDFs de forma nativa.
- Si no viene, pedirlo.
Proceso — 3 fases
① Extraer (la IA lee)
- Leer el documento entero.
- Armar el mapa de candidatos: las épicas que el doc sugiere, y bajo cada una,
las US candidatas. Cada ítem con un título corto y una línea de qué cubre.
- Anotar la procedencia: de qué sección/página del doc salió cada candidato (para
poder trazar de vuelta al análisis).
- Marcar TODO como
sin validar. Es una hipótesis, no un backlog final.
② Triage (el humano decide)
- Presentar el mapa y frenar: el doc es un menú, no un mandato. Pedir al
funcional que priorice y corte — qué entra, qué queda para después, qué se
descarta. No todo lo que está en el doc hay que construirlo.
- Para lo dudoso, sugerir pasar por
/grill-intent (Gate 0): ¿este ítem resuelve un
problema real, o está en el doc "por las dudas"?
③ Routear (cada sobreviviente a su grill)
- No grillar todo de golpe. Empezar por la rebanada priorizada (las 1–3 épicas o
US más importantes), no las 40 (Art. 14).
- Handoff, en modo refinar (el doc pre-llena, el grill cubre solo los huecos):
- épica candidata →
/grill-epic (con el fragmento del doc como fuente)
- US candidata (suelta) →
/grill-user-story
- Recién en ese paso se publica en el tracker, testeable y linkeable (
dai link-us).
Dos cortes duros
- No emitir US/épicas finales desde el doc. Solo candidatos. Lo final sale del grill,
con el humano respondiendo. Si te descubres "completando" criterios que el doc no dice,
detente: eso lo define el funcional en el grill.
- No ahogar. Un doc de 60 páginas puede sugerir 50 ítems. Prioriza y entrega la
rebanada de arriba; el resto queda en el mapa candidato, listo para más tarde.
Relación con el modelo
- Es la puerta de entrada del caso bulk. Reemplaza "idea suelta" por "doc" como fuente.
- Abajo:
grill-epic (épicas) y grill-user-story (US) toman cada candidato y lo
vuelven artefacto válido. grill-intent desafía el problema de los dudosos.
- No toca el link: el
implements.yaml y el ac_hash viven a nivel US, mucho después
(dai link-us). Esta skill solo prepara el QUÉ.
