Découpez le périmètre produit en user stories avec critères d acceptation clairs. — Claude Skill
Une compétence Claude pour Claude Code par Paweł Huryn — exécuter /write-stories dans Claude·Mis à jour le 13 juin 2026·vmain@d384f0c
Convertit fonctionnalités, designs et contexte PRD en user stories petites avec critères 3 C et INVEST, critères d acceptation testables, cas limites et notes de préparation sprint.
- Transforme périmètre de fonctionnalité et designs en stories testables.
- Applique les 3 C : Card, Conversation, Confirmation.
- Vérifie les critères INVEST pour garder les stories petites, utiles et estimables.
- Ajoute edge cases, liens design et notes de préparation QA.
Les tickets décrivent une fonctionnalité globale, mais l intention utilisateur, les critères de test et les cas limites restent implicites.
Lancez /user-stories pour produire des stories petites, indépendantes et testables avec critères d acceptation.
Pour qui
Ce qu'il fait
Transformer un périmètre feature en stories prêtes à être affinées.
Relier design, comportement attendu et critères d acceptation.
Ajouter cas limites et comportements observables avant développement.
Fonctionnement
Collecte fonctionnalité, PRD, designs, hypothèses et contraintes.
Identifie rôles utilisateurs, parcours et moments de valeur.
Rédige chaque story avec description, contexte et critères d acceptation.
Vérifie taille, indépendance, testabilité et dépendances.
Signale les questions ouvertes qui bloquent la préparation sprint.
Options d'entrée
Le périmètre à découper, y compris objectifs, contraintes et contexte.
Exemple
Fonctionnalité : checklist d onboarding pour nouveaux admins de workspace. Utilisateurs : admin de workspace, coéquipier invité. Design : lien Figma. Objectif business : faire passer l activation de 38 % à 55 %. Règles : afficher la checklist seulement pendant les 14 premiers jours; les tâches terminées ne doivent pas distraire les admins; le rappel d invitation peut être envoyé une fois par jour; l admin doit savoir ce qui bloque l activation; le support veut un event log quand les rappels sont envoyés.
Ne créez pas un gros ticket appelé “build onboarding checklist”. Découpez par parcours utilisateur : l admin comprend la progression, l admin rappelle les coéquipiers, le coéquipier accepte l invitation, le support voit l historique des rappels.
En tant qu admin de workspace, je veux voir quelles étapes de setup sont incomplètes afin de savoir ce qui bloque l activation. Critères d acceptation : 1. La checklist apparaît seulement pour les workspaces de moins de 14 jours. 2. Le bloqueur d activation actuel apparaît en premier. 3. Les tâches terminées sont marquées complètes et visuellement désaccentuées. 4. Si toutes les tâches sont complètes, l empty state explique que le setup est terminé. 5. La checklist est utilisable au clavier et avec lecteurs d écran.
En tant qu admin de workspace, je veux rappeler les coéquipiers invités depuis la checklist afin que le setup ne cale pas. Critères d acceptation : 1. Le bouton de rappel apparaît seulement pour les invitations en attente. 2. Un rappel peut être envoyé une fois par coéquipier et par jour. 3. L admin voit un message clair de succès ou d échec. 4. L activité de rappel est loggée pour Support. 5. Le bouton est désactivé avec explication après atteinte de la limite quotidienne.
En tant que coéquipier invité, je veux que le lien d invitation m amène directement au workspace afin de commencer à collaborer sans demander d aide à l admin. Critères d acceptation : 1. Une invitation valide ouvre le bon workspace. 2. Une invitation expirée explique ce qui s est passé et propose un chemin pour demander une nouvelle invitation. 3. Une invitation déjà acceptée redirige vers le workspace. 4. L acceptation met à jour la checklist admin dans la fenêtre de rafraîchissement attendue.
Ne pas inclure invitation CSV en masse, refonte des rôles/permissions ou provisioning SSO dans ce set de stories. Créer des items discovery séparés si nécessaire.
Prêt quand Product confirme la règle de visibilité 14 jours, Design confirme les empty states, Engineering confirme la limite de fréquence de rappel et Support confirme les champs d event log nécessaires.
Métriques améliorées
Compatible avec
Envie d'utiliser User stories ?
Choisissez comment commencer.
Installez et exécutez cette compétence localement sur votre ordinateur.
Ouvrez un terminal sur votre ordinateur et collez cette commande :
Cela télécharge la compétence avec tous ses fichiers sur votre ordinateur :
Ajoutez -g à la fin pour le rendre disponible dans tous vos projets.
Démarrez Claude Code, puis tapez la commande :
User Stories
Créer des user stories selon les 3 C (Card, Conversation, Confirmation) et les critères INVEST. Génère des stories avec descriptions, liens design et critères d acceptation.
À utiliser quand : rédiger des user stories, découper des fonctionnalités en stories, créer des backlog items ou définir des critères d acceptation.
Arguments :
$PRODUCT: nom du produit ou système$FEATURE: nouvelle fonctionnalité à découper en stories$DESIGN: lien vers les fichiers design (Figma, Miro, etc.)$ASSUMPTIONS: hypothèses clés ou contexte
Processus étape par étape
- Analyser la fonctionnalité à partir du design et du contexte fournis
- Identifier les rôles utilisateurs et les parcours distincts
- Appliquer le framework 3 C :
- Card : titre simple et one-liner
- Conversation : discussion détaillée de l intention
- Confirmation : critères d acceptation clairs
- Respecter les critères INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
- Utiliser un langage simple qu une personne sortie de l école primaire peut comprendre
- Lier les fichiers design comme référence visuelle
- Sortir les user stories dans un format structuré
Template de story
Titre : [Nom de la fonctionnalité]
Description : En tant que [rôle utilisateur], je veux [action], afin de [bénéfice].
Design : [Lien vers les fichiers design]
Critères d acceptation :
- [Critère clair et testable]
- [Comportement observable]
- [Le système valide correctement]
- [Gestion du cas limite]
- [Considération performance ou accessibilité]
- [Point d intégration]
Exemple de user story
Titre : Section consultés récemment
Description : En tant qu acheteur en ligne, je veux voir une section « Consultés récemment » sur la page produit afin de retrouver facilement les articles que j ai considérés.
Design : [Lien Figma]
Critères d acceptation :
- La section « Consultés récemment » s affiche en bas de la page produit pour chaque utilisateur ayant déjà consulté au moins 1 produit.
- Elle ne s affiche pas pour les utilisateurs visitant la première page produit de leur session.
- Le produit actuel est exclu des éléments affichés.
- La section montre des cartes ou miniatures produit avec images, titres et prix.
- Chaque carte produit indique quand elle a été consultée (par exemple « Consulté il y a 5 minutes »).
- Cliquer sur une carte produit mène l utilisateur à la page produit correspondante.
Livrables de sortie
- Ensemble complet de user stories pour la fonctionnalité
- Chaque story inclut titre, description, lien design et 4-6 critères d acceptation
- Les stories sont indépendantes et peuvent être développées dans n importe quel ordre
- Les stories sont dimensionnées pour un cycle de sprint
- Les stories référencent la documentation design liée
Lectures complémentaires
Documents de référence
name: user-stories description: "Créer des user stories selon les 3 C (Card, Conversation, Confirmation) et les critères INVEST avec descriptions, liens design et critères d acceptation. À utiliser pour rédiger des user stories, découper des fonctionnalités en backlog items ou définir des critères d acceptation."
User Stories
Créer des user stories selon les 3 C (Card, Conversation, Confirmation) et les critères INVEST. Génère des stories avec descriptions, liens design et critères d acceptation.
À utiliser quand : rédiger des user stories, découper des fonctionnalités en stories, créer des backlog items ou définir des critères d acceptation.
Arguments :
$PRODUCT: nom du produit ou système$FEATURE: nouvelle fonctionnalité à découper en stories$DESIGN: lien vers les fichiers design (Figma, Miro, etc.)$ASSUMPTIONS: hypothèses clés ou contexte
Processus étape par étape
- Analyser la fonctionnalité à partir du design et du contexte fournis
- Identifier les rôles utilisateurs et les parcours distincts
- Appliquer le framework 3 C :
- Card : titre simple et one-liner
- Conversation : discussion détaillée de l intention
- Confirmation : critères d acceptation clairs
- Respecter les critères INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
- Utiliser un langage simple qu une personne sortie de l école primaire peut comprendre
- Lier les fichiers design comme référence visuelle
- Sortir les user stories dans un format structuré
Template de story
Titre : [Nom de la fonctionnalité]
Description : En tant que [rôle utilisateur], je veux [action], afin de [bénéfice].
Design : [Lien vers les fichiers design]
Critères d acceptation :
- [Critère clair et testable]
- [Comportement observable]
- [Le système valide correctement]
- [Gestion du cas limite]
- [Considération performance ou accessibilité]
- [Point d intégration]
Exemple de user story
Titre : Section consultés récemment
Description : En tant qu acheteur en ligne, je veux voir une section « Consultés récemment » sur la page produit afin de retrouver facilement les articles que j ai considérés.
Design : [Lien Figma]
Critères d acceptation :
- La section « Consultés récemment » s affiche en bas de la page produit pour chaque utilisateur ayant déjà consulté au moins 1 produit.
- Elle ne s affiche pas pour les utilisateurs visitant la première page produit de leur session.
- Le produit actuel est exclu des éléments affichés.
- La section montre des cartes ou miniatures produit avec images, titres et prix.
- Chaque carte produit indique quand elle a été consultée (par exemple « Consulté il y a 5 minutes »).
- Cliquer sur une carte produit mène l utilisateur à la page produit correspondante.
Livrables de sortie
- Ensemble complet de user stories pour la fonctionnalité
- Chaque story inclut titre, description, lien design et 4-6 critères d acceptation
- Les stories sont indépendantes et peuvent être développées dans n importe quel ordre
- Les stories sont dimensionnées pour un cycle de sprint
- Les stories référencent la documentation design liée