Étape 2 · Décrire

`/pulse:us`

Écrire les user stories, rangées par groupe (un fichier par US, et le référentiel docs/user-stories.md), avec règles métier, exemples et critères d'acceptation (Étant donné / Lorsque / Alors), chacune vérifiée avant d'être déclarée prête, triées par ordre de réalisation, sauvegardées après validation.

Description

Une user story décrit un besoin du point de vue de l'utilisateur : « En tant que… je souhaite… afin de… ». Ses critères d'acceptation, écrits sous la forme Étant donné… Lorsque… Alors…, permettront de vérifier que l'IA a codé exactement ce que vous vouliez.

Pulse part de votre PRD. Il range d'abord les fonctionnalités en groupes, un par grand besoin (« Gérer les rendez-vous »), que vous validez. Puis il écrit chaque user story avec sa règle métier, un exemple concret et 2 à 4 critères, dont au moins un cas d'erreur ou un cas limite.

Chaque user story est vérifiée avant d'être déclarée prête : elle se réalise seule, elle est petite, chaque critère se voit à l'écran. Les cas limites que rien ne tranche deviennent des questions, une ou deux par groupe, posées une à une : un exemple concret de situation, et vous répondez avec vos mots. Enfin, Pulse trie les user stories dans l'ordre de réalisation.

US-001 · Prendre rendez-vous · taille S · dépend de : —
En tant que cliente, je souhaite choisir un créneau libre
afin de réserver ma coupe sans téléphoner.

Cas nominal : Étant donné le créneau de mardi 14 h libre,
lorsque Camille le choisit, alors il apparaît comme réservé.
Cas limite : Étant donné le créneau de mardi 14 h déjà pris,
lorsque Inès le choisit, alors on lui propose les créneaux voisins.

Une user story résumée, telle que Pulse la présente avant la validation.

Pourquoi l'utiliser

L'IA sait exactement quoi construire. Chaque critère décrit un résultat visible, que vous pourrez tester vous-même.
Les cas difficiles sont tranchés avant le code. Une annulation tardive, un doublon, un accès refusé : vous décidez, l'IA applique.
Vous avancez dans le bon ordre. Les user stories sont triées : d'abord celles dont les autres dépendent, puis par priorité.
Vous voyez qui a décidé quoi. Le tableau des règles indique « Décidé par vous » ou « Proposé par Pulse ».

Quand l'utiliser

1 Démarrer
2 Décrire
3 Préparer
4 Construire
5 Mettre en ligne
6 Être trouvé
7 À tout moment

Après /pulse:tech, et après /pulse:ui identite si vous choisissez l'apparence d'abord.
Avant /pulse:spec, qui détaille une user story à la fois.
Pour compléter vos user stories quand le PRD s'enrichit : les numéros existants sont gardés.

Comment la lancer

/pulse:us

Cette commande se lance sans rien après son nom.

Pulse lit votre PRD (à défaut votre brief, en le signalant), puis vous propose les groupes.

/pulse:us

Ce qu'elle produit

Fichier	À quoi il sert
`docs/user-stories.md`	Le référentiel : les groupes, le parcours de l'utilisateur, l'ordre de réalisation, et pour chaque groupe le tableau de ses user stories avec le lien vers leur fiche.
`aidd_docs/tasks/<groupe>/US-XXX-<nom>.md`	Une fiche par user story indispensable ou essentielle, rangée dans le dossier de son groupe : la phrase, la taille, les dépendances, la règle métier, l'exemple, les critères et ce qu'elle laisse de côté.

Les user stories optionnelles figurent seulement dans le référentiel ; leur fiche sera écrite par /pulse:spec quand vous les traiterez. Si votre mémoire de projet indique un outil de suivi des tickets (GitHub Issues, Jira, Linear…), Pulse y crée aussi un ticket par user story.

Risques et précautions

Rien n'est enregistré avant « Valider et sauvegarder ». Vous pouvez aussi contester une règle proposée par Pulse, ou modifier une user story.
Refaire garde le travail avancé. Les fiches qui ont déjà une spec ou un plan sont conservées ; Pulse vous le signale et vous demande.
Avec GitHub Issues, Claude Code vous demande d'autoriser la création des tickets : ils apparaissent en ligne, sur le site de votre dépôt.

Problèmes et solutions

Pulse me dit qu'il manque le PRD

Les user stories découpent la première version décrite dans docs/prd.md. Lancez /pulse:prd, puis relancez /pulse:us.

Pulse me demande de compléter ou de refaire

Des user stories existent déjà. « Compléter » garde leurs numéros et ajoute les nouvelles à la suite. « Refaire » réécrit tout, sauf les fiches qui ont déjà une spec ou un plan.

Je ne suis pas d'accord avec une règle

Choisissez « Contester une règle proposée par Pulse ». Pulse vous pose la question sous forme de scénario concret, corrige la user story et vous la présente à nouveau.

Une de mes idées a été coupée en deux

Une user story doit rester petite : une seule personne, une seule action, 4 critères au plus. Pulse découpe celles qui en font trop ; chaque morceau se teste seul.

Exemples

/pulse:us

Je propose deux groupes : « Gérer les rendez-vous » : prise de rendez-vous, rendez-vous du jour. « Prévenir les clientes » : rappel par e-mail. → Valider / Modifier les groupes

Valider

Une cliente annule une heure avant son rendez-vous : que se passe-t-il ? Chez un médecin, par exemple, le créneau redevient libre aussitôt.

Le créneau redevient libre.

Valider et sauvegarder

/pulse:us

docs/user-stories.md existe déjà. → Le compléter (les numéros sont gardés) / Le refaire

Le compléter

Nouvelle user story : US-004 Annuler mon rendez-vous, à la suite de US-003.

Commandes liées

/pulse:prd : décider de la première version, que les user stories découpent.
/pulse:ui : choisir l'apparence avant, pour que tout s'y conforme.
/pulse:spec : l'étape suivante, pour la première user story de l'ordre de réalisation.
/pulse:memory : indiquer votre outil de suivi des tickets.
/pulse:spirc : enchaîner spec, plan et réalisation d'une user story.