xallindrome-labs/claude-code-ops

/runway

Objectif : toutes les questions sont posées maintenant, pour que rien ne doive être demandé au tour 40. Ensuite, l'utilisateur approuve un plan unique et s'éloigne ; son téléphone n'est sollicité qu'aux points d'arrêt.

Règles fondamentales (l'utilisateur peut avoir les siennes dans CLAUDE.md ; les siennes priment) :

• Le travail local et réversible (éditions, builds, tests, commandes locales, commits sur une branche ou un worktree) s'exécute sans demander.
• Toujours s'arrêter pour : push ou déploiement, envoi d'un message, soumission d'une candidature, dépense d'argent, suppression de données, publication de quoi que ce soit en public.
• Utiliser des modèles de sous-agents moins chers pour les tâches volumineuses (recherches, exécutions de tests, tri de logs) ; le meilleur modèle uniquement pour la conception et le débogage difficile.

0. Pré-vol (silencieux, aucune question)

• Trouver la racine du dépôt et son état : git status, branche courante, un SPEC.md existant, les scripts de test et de build (package.json, Makefile, etc.). Trouver les faits est votre travail, pas celui de l'utilisateur.
• Vérifier si les approbations téléphoniques sont actives. Elles le sont si soit ~/.claude/settings.json a un hook PermissionRequest exécutant phone-approve.js, soit le hook de ce plugin est activé, et ~/.claude/phone-approve.json existe. Si ce n'est pas le cas, informer l'utilisateur une fois (configuration : exécuter node "${CLAUDE_PLUGIN_ROOT}/hooks/phone-approve.js" --init, puis s'abonner au sujet de requête dans ce fichier avec l'application ntfy) et continuer ; les points d'arrêt tombent alors dans la boîte de dialogue du bureau.
• Vérifier que les commandes aux points d'arrêt sont forcées à demander une confirmation, car le mode automatique pourrait autrement les approuver sans notification. Rechercher dans les paramètres utilisateur, projet et locaux les règles permissions.ask (ou deny) couvrant git push, les commandes de déploiement de ce dépôt (vercel, aws s3 sync, cdk deploy, npm publish, gh release, gh pr merge), et les commandes de suppression (rm -r, git clean, git branch -D). Si des règles manquent, proposer les règles spécifiques, montrer le diff, et ne les ajouter que si l'utilisateur dit oui (le fichier examples/permissions-ask.json du plugin est un point de départ). Ne jamais ajouter de règles allow pour les outils d'envoi, de publication ou de déploiement, et jamais Bash(*).

1. Entretien jusqu'à ce que le cahier des charges soit complet

Si une compétence grilling ou grill-me est installée, l'appeler et l'exécuter sur cette fonctionnalité ; ses règles s'appliquent intégralement. Sinon, mener l'entretien vous-même comme suit : poser des questions par tours ; chaque tour contient toutes les questions dont les prérequis sont déjà établis, chacune numérotée, chacune avec votre réponse recommandée formulée de sorte que « oui » l'accepte. Attendre les réponses, recalculer ce qui peut maintenant être demandé, et répéter. Rechercher vous-même les faits environnementaux (utiliser un sous-agent pour les recherches volumineuses) et ne jamais demander à l'utilisateur quelque chose que vous pouvez trouver. Les décisions sont celles de l'utilisateur.

Si l'utilisateur a déjà mené une session de grillage sur cette fonctionnalité plus tôt dans la conversation et a confirmé une compréhension partagée, ne pas la répéter : réutiliser les réponses et ne poser que les questions des éléments de la liste de contrôle ci-dessous qui sont restés ouverts.

Continuer jusqu'à ce que rien ne reste ouvert sur l'ensemble des points suivants :

1. Objectif : une ou deux phrases, le résultat visible par l'utilisateur.
2. Périmètre : ce qui va changer (domaines, fichiers, surfaces).
3. Hors périmètre : ce qui ne doit pas être touché.
4. Critères d'acceptation : une liste de contrôle dont chaque élément peut être démontré vrai par la sortie d'une commande.
5. Commande de vérification : exactement une commande dont la sortie 0 signifie terminé (par exemple npm run lint && npm test && npm run build). Si elle n'existe pas, le cahier des charges inclut son écriture comme première tâche.
6. Points d'arrêt : parmi push / déploiement / envoi / soumission / dépense / suppression / publication, ceux que cette fonctionnalité atteindra, et ce que l'utilisateur attend à chacun (par exemple « pousser la branche, ouvrir une PR, ne pas fusionner »).
7. Décisions que vous prendriez autrement en cours de tâche : bibliothèques, noms, formes de données, copie, comportement aux limites. Demander maintenant, avec une recommandation.
8. Plafond de tours (60 par défaut) et toute préoccupation budgétaire.

Ne pas passer à la suite avant que l'utilisateur confirme une compréhension partagée.

2. Écrire SPEC.md et le commiter localement

Écrire SPEC.md à la racine du dépôt :

# <nom de la fonctionnalité>
## Objectif
## Périmètre
## Hors périmètre
## Critères d'acceptation
- [ ] ...
## Commande de vérification
`<une commande>`
## Points d'arrêt
| Action | Traitement attendu |
## Décisions déjà prises
## Plafond de tours
60

Créer une branche (git switch -c runway/<slug>), ou utiliser un worktree lorsque d'autres sessions éditent le même dossier, puis commiter uniquement SPEC.md. Ceci est local et réversible ; ne pas demander. Ne jamais pousser.

3. Une seule approbation de plan

Passer en mode planification et présenter un plan unique : étapes ordonnées, les étapes confiées à des sous-agents (et sur quel modèle), la commande de vérification, et les points d'arrêt avec leur traitement attendu. C'est la seule approbation avant l'exécution. Utiliser ExitPlanMode et demander à l'utilisateur de choisir « Oui, et utiliser le mode automatique ». (Le hook téléphonique ignore délibérément l'approbation du plan, donc l'utilisateur fait ceci à l'ordinateur.)

Si le mode automatique n'est pas actif après l'approbation, le dire et demander à l'utilisateur de l'activer. Ne pas exécuter la boucle en mode manuel.

4. Exécuter sous /goal avec un plafond de tours

Les commandes intégrées avec slash ne peuvent pas être invoquées par le modèle, donc terminer l'étape précédente en donnant à l'utilisateur une ligne à coller (remplir la commande réelle et le plafond) :

/goal <commande de vérification> se termine avec 0, chaque critère d'acceptation dans SPEC.md est coché avec une preuve dans le compte-rendu, et rien dans la liste hors périmètre de SPEC.md n'a été touché, ou s'arrêter après 60 tours

Si la session exécute déjà un objectif, /goal le remplace. L'évaluateur ne voit que le compte-rendu, donc pendant le travail : exécuter souvent la commande de vérification, afficher son résultat, et cocher les critères de SPEC.md avec des preuves. Signaler la progression par rapport au plafond de tours à chaque tour.

Pendant l'exécution :

• Ne pas poser de questions. Si quelque chose de non spécifié survient, choisir l'option la plus proche du cahier des charges, l'enregistrer sous « Décisions déjà prises », et continuer. Ne s'arrêter pour une question que si continuer atteindrait un point d'arrêt ou contredirait le cahier des charges.
• Commit le travail en petits commits sur la branche runway. Ne jamais pousser sans une approbation de point d'arrêt.
• À un point d'arrêt, effectuer l'appel normalement ; l'invite de permission est ce qui fait sonner le téléphone. Si elle est refusée, ne pas réessayer d'une autre manière : l'enregistrer, terminer ce qui n'en a pas besoin, et faire le rapport.
• Si 3 tours consécutifs ne progressent pas, s'arrêter et signaler ce qui vous a bloqué.

5. Terminer

Lorsque la vérification réussit (ou que le plafond est atteint), faire le rapport dans cet ordre :

1. Résultat : terminé / partiellement terminé / bloqué, plus la branche et tout lien vers une PR.
2. Statistiques de diff (git diff --stat <base>...HEAD).
3. Vérifié : critères prouvés, avec la commande et le résultat.
4. Non vérifié : critères non prouvés ou seulement partiellement ; tout élément sauté ou refusé à un point d'arrêt.
5. Sous-agents utilisés, sur quel modèle, et où un modèle plus petit a moins bien fonctionné.
6. Tours et coût approximatif utilisés par rapport au plafond.