to-PRD + to-Issues: Condensar la conversación de la parrilla en una porción vertical ejecutable

La posición de esta sección en el flujo de trabajo.

Volvamos al diagrama de flujo de trabajo de Matt:

/grill-me 或 /grill-with-docs   ← 谈清楚
        ↓
   /to-prd                       ← 凝固成 PRD（你在这里）
        ↓
   /to-issues                    ← 切成可领取的 vertical slice（你在这里）
        ↓
   /tdd                          ← 一个 slice 一个 slice 跑红绿
        ↓
   /improve-codebase-architecture

/to-prd y /to-issues son un vínculo entre lo anterior y lo siguiente: traducir decisiones abstractas de diálogo** en unidades de trabajo ejecutables**. Los combino porque en el uso real de Matt son dos pasos consecutivos.

Modo de falla: nada que hacer después de asar

Muchas personas se quedan estancadas después de usar /grill-me: tienen una larga conversación con un montón de decisiones, pero ¿cómo empezar a escribir código?

Darle a Claude un "por favor hazlo" directamente está mal, porque:

1. Implementar funciones completas a la vez = salida de IA de más de 1000 líneas = difícil de revisar, difícil de probar, difícil de localizar errores
2. Después de que la IA pierde la memoria, la siguiente sesión no tiene contexto.
3. Sin seguimiento: no hay forma de saber dónde hemos llegado y cuánto queda

El enfoque correcto es congelar la decisión en un artefacto (PRD) y luego dividir el PRD en paquetes de trabajo (problemas) que sean lo suficientemente pequeños como para completarse de forma independiente. Esto ha sido de conocimiento común en la ingeniería de software durante 30 años, pero adquiere un nuevo significado en la era de la IA:

Píquelo lo suficientemente fino como para que el agente AFK (el agente que se ejecuta cuando usted no está presente) pueda recogerlo y completarlo de forma independiente.

/to-prd: comprime la conversación en PRD

Limitaciones clave de las habilidades

SKILL.md de /to-prd escribe una oración muy importante al principio:

"This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know."

No hagas más preguntas. Esto es lo que hace la etapa grill-me, to-prd solo hace síntesis. Así que no borre el contexto y ejecute-prd: se basa en todo el diálogo de la parrilla anterior.

Flujo de procesamiento de habilidades

1. Explore la base del código (si aún no la ha explorado): utilice el vocabulario CONTEXT.md del proyecto y respete las ADR existentes.
2. Borrador del módulo——Busque proactivamente oportunidades que puedan extraerse como módulos profundos para que la interfaz se pueda probar de forma independiente
3. Alinear módulos con usuarios - "¿Son correctos estos módulos? ¿Cuáles deben probarse?"
4. Genere PRD según la plantilla, envíelo al rastreador de problemas y etiquételo con needs-triage

Plantilla PRD

La plantilla proporcionada por Matt es la siguiente:

## Problem Statement
The problem that the user is facing, from the user's perspective.

## Solution
The solution to the problem, from the user's perspective.

## User Stories
A LONG, numbered list:
1. As a <actor>, I want a <feature>, so that <benefit>
2. ...

## Implementation Decisions
- The modules that will be built/modified
- The interfaces of those modules
- Technical clarifications from the developer
- Architectural decisions
- Schema changes / API contracts / Specific interactions

(NO specific file paths or code snippets — they rot fast.)

## Testing Decisions
- What makes a good test (test external behavior, not internals)
- Which modules will be tested
- Prior art (similar tests in the codebase)

## Out of Scope
What's NOT in this PRD.

## Further Notes

Varios diseños clave:

• Las historias de usuarios representan la mayoría: requisitos LARGA lista numerada, lo que le obliga a enumerar exhaustivamente los puntos de función completos. Esto evita el punto ciego de "pensé que estaba claro".
• La implementación no escribe rutas de archivo ni código: Matt dijo directamente "pueden terminar quedando obsoletos muy rápidamente". Esta es una consideración única en la era LLM: la ruta específica quedará obsoleta inmediatamente después de la reconstrucción, pero el "límite del módulo" y el "contrato de interfaz" tienen un ciclo de vida más largo.
• Debe tener fuera de alcance: este párrafo se ignora en la mayoría de las plantillas del PRD, pero es el seguro de límites cuando se cortan temas más adelante.

/to-issues: Cortar el PRD en rodajas verticales

¿Qué es el corte vertical?

Este es uno de los conceptos más importantes de toda la metodología de Matt. SKILL.md dijo directamente:

Each issue is a thin vertical slice cutting through ALL integration layers end-to-end, NOT a horizontal slice of one layer.

El ejemplo más claro es crear una “función de comentario”.

Corte horizontal (forma incorrecta):

• Problema 1: esquema de base de datos
• Problema 2: puntos finales API
• Problema 3: componentes de la interfaz de usuario
• Número 4: Pruebas

Corte longitudinal (método Tracer Bullet):

• Problema 1: "Los visitantes pueden enviar un comentario anónimo" (se incluyen esquema + API + UI + prueba, pero el alcance es tan pequeño que solo puede ser anónimo)
• Problema 2: "Los comentarios de los usuarios que han iniciado sesión están asociados con la cuenta"
• Problema 3: "Se pueden responder los comentarios"
• Problema 4: "Los administradores pueden eliminar comentarios"

El problema del corte horizontal: cada corte no se puede probar individualmente. Después de completar el Número 1, no había nada que demostrar, y no fue hasta el Número 4 que se pudo ejecutar todo el enlace; fue sólo entonces que descubrí que el diseño del esquema era incorrecto.

Cada segmento vertical completado es un subconjunto funcional disponible de extremo a extremo, denominado bala rastreadora (bañera rastreadora) en palabras del programador pragmático. Dispare primero una ronda para comprobar la mira y luego ajuste la siguiente ronda.

HITL vs AFK

/to-issues también etiqueta cada segmento:

• HITL (Human in the Loop): requiere que las personas participen en la toma de decisiones. Como decisiones arquitectónicas, revisiones de diseño.
• AFK (Ausente del teclado): el agente puede completar el trabajo de forma independiente y usted puede regresar para ver los resultados.

"Prefiere AFK a HITL siempre que sea posible".

Esta es una idea muy radical en el flujo de trabajo de Matt: después de terminar de cortar el problema, lo envía directamente a un agente que se ejecuta cuando usted no está presente (como por la noche o los fines de semana). Cuando regresa al día siguiente, el PR ya está allí esperando ser revisado. La parte HITL permanece durante el día y trabaja con el agente.

Enlace de confirmación de corte

/to-issues no generará un problema tan pronto como aparezca; primero le mostrará el esquema de ordenamiento en mosaico como una lista numerada:

1. Title: 访客提交匿名评论
   Type: AFK
   Blocked by: None
   User stories covered: #1, #2

2. Title: 评论关联到登录账户
   Type: AFK
   Blocked by: #1
   User stories covered: #3

3. Title: 评论审核流程
   Type: HITL（需要确认审核 UI 设计）
   Blocked by: #1
   User stories covered: #4, #5

Entonces pregúntale:

• ¿La granularidad es correcta? ¿Demasiado grueso/demasiado fino?
• ¿Son correctas las dependencias?
• ¿Cuáles deberían fusionarse/dividirse?
• ¿Son correctas las marcas HITL/AFK?

Itere hasta que asienta antes de enviarlo al rastreador de problemas, en orden de dependencia (bloqueador primero), para que los problemas posteriores puedan hacer referencia al ID de problema real del primer problema.

Plantilla de problema

## Parent
A reference to the parent issue (if any).

## What to build
A concise description. Describe end-to-end behavior, NOT layer-by-layer
implementation.

## Acceptance criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Blocked by
- A reference to the blocking ticket
(or "None - can start immediately")

Tenga en cuenta la línea "describir el comportamiento de un extremo a otro", que es coherente con el espíritu del corte vertical. Los criterios de aceptación son una lista de aceptación, que Claude convertirá en pruebas una por una en la etapa /tdd.

Cómo utilizar: ejemplo de proceso completo

