Usage quotidien¶

Rituel d'ouverture de session¶

Ouvrir Claude Code ou Copilot Chat à la racine du projet.
Le hook SessionStart injecte automatiquement .product/spiral-state.md comme contexte.
Premier prompt : Où en est-on ? ou #agent-coach-emergent fais un point.

L'agent doit répondre en citant :

L'objet actif et son statut.
La porte active.
Le prochain skill à invoquer.
Ce qui est LIVING vs COLD.

Si la réponse est vague, spiral-state.md est insuffisant — le compléter avant d'aller plus loin.

Commandes CLI les plus fréquentes¶

# Vue d'ensemble du registre
node .sdeg/sdlc/sdlc.js status

# Examiner les portes disponibles pour un objet
node .sdeg/sdlc/sdlc.js check BE-I

# Franchir une porte (après revue humaine)
node .sdeg/sdlc/sdlc.js move BE-I ENGAGE

# Consulter l'historique d'un objet
node .sdeg/sdlc/sdlc.js log BE-I

# Vérifier la cohérence du registre
node .sdeg/sdlc/sdlc.js validate

Invoquer un skill¶

Dans Copilot Chat (VS Code) :

#nom-du-skill

[Contexte spécifique, question, ou fichiers à analyser]

Dans Claude Code :

Utilise le skill .github/prompts/nom-du-skill.prompt.md

[Contexte]

Le catalogue complet est dans Skills et agent.

Les skills task-level en dev (v3)¶

Pendant us.DEV, une micro-machine d'états orthogonale (introduite en v3 par ADR-0009) pilote l'exécution tâche par tâche :

CHECK_STATUS → WORKING → VERIFY → COMPLETE → AWAITING_COMMIT → MARK_TASK_COMPLETE

#create-tasks décompose l'US en tâches atomiques (Example Mapping + SPIDR + INVEST + GWT) dans .claude/tasks.md.
#lightweight-task-workflow pilote la micro-SM ; préfixe chaque message par 🔵 STATE: X.
#task-check émet un verdict PASS/FAIL/NEED_INFO avant chaque VERIFY → COMPLETE.

Cette micro-SM ne touche jamais sdlc/schema.js ni sdlc-registry.json. Les transitions macro (US → LIVRE, G4) restent humaines via node .sdeg/sdlc/sdlc.js move.

Côté Claude Code natif, les mêmes skills sont packagés en plugin dans .claude/plugins/sdeg-task-level/ (installé par bootstrap.js, EN).

Bonnes pratiques¶

1. Toujours passer par le Coach pour décider de la porte suivante¶

#agent-coach-emergent

On vient de finir l'hypothèse de BE-I. Que fait-on maintenant ?

Le Coach identifie la porte suivante et propose le skill adapté. Évite de choisir soi-même un skill « au feeling ».

2. Relire le livrable avant `move`¶

Chaque skill produit un livrable dans .product/. Relire intégralement avant de franchir la porte. Un livrable IA bien structuré peut cacher :

Des affirmations fausses formulées avec assurance.
Des non-dits importants absents.
Des chiffres inventés présentés comme sourcés.

3. Mettre à jour `spiral-state.md` à chaque décision¶

Pas à chaque prompt — mais à chaque fois qu'un artefact change de chaleur (gelé) ou qu'une porte est franchie. Sinon, le fil se perd.

4. Committer les événements¶

Un événement dans .product/.events/ n'est utile que s'il est versionné. La CLI le commite automatiquement ; si vous l'aviez utilisée avec --no-git, penser à commiter manuellement avant fin de journée.

5. Profiter du hook `PreToolUse`¶

Quand vous éditez un fichier HTML destiné au COMEX, le hook bloque automatiquement l'usage de termes internes (EHS, LBC, invariant, KR). Ne pas essayer de le contourner — c'est une protection délibérée. Si le terme est légitime, réécrire en langage CODIR.

Anti-patterns à éviter¶

Anti-pattern	Conséquence	Remède
Éditer `sdlc-registry.json` à la main	Pre-commit hook bloque le commit ; si `--no-verify`, invariant cassé	Toujours passer par `sdlc/sdlc.js move`
Invoquer `#tdd-dev` avant d'avoir un Récit DOR	Le skill produit du code spéculatif ; dette technique	Compléter le Plan de fab FE (G3 : PRD + spec + plan-fab + USs INVEST) avant d'entrer en G4
Sauter `#prd-architect` entre G2 et G3	Le cadrage produit reste implicite dans `spec.md`, G3 échoue sur le check `prd-meta`	Passer la Feature en `PRD_EN_COURS` et invoquer `#prd-architect` avant la décomposition en USs
Claimer une tâche dev « terminée » sans `#task-check`	Régressions non détectées avant revue	Invoquer `#task-check` avant chaque `VERIFY → COMPLETE` dans la micro-SM intra-`us.DEV`
Multiplier les BE sans en faire avancer aucun	Backlog inflationnaire, aucune mémoire consolidée	Se concentrer sur 1-2 BE actifs maximum
Ignorer les avertissements NEEDS-REVIEW	Transitions sur données instables	Traiter les warnings avant `move`
Mettre à jour `spiral-state.md` seulement en fin de projet	La session IA suivante tourne à vide	Update à chaque décision
Copier/coller un prompt skill dans un éditeur	Perd le mécanisme d'invocation Copilot, pollue le chat	Invoquer avec `#nom-du-skill`

Fréquence recommandée¶

Action	Fréquence
`status`	Début de chaque session
`check <id>`	Avant chaque `move`
`move <id> <statut>`	À chaque décision consciente
Mise à jour `spiral-state.md`	À chaque décision consciente
`validate`	Avant chaque PR majeure, et en CI
`log <id>`	En revue, en rétro, en explication sponsor

Quand l'IA dévie¶

Symptômes courants :

Elle propose des move que vous n'avez pas demandés.
Elle rédige un livrable pour une porte qui n'est pas active.
Elle invente un identifiant de skill inexistant.

Réponse immédiate :

Ne pas exécuter la commande.
Rappeler le contexte : « La porte active est P. Tu produis un livrable prévu par cette porte, pas un autre. »
Si la dérive persiste, revenir au Coach : #agent-coach-emergent rappelle-moi où nous en sommes.

Voir aussi : Première session · Dépannage · Skills.