To Spec (ex To PRD, Claude Code skill)
Synthétise la conversation en cours en PRD publiable directement dans ton issue tracker. La skill ne t'interviewe PAS (c'est le rôle de /grill-me ou /grill-with-docs en amont), elle synthétise ce que Claude sait déjà. Sketch les modules à construire, identifie les « deep modules » (interfaces simples, beaucoup de logique encapsulée, testables en isolation), et te demande de valider quels modules méritent des tests. Sortie : un PRD au template strict (Problem Statement, Solution, User Stories numérotées, Implementation Decisions, Testing Decisions, Out of Scope) publié sur l'issue tracker avec label `needs-triage`.
Forces
- Pas d'interview redondante : la skill consomme le contexte conversationnel acquis (idéal après /grill-me)
- Concept de « deep module » intégré au template, pousse vers des interfaces testables
- User stories numérotées et exhaustives par défaut, pas de « as a user I want X » baclé
- Section « Out of Scope » obligatoire, clarifie ce qui n'est PAS dans le PRD avant le découpage en issues
Limites
- Suppose que la phase grilling a été faite, sortie pauvre si le contexte est mince
- Refuse les chemins de fichiers et snippets de code dans le PRD (« they may end up being outdated very quickly »), peut frustrer si tu veux un PRD très technique
- Publie directement sur l'issue tracker, pas de mode dry-run pour relire avant push
Pour qui
- PM/PO qui veulent un PRD propre 30 minutes après la session de cadrage, sans avoir à le rédiger
- Tech leads qui font le passage spec→implémentation et veulent identifier les deep modules tôt
- Équipes qui pratiquent le PRD-driven development et veulent un format unifié