Quand la liste de features ne rentre pas dans le cycle, /scoping-cutting échange du scope contre une appetite fixe pour livrer le scooter plutôt qu’une demi-voiture. — Claude Skill
Une compétence Claude pour Claude Code par Refound — exécuter /scoping-cutting dans Claude·Mis à jour le 1 juin 2026
Réduisez le scope pour tenir une appetite fixe avec Shape Up, MVP et Wizard of Oz.
- Cadrage par appetite selon Ryan Singer et Jason Fried : fixer le temps, varier le scope, éviter les estimations
- MVP comme test d’hypothèse (Eric Ries) : réduire la feature au minimum qui valide une question, puis recouper
- Règle build-the-scooter (Eeke de Milliano) : livrer la petite chose end-to-end, pas un essieu sans roues
- Validation Wizard of Oz (Crystal W) : simuler la feature avec des humains avant d’écrire du code
- Critères kill circuit-breaker : si le travail n’a pas passé la colline à la fin de l’appetite, il meurt
Pour qui
Ce qu'il fait
Vous avez engagé une appetite 6 semaines et l’équipe dit qu’il en faut 10. /scoping-cutting applique le shaping Ryan Singer : pièces mobiles indispensables, coupe du reste, version qui rentre dans la boîte ou recommandation de tuer le projet.
Votre « MVP » a 14 features et n’a pas lancé. /scoping-cutting applique « couper en deux puis encore en deux » d’Eric Ries plus le check scooter d’Eeke de Milliano pour livrer une petite chose complète, pas une grande chose incomplète.
Vous allez construire un workflow automatisé sans être sûr que les utilisateurs le veulent. /scoping-cutting rédige un plan Wizard of Oz : Typeform, groupe Slack et stagiaires pendant une semaine, mesure de l’intention, puis décision build.
Vous êtes semaine 5 sur 6 et le travail n’est pas fini. /scoping-cutting lance le check « left side of the hill » de Jason Fried : si vous poussez encore en montée, le sujet meurt, pas d’extension, retour au shaping.
Fonctionnement
Collez la spec feature, le scope actuel et l’appetite (par exemple 6 semaines, 2 personnes)
Identifiez l’hypothèse centrale : la seule chose à valider ou livrer
Coupez la liste de scope en deux, puis encore en deux façon Eric Ries
Testez avec la règle du scooter : ce qui reste est-il une valeur autonome ou une moitié cassée ?
Recevez le plan de coupe, une alternative Wizard of Oz et les critères kill de fin de cycle
Exemple
Feature : team @-mentions Appetite : 6 semaines, 1 FE + 1 BE Scope actuel : créer équipes, @-mention, équipes imbriquées, présence par équipe, équipes externes, audit log, contrôles admin, UI tuning notifications, sync SCIM Statut : estimation engineering 10 semaines
Core : les utilisateurs veulent-ils vraiment ping une équipe entière plutôt qu’un canal ? Une métrique : % d’orgs actives qui utilisent @team dans les 4 semaines après GA.
Must-have (6 semaines) : ✓ créer équipe (plate) ✓ @-mention équipe ✓ notification respecte DND Coupé : ✗ équipes imbriquées (complexité double) ✗ présence par équipe (nice-to-have) ✗ équipes externes (scope sécurité) ✗ audit log (post-GA) ✗ UI contrôles admin (post-GA, defaults hard-codés) ✗ UI tuning notifications (defaults sains) ✗ sync SCIM (post-GA)
Créer équipe + @-mention + DND est-il une chose utile autonome ? OUI. Les utilisateurs accomplissent le job complet avec ces trois éléments. Tout le reste est « roues sur un essieu ».
Fin semaine 5 : → si create-team + @-mention + DND sont passés la colline, ship semaine 6 → si l’un des trois pousse encore en montée, la feature meurt, retour au shaping → pas d’extension « juste une semaine de plus »
Métriques améliorées
Compatible avec
Envie d'utiliser Cadrage et découpe ?
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 :
Scoping & Cutting
Aidez l’utilisateur à transformer une liste trop grande en version livrable et complète.
Comment aider
- Comprendre l’hypothèse - Ce que l’on veut apprendre ou valider.
- Identifier l’appetite - Temps et ressources réellement disponibles.
- Trouver le cœur essentiel - Ce qui doit exister pour une première version utile.
- Designer pour apprendre - Livrer vite sans casser la valeur end-to-end.
Principes clés
Fixez le temps et variez le scope. Un MVP doit tester une hypothèse, pas contenir toutes les envies. Coupez jusqu’à obtenir un scooter complet, pas une moitié de voiture. Si le travail ne passe pas la colline dans l’appetite, tuez ou reshapez.
Sortie attendue
Livrez hypothèse, appetite, liste must-have, coupes, alternative Wizard of Oz, risques et critères kill/ship.