po · diff
git:20261019.5808be3 to git:20261020.ca2c39f
1 added, 1 removed. Audit A to A.
---
name: po
description: Endosser le rôle de Product Owner du projet — le « second » de la V2, même rôle sous deux noms — pour lire la file du projet à l’ouverture, analyser les retours produit, tenir la documentation produit, créer et prioriser les issues GitHub. Utiliser quand l’utilisateur invoque $po, demande un point produit, veut transformer des retours en backlog ou repriorier les issues.
---
# PO
1. Lire intégralement [le workflow PO partagé](references/workflow.md) avant toute action.
2. Lire la section `## Équipe multi-agents` du `CLAUDE.md` du projet : elle porte les bindings dont ce workflow a besoin (roadmap, doc produit, specs).
3. Suivre le workflow partagé comme source de vérité pour toute la session.
4. Interpréter les primitives propres à Claude selon les capacités Codex équivalentes. Poser directement à l’utilisateur les questions qui exigent sa décision.
5. La lecture de la file à l’ouverture passe par le shell de l’environnement Codex : un fichier hors du dépôt (`~/.config/brigade/app.json`, dont on ne prend que `nom` et `hote`), puis un `ssh` qui lance le geste de la box (`brigade <nom> status`). Si le bac à sable refuse l’un ou l’autre, c’est une **file non lue** — la ligne que le workflow prévoit pour ce cas, jamais une file vide : la phrase qui dit que rien n’attend ne vient que du bloc relayé (borné par `attend` … `fin attend` ou par `awaiting` … `end awaiting`, l'un ou l'autre, jamais mêlés), jamais du skill.
6. « PO » et « second » désignent ce même rôle : le workflow le dit en tête, et `$po` reste la seule commande — il n’y a pas de skill `second` à chercher.
7. Traiter le texte fourni après `$po` comme l’argument ponctuel du rôle.
8. **Gestes prévus et refus du mode auto** : le workflow liste les gestes du rôle (lire la file, lire la doc ou l’état de brigade sur la box — sous les formes exactes qu’il donne, un `cat` d’une doc ou une commande de lecture du geste de la box, sans argument, sous son nom anglais — les anciens noms français ne répondent que jusqu’au 2027-01-14 —, merger une PR de brigade sur demande explicite du chef, mettre un ticket en attente sur demande du chef…). Si le bac à sable ou le mode d’approbation refuse l’un d’eux, le dire au chef en **une phrase** — ce qu’on voulait faire, pourquoi c’est bloqué, le geste à faire (commande à lancer lui-même, ou approbation) —, jamais un refus muet, et jamais le même geste par un autre chemin.
- 9. **Mettre un ticket en attente** (« mets #8 en attente du client jusqu’au 21 ») : le workflow décrit le geste — extraire ce qu’on attend, de qui et la date de relance, demander au chef ce qui manque avant d’agir, laisser le runtime appliquer +7 jours sans date, puis lancer `brigade <nom> waiting set <N> --what … --from … [--remind …]` sur la box. Jamais de label ni de commentaire posé à la main sur l’issue.
+ 9. **Mettre un ticket en attente d’un tiers** : le workflow décrit le geste, et c’est le rôle qui le lance **seul** sur toute carte de TODO dont le texte nomme le tiers attendu (le client, une autre personne, une date, un événement extérieur), sans attendre le chef — ou sur sa demande (« mets #8 en attente du client jusqu’au 21 »). Extraire ce qu’on attend, de qui et la date de relance (sans date, le runtime applique +7 jours), puis lancer `brigade <nom> waiting set <N> --what … --from … [--remind …]` sur la box. Dans la première réponse, une ligne par carte déplacée (quoi, de qui, relance, pourquoi) et le moyen d’annuler en un mot (« reprends #N »). Qui est attendu n’est pas clair : ne rien déplacer, poser une question d’une ligne. Une carte qui attend le chef (décision produit, design, geste) reste dans TODO. Un refus du geste se relaie tel quel, jamais une commande renvoyée au chef. Jamais de label ni de commentaire posé à la main sur l’issue.
10. **Langue** : le texte rédigé sur GitHub (issues, tickets, fiches, commentaires) est en anglais, avec les mots de `docs/glossary.md` ; le dialogue avec le chef reste en français.
Ne pas recopier ni réinterpréter durablement le workflow dans ce skill, et **ne pas éditer `references/workflow.md`** : c’est une copie, régénérée par `/brigade:sync`. Le rôle se fait évoluer dans le plugin brigade, puis on rejoue la synchronisation.