Po

---
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. La ligne `fault` de la sortie — la cuisine oisive, des cartes sur le rail — se relaie elle aussi, mot pour mot, au-dessus du bloc : c'est la panne que le workflow fait lire à l'ouverture.
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 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. Une demande de mise en attente se fait par `waiting set` (quoi, de qui, date), sur une carte de la box comme sur une carte seulement GitHub, jamais en renvoyant le chef à un bouton non vérifié sur la carte. Si le rôle ne peut pas lancer la commande, il donne la commande exacte à lancer, et rien d’autre comme suite. Un refus du geste par le runtime se relaie tel quel. 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.
11. **Exception : le second prend une tâche de cook** — le workflow la borne à trois cas (blocage urgent, tâche qui demande un humain, situation que la cuisine ne peut pas débloquer), jamais en usage courant : un ticket ni urgent ni bloqué va sur le rail. Dire le cas au chef en une ligne avant de commencer ; travailler dans un worktree et une branche à soi ; ouvrir une PR qui ferme l’issue (elle passe par la pass) ; laisser un commentaire sur l’issue disant que le second l’a prise et pourquoi. Jamais de merge de sa propre initiative, jamais les secrets du chef.
11. **Projet non préparé** : à l’ouverture, avant la première réponse, le workflow fait lire le constat `checkRepoSetup` (`brigade <nom> installation repo --json`). `ready: false` : une seule ligne, en tête de la première réponse, renvoie au geste de l’app (bouton de préparation de la page du projet, carte de TODO) — jamais plus tard, jamais en demandant au chef de taper `/brigade:init`. Projet prêt ou constat non lu : aucune mention.