to-PRD + to-Issues : condensez la conversation du grill en une tranche verticale exécutable

La position de cette section dans le workflow

Retour au diagramme de flux de travail de Matt :

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

/to-prd et /to-issues sont un lien entre le précédent et le suivant : traduire des décisions abstraites de dialogue** en unités de travail exécutables**. Je les combine car dans l'utilisation réelle de Matt, ce sont deux étapes consécutives.

Mode échec : Rien à faire après la grillade

De nombreuses personnes se retrouvent bloquées après avoir utilisé /grill-me : elles ont une longue conversation avec un tas de décisions, mais comment commencer à écrire du code ?

Donner directement à Claude un « s'il vous plaît, faites-le » est une erreur - car :

1. Implémentation de fonctions complètes en même temps = sortie AI plus de 1000 lignes = difficile à examiner, difficile à tester, difficile à localiser les bogues
2. Une fois que l'IA a perdu sa mémoire, la session suivante n'a plus de contexte.
3. Pas de suivi - aucun moyen de savoir où nous sommes arrivés et combien il en reste

L’approche correcte consiste à figer la décision dans un artefact (PRD), puis à découper le PRD en lots de travaux (problèmes) suffisamment petits pour être réalisés indépendamment. C'est un fait connu dans le domaine du génie logiciel depuis 30 ans, mais cela prend un nouveau sens à l'ère de l'IA :

Hachez-le suffisamment finement pour que l'agent AFK (l'agent qui s'exécute lorsque vous n'êtes pas présent) puisse le récupérer et le compléter de manière autonome.

/to-prd : compresse la conversation en PRD

Principales contraintes de compétence

SKILL.md de /to-prd écrit une phrase très importante au début :

"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."

Ne posez plus de questions. C'est ce que fait l'étape grill-me, to-prd ne fait que de la synthèse. Alors n'effacez pas le contexte et exécutez vers-prd - cela s'appuie sur tous les dialogues du grill précédent.

Flux de traitement des compétences