Suponga que desea agregar funcionalidad de comentarios a su blog. Proceso completo:

你: 我想给博客加评论功能
    ↓
/grill-me  →  Claude 问 30 个问题（要不要登录？匿名？嵌套？审核？……）
    ↓
你回答完毕，达成共识
    ↓
/to-prd    →  Claude 生成结构化 PRD，提交到 GitHub Issues #42
    ↓
/to-issues  →  Claude 提议切成 4 个 vertical slice
                  让你确认粒度和依赖
                  你点头
                  按依赖顺序发布到 GitHub Issues #43~#46
    ↓
你回家睡觉
    ↓
夜里 AFK agent 抓 #43（无依赖），跑 /tdd 完成 → 提 PR
你早上 review、merge
    ↓
agent 抓 #44 / #45 ……

Todo el proceso no requiere que te sientes frente a la pantalla y observes cada detalle. Las decisiones clave se toman en la etapa de interrogarme.

Instalación y requisitos previos

npx skills@latest add mattpocock/skills

Marque to-prd, to-issues, setup-matt-pocock-skills.

Primero debe ejecutar /setup-matt-pocock-skills: escribirá su rastreador de problemas (GitHub/GitLab/markdown local) y el vocabulario de etiquetas de clasificación en AGENTS.md/CLAUDE.md; de lo contrario, to-prd y to-issues no sabrán dónde enviar los problemas.

Rastreadores de problemas admitidos:

• Problemas de GitHub (predeterminado, usa gh CLI)
• Problemas de GitLab (usando glab CLI)
• Rebaja local (crear archivos en .scratch/<feature>/): adecuado para proyectos personales o proyectos sin control remoto
• Otros (Jira, Linear, etc.) - Utilice una prosa para describir el flujo de trabajo y la habilidad se llamará según su descripción.

Preguntas frecuentes

**P: Ya existe un PRD ya preparado. ¿Puedo saltar a prd e ir directamente a issues? ** R: Sí. /to-issues acepta una referencia de problema como parámetro ("Dividir el problema n.° 42 en sectores verticales"), buscará el contenido del problema y luego lo dividirá.

**P: Mi proyecto no utiliza el rastreador de problemas, ¿se puede utilizar? ** R: Sí. Seleccione "Rebaja local" durante la configuración y todos los problemas se convertirán en archivos locales como .scratch/<feature>/001-foo.md.

**P: ¿Qué debo hacer si el PRD es demasiado largo y la IA por sí sola no puede manejarlo? ** R: Esto es un signo de granularidad de corte: el PRD debe dividirse en múltiples PRD independientes en lugar de un PRD gigante. Deberías sentirlo durante la etapa de parrilla: si hablas del número 50 y todavía estás introduciendo nuevas funciones, detente primero, córtalo en dos PRD y hazlo en lotes.

**P: ¿Cómo detecta automáticamente el agente AFK los problemas? ** R: El repositorio de Matt no proporciona esta parte y debe coordinarse con su propio acuerdo de agente (por ejemplo, GitHub Actions activa Claude Code para ejecutar problemas). Lo más fácil es hacer cron para verificar is:open no:assignee label:agent-ready cada hora.

El verdadero valor de este proceso

/to-prd y /to-issues parecen "gestión de proyectos automatizada", pero Matt los sitúa en el centro de su flujo de trabajo por una razón más profunda:

Te obliga a pensar "Qué es una cosita completa". Cuando te ves obligado a cortar la funcionalidad en cortes verticales, estás haciendo una de las cosas más difíciles en ingeniería de software: encontrar uniones. El pensamiento en sí es más valioso que estas dos habilidades.

Y el tamaño del corte vertical es el tamaño que la IA puede manejar al mismo tiempo. Deje que el tamaño de la tarea coincida con el límite superior de las capacidades de la IA: este es el ritmo fundamental de colaboración con LLM.

Recursos de referencia

Siguiente artículo: TDD: Utilice la reconstrucción roja y verde para obligar a la IA a dar pequeños pasos——Una vez solucionado el problema, cómo hacer que la IA realmente dé pequeños pasos.