1. Explorez la base de code (si vous ne l'avez pas encore explorée) - utilisez le vocabulaire CONTEXT.md du projet et respectez les ADR existants
2. Module préliminaire——Recherchez de manière proactive les opportunités qui peuvent être extraites sous forme de modules approfondis afin que l'interface puisse être testée de manière indépendante.
3. Aligner les modules avec les utilisateurs - "Ces modules sont-ils corrects ? Lesquels doivent être testés ?"
4. Générez le PRD selon le modèle, envoyez-le au système de suivi des problèmes et étiquetez-le avec needs-triage

Modèle PRD

Le modèle donné par Matt est le suivant :

## 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

Plusieurs modèles clés :

• Les User Stories représentent la majorité : Exigences LONGUE liste numérotée - vous obligeant à énumérer de manière exhaustive les points de fonction complets. Cela évite le point aveugle du "Je pensais que c'était clair"
• L'implémentation n'écrit pas les chemins de fichiers ni le code : Matt a directement dit "ils pourraient finir par être obsolètes très rapidement". Il s'agit d'une considération unique à l'ère LLM : le chemin spécifique deviendra obsolète immédiatement après la reconstruction, mais la « limite du module » et le « contrat d'interface » ont un cycle de vie plus long.
• Doit être hors de portée : ce paragraphe est ignoré dans la plupart des modèles PRD, mais il constitue l'assurance des limites lors de la résolution ultérieure des problèmes.

/to-issues : Couper le PRD en tranches verticales

Qu'est-ce que la tranche verticale ?

C’est l’un des concepts les plus importants de toute la méthodologie de Matt. SKILL.md a dit directement :

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

L’exemple le plus clair est de créer une « fonction de commentaire ».

Tranchage horizontal (dans le mauvais sens) :

• Problème 1 : Schéma de base de données
• Problème 2 : points de terminaison de l'API
• Problème 3 : composants de l'interface utilisateur
• Numéro 4 : Tests

Tranchage longitudinal (méthode Tracer Bullet) :

• Problème 1 : "Les visiteurs peuvent soumettre un commentaire anonyme" (schéma + API + UI + test sont tous inclus, mais la portée est si petite qu'elle ne peut être qu'anonyme)
• Problème 2 : "Les commentaires des utilisateurs connectés sont associés au compte"
• Problème 3 : "Il est possible de répondre aux commentaires"
• Problème 4 : "Les administrateurs peuvent supprimer des commentaires"

Le problème du découpage horizontal : chaque tranche ne peut pas être testée individuellement. Une fois le numéro 1 terminé, il n'y avait plus rien à démontrer, et ce n'est qu'au numéro 4 que l'intégralité du lien a pu être parcourue. C'est seulement à ce moment-là que j'ai découvert que la conception du schéma était erronée.

Chaque tranche verticale terminée est un sous-ensemble fonctionnel disponible de bout en bout - appelé une balle traceuse (balle traceuse) selon les mots du programmeur pragmatique. Tirez d'abord sur un tour pour vérifier le réticule, puis ajustez le tour suivant.

HITL vs AFK

/to-issues étiquette également chaque tranche :

• HITL (Human in the Loop) - exige que les gens participent à la prise de décision. Tels que les décisions architecturales, les revues de conception
• AFK (Away From Keyboard)——L'agent peut terminer le travail de manière indépendante et vous pouvez revenir pour voir les résultats.

"Préférez AFK plutôt que HITL lorsque cela est possible."

Il s'agit d'une idée très radicale dans le flux de travail de Matt : une fois le problème résolu, vous l'envoyez directement à un agent qui intervient lorsque vous n'êtes pas présent (par exemple la nuit ou le week-end). Lorsque vous revenez le lendemain, le PR est déjà là en attente d'examen. La partie HITL reste la journée et travaille avec l'agent.

Lien de confirmation du découpage

/to-issues ne générera pas de problème dès qu'il surviendra - il vous montrera d'abord le schéma de mosaïque sous forme de liste numérotée :

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

Alors demandez-vous :

• La granularité est-elle correcte ? Trop épais/trop fin ?
• Les dépendances sont-elles correctes ?
• Lesquels devraient être fusionnés/scindés ?
• Les marquages HITL/AFK sont-ils corrects ?

Répétez jusqu'à ce que vous hochiez la tête avant de l'envoyer au système de suivi des problèmes, par ordre de dépendance (le bloqueur en premier), afin que les problèmes ultérieurs puissent faire référence au véritable ID du premier problème.

Modèle de problème

## 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")

Notez la ligne "décrire le comportement de bout en bout" - cohérente avec l'esprit de la tranche verticale. Les critères d'acceptation sont une liste d'acceptation, que Claude transformera en tests un par un à l'étape /tdd.

Comment utiliser : Exemple de processus complet

Supposons que vous souhaitiez ajouter une fonctionnalité de commentaires à votre blog. Processus complet :

你: 我想给博客加评论功能
    ↓
/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 ……

L’ensemble du processus ne nécessite pas que vous vous asseyiez devant l’écran et que vous regardiez chaque détail. Les décisions clés sont prises lors de l’étape du grill.

Installation et prérequis

npx skills@latest add mattpocock/skills

Vérifiez to-prd, to-issues, setup-matt-pocock-skills.

Vous devez d'abord exécuter /setup-matt-pocock-skills - il écrira votre outil de suivi des problèmes (GitHub / GitLab / local markdown) et triera le vocabulaire des étiquettes dans AGENTS.md/CLAUDE.md, sinon to-prd et to-issues ne sauront pas où envoyer les problèmes.

Suivi des problèmes pris en charge :

• Problèmes GitHub (par défaut, utilise gh CLI)
• Problèmes GitLab (en utilisant glab CLI)
• Démarquage local (créer des fichiers sous .scratch/<feature>/) - adapté aux projets personnels ou aux projets sans télécommande
• Autres (Jira, Linear, etc.) - Utilisez un morceau de prose pour décrire le flux de travail, et la compétence sera appelée selon votre description

##FAQ

**Q : Il existe déjà un PRD prêt à l'emploi. Puis-je passer au prd et accéder directement aux problèmes ? ** R : Oui. /to-issues accepte une référence de problème en tant que paramètre ("Décomposer le problème n°42 en tranches verticales"), et il récupérera le contenu du problème, puis le découpera.

**Q : Mon projet n'utilise pas de suivi des problèmes, peut-il être utilisé ? ** R : Oui. Sélectionnez « Démarquage local » lors de l'installation et tous les problèmes deviendront des fichiers locaux comme .scratch/<feature>/001-foo.md.

**Q : Que dois-je faire si le PRD est trop long et que l'IA elle-même ne peut pas le gérer ? ** R : C'est un signe de granularité des tranches : le PRD doit être découpé en plusieurs PRD indépendants plutôt qu'en un seul PRD géant. Vous devriez le ressentir pendant la phase de grillage : si vous parlez du 50e numéro et que vous introduisez encore de nouvelles fonctionnalités, arrêtez-vous d'abord et coupez-les en deux PRD et faites-les par lots.

**Q : Comment l'agent AFK détecte-t-il automatiquement les problèmes ? ** R : Le dépôt de Matt ne fournit pas cette partie, et elle doit être coordonnée avec votre propre arrangement d'agent (par exemple, GitHub Actions déclenche Claude Code pour exécuter des problèmes). La chose la plus simple à faire est de faire un cron pour vérifier is:open no:assignee label:agent-ready toutes les heures.

La vraie valeur de ce processus

/to-prd et /to-issues ressemblent à de la « gestion de projet automatisée », mais Matt les place au cœur de son workflow pour une raison plus profonde :

Cela vous oblige à penser "Qu'est-ce qu'une petite chose complète". Lorsque vous êtes obligé de découper des fonctionnalités en tranches verticales, vous faites l'une des choses les plus difficiles en génie logiciel : trouver des coutures. La pensée elle-même a plus de valeur que ces deux compétences.

Et la taille de la tranche verticale est la taille que l’IA peut gérer en même temps. Laissez la taille de la tâche correspondre à la limite supérieure des capacités de l'IA - C'est le rythme fondamental de la collaboration avec LLM.

Ressources de référence

Article suivant : TDD : Utiliser la reconstruction rouge et verte pour forcer l'IA à faire de petits pas——Une fois le problème résolu, comment faire en sorte que l'IA réalise réellement de petits pas.