prd-taskmaster Phase 3 : Remise au Moule

Phase 3 : Remise au Moule

Skill déclaratif de phase. Invoqué par l'orchestrateur prd-taskmaster lorsque current_phase vaut HANDOFF. Jamais appelé directement par un utilisateur.

La règle d'or : détecter ce que l'utilisateur possède, recommander UN mode, offrir un choix structuré, dispatcher le mode choisi. Le Mode D ne s'exécute que sur tier=premium ; sinon c'est un teaser verrouillé.

Porte d'entrée

1. Appeler mcp__plugin_prd_go__check_gate(phase="HANDOFF", evidence={}) pour les diagnostics.

   check_gate est une porte de SORTIE : elle requiert user_mode_choice et plan_file_exists — tous deux produits par HANDOFF lui-même, c'est-à-dire des preuves pour avancer, pas pour entrer. Lors de la première entrée, ni l'un ni l'autre n'existe encore, donc un gate_passed: false ici est ATTENDU — les transitions légales de la machine d'état garantissent déjà une entrée légale.

   • Première entrée (aucune preuve encore) : noter le résultat et continuer avec la Procédure.
   • Ré-entrée : si la porte signale des violations, les rapporter et s'arrêter — elle protège contre la réexécution d'une phase terminée ou le saut depuis GENERATE.

2. Lire les sorties de GENERATE — .taskmaster/docs/prd.md, .taskmaster/tasks/tasks.json, .taskmaster/reports/task-complexity-report.json. Si l'un d'eux manque, le signaler et s'arrêter. La porte aurait dû l'attraper, mais par sécurité.

Liste de contrôle de la remise au moule

Copier dans la réponse avant d'exécuter la procédure :

LISTE DE CONTRÔLE HANDOFF :
- [ ] Capacités détectées (tier + indicateurs par capacité)
- [ ] Mode recommandé : ___ (raison : ___)
- [ ] Résumé affiché (emplacement du spec, nombre de tâches, capacités)
- [ ] Workflow de tâches ajouté à CLAUDE.md (idempotent)
- [ ] Sélecteur AskUserQuestion affiché (ou solution de repli en prose si hook-bloqué)
- [ ] Choix utilisateur dispatché (Mode A / B / C, ou D si tier=premium)
- [ ] Structure de debrief émise (optionnel, toléré silencieusement)
- [ ] Remise au moule terminée

Étape 1 : Détecter les capacités

MCP (recommandé) : mcp__plugin_prd_go__detect_capabilities()

CLI de repli : python3 script.py detect-capabilities

Retourne un champ tier ("free" ou "premium") plus des indicateurs par capacité. Signaux clés :

Capacité	Ce qu'elle permet
plugin superpowers	Modes A, C (brainstorm, plans, subagents)
task-master-ai (CLI ou MCP)	Mode B (boucle d'exécution native)
plugin ralph-loop	Mode C (boucle d'exécution itérative)
atlas-launcher MCP (sous licence)	Mode D — Atlas Fleet (tier=premium)
compétences atlas-loop / atlas-cdd	graines legacy du Mode D — remplacées par la détection d'atlas-launcher
Modèle de recherche (task-master ou MCP)	Recherche approfondie par tâche
MCP Playwright	Vérification navigateur de niveau S

Le Mode D (Atlas Fleet) se déverrouille uniquement sur tier: "premium" — c'est-à-dire un enregistrement MCP atlas-launcher sous licence détecté par detect_atlas_launcher(). Les compétences locales atlas-loop/atlas-cdd ne le déverrouillent PAS. Voir Étape 2 et la section Mode D ci-dessous.

Étape 2 : Recommander UN mode

Logique de décision (la première correspondance gagne) :

• superpowers + ralph-loop présents → Mode C (recommandé gratuit)
• superpowers seulement → Mode A (plan uniquement, pilotage manuel)
• task-master-ai seulement → Mode B (exécution automatique native)
• Repli → Mode A

Les modes d'outils externes (E–J : Cursor, RooCode, Codex, Gemini, CodeRabbit, Aider) sont proposés comme alternatives via le champ alternative_modes, pas comme recommandations principales. Le Mode D est recommandé ssi tier == "premium" ET le graphe de tâches se parallélise (>= 2 chaînes de dépendance indépendantes — vérifier la sortie de fleet-waves : toute vague avec >= 2 blocs). Premium + graphe sérial : recommander le meilleur mode gratuit et dire pourquoi ("vos tâches forment une chaîne de dépendance unique — Verified Loop est l'outil adapté ici") ; Fleet reste sélectionnable mais pas par défaut. Tier gratuit : le Mode D est un teaser Atlas Pro verrouillé, jamais sélectionnable, quels que soient les plugins locaux installés.

Mode A : Plan uniquement (manuel)

Recommandé : Plan uniquement
  superpowers:writing-plans crée votre plan d'implémentation
  Le plan référence les IDs de tâches TaskMaster de tasks.json
  Vous pilotez l'exécution manuellement

Mode B : Exécution automatique TaskMaster (Mode B — TaskMaster backend uniquement)

Recommandé : Exécution automatique TaskMaster
  MCP :  mcp__task-master-ai__next_task -> implement -> set_task_status(id, "done") (Mode B — TaskMaster backend uniquement)
  CLI :  task-master next -> implement -> task-master set-status --id N --status done (Mode B — TaskMaster backend uniquement)
  Boucle d'exécution native TaskMaster (aucun orchestrateur externe requis)

Mode C : Plan + Ralph Loop (Recommandé gratuit)

Recommandé : Plan + Ralph Loop
  superpowers:writing-plans → plan d'implémentation référençant les IDs de tasks.json
  ralph-loop enveloppe chaque tâche :
    next_task → set_task_status("in-progress") → recherche si <80% de confiance
    → développement piloté par sous-agent → porte d'exécution (preuves Niveau A+)
    → vérification post-doute → journal dans .claude/verification-log.md
    → set_task_status("done") → TodoWrite → répéter
  Achèvement : un agent de doute examine le journal de vérification avant que la promesse ne soit satisfaite.

Mode D : Atlas Fleet (sélectionnable sur tier=premium ; 🔒 teaser verrouillé sur gratuit)

🔒 Atlas Fleet                                          Atlas Pro · 29$/mois
  Exécution parallèle multi-session à travers Claude, Codex et Gemini :
    votre graphe de tâches divisé en vagues de dépendances de worktrees isolés
    fusions vérifiées par une passerelle dans une branche d'intégration, une PR finale
    collecte durable des résultats dans une boîte de réception (vérifiée, non racontée)
    fiche de preuve CDD par tâche ; un SHIP_CHECK_OK à la fin
    Partez, revenez pour la preuve.

  Déverrouillage : https://atlas-ai.au/pro   (les modes gratuits ci-dessus restent gratuits pour toujours)

Quand tier == "premium" (atlas-launcher sous licence détecté) : le Mode D est un mode réel et sélectionnable — son dispatching invoque /prd:execute-fleet (le skill orchestrateur de vagues). Afficher la carte déverrouillée :

▸ Atlas Fleet                     ★ Pro · licence active
  <N> vagues · estimé à partir de votre graphe de dépendances · mode "partez-revenez"

Quand tier == "free" : le Mode D est un teaser verrouillé — non sélectionnable, jamais exécuté. Si l'utilisateur le sélectionne alors qu'il est verrouillé, répondre par :

"Atlas Fleet fait partie d'Atlas Pro (29$/mois). Sur ce projet, il diviserait vos tâches en vagues parallèles à travers des worktrees isolés avec des fusions vérifiées par une passerelle et une PR finale. Déverrouillez-le sur https://atlas-ai.au/pro — votre spec et vos tâches sont sauvegardées. Pendant ce temps, tout le reste est gratuit pour toujours : veuillez choisir l'un des modes gratuits ci-dessous."

Ensuite ré-invoquer le sélecteur de mode (AskUserQuestion) avec le Mode D retiré des options.

Modes alternatifs E–J (outils IA externes)

detect_capabilities retourne alternative_modes lorsque ces outils sont installés. Les utilisateurs peuvent choisir n'importe lequel d'entre eux au lieu des Modes A–D. Tous sont des wrappers agnostiques autour du même .taskmaster/tasks/tasks.json.

Mode	Outil	Invocation
E	Cursor Composer	cursor --open .taskmaster/tasks/tasks.json, @-ref in Composer
F	RooCode	Pallette de commandes VS Code → RooCode: Run tasks.json
G	Codex CLI	`python3 script.py next-task
H	Gemini CLI	gemini --file .taskmaster/tasks/tasks.json implement next (gratuit via Google)
I	CodeRabbit	Implémenter via A–H, ouvrir une PR, CodeRabbit examine par tâche. Se combine avec d'autres modes.
J	Aider	aider --read .taskmaster/tasks/tasks.json — style programmation en binôme

Étape 3 : Ajouter le workflow de tâches à CLAUDE.md

Utiliser la sous-commande déterministe — ne pas faire de Lecture+Édition brute. Ce chemin est idempotent, prend une sauvegarde horodatée lors de la modification d'un fichier existant, et utilise des sentinelles en commentaire HTML pour que les ré-exécutions soient sans effet.

1. Le contenu du workflow est le même à chaque exécution — l'écrire dans un fichier temporaire :

   ## Workflow d'exécution des tâches (prd-taskmaster)
   
   Lors de l'implémentation des tâches, privilégier les opérations backend :
   1. `python3 script.py next-task` — obtenir la prochaine tâche prête
   2. `python3 script.py set-status --id <id> --status in-progress` — noter le trait d'union ; le souligné est rejeté
   3. Implémenter la tâche (suivre le plan lié à cette tâche)
   4. `python3 script.py set-status --id <id> --status done` — marquer comme terminée
   5. Mettre à jour TodoWrite avec la progression
   6. Répéter à partir de l'étape 1
   
   Statuts valides : `pending`, `in-progress`, `done`, `review`, `blocked`, `deferred`, `cancelled`.
   
   ### Suivi de la progression
   - Mettre à jour TodoWrite AVANT et APRÈS chaque tâche
   - Impossible de passer à la tâche suivante sans mettre à jour TodoWrite
   - TodoWrite = visibilité utilisateur. TaskMaster = source de vérité.
   

2. Exécuter la commande d'ajout. Pas d'aperçu en Plan Mode — la sous-commande elle-même est idempotente (les sentinelles en commentaire HTML verrouillent l'écriture), donc l'information est présentée à l'utilisateur via le résumé de l'Étape 4 et les options AskUserQuestion (Étape 5) avant le dispatching, pas via une boîte de dialogue de plan :

   python3 $SKILL_DIR/script.py append-workflow \
     --target ./CLAUDE.md \
     --content-file /tmp/pdtm-workflow-section.md
   

   La réponse JSON indique l'une des choses suivantes :

   • action: "created" — pas de CLAUDE.md préexistant, nouveau fichier avec marqueurs
   • action: "skipped" (reason: markers_present) — déjà configuré, sans effet
   • action: "appended" — CLAUDE.md existant inchangé sauf pour le bloc de marqueurs ajouté ; backup_path pointe vers CLAUDE.md.prd-taskmaster-backup-<ts>

   Si l'utilisateur souhaite un aperçu avant l'écriture, présenter le contenu prévu dans les options AskUserQuestion ou comme paragraphe d'information dans le résumé de l'Étape 4 — décrire ce qui serait écrit sans invoquer d'outil de dialogue de plan.

Étape 4 : Afficher le résumé

Générer le panneau de remise au moule et l'afficher : MCP render_status(phase="HANDOFF") → afficher rendered ; CLI python3 script.py status --phase HANDOFF. (Repli — émettre un bloc compact avant le sélecteur de mode pour que l'utilisateur ait tout le contexte :)

Spec généré : .taskmaster/docs/prd.md
Validation : <GRADE> (<score>/<max>)
Tâches : <nombre> tâches analysées avec dépendances (voir .taskmaster/tasks/tasks.json)
Complexité : analysée via TaskMaster (.taskmaster/reports/task-complexity-report.json)
Recherche : <développée|ignorée>

Capacités :
  [check] TaskMaster (MCP|CLI)
  [check|cercle] Playwright (vérification navigateur)
  [check|cercle] Fournisseur de recherche
  [check|cercle] Plugin Ralph-loop
  [check|cercle] Atlas Fleet (premium : sélectionnable · gratuit : verrouillé)

Étape 5 : AskUserQuestion obligatoire pour la sélection du mode

HANDOFF est le moment de l'action utilisateur. Les recommandations en prose sont optionnelles ; les appels d'outils ne le sont pas. Vous DEVEZ invoquer AskUserQuestion à cette étape. C'est une règle stricte — un repli en prose seul est un bug, pas un raccourci.

AskUserQuestion offre à l'utilisateur un choix explicite, structuré et lisible par machine. C'est l'enregistrement durable de la remise au moule. La sélection de l'utilisateur est journalisée par programme et les étapes aval dispatchent directement dessus — pas d'analyse d'affirmations en langage naturel, pas d'ambiguïté.

Séquence

1. Émettre un résumé de remise au moule couvrant :

   • Chemin du PRD + note de validation
   • Nombre de tâches + répartition de la complexité
   • Mode recommandé (A/B/C) + raison en une ligne
   • Modes alternatifs disponibles (E–J lorsqu'ils sont détectés, réduits sous "Utiliser un autre outil…")
   • Teaser 🔒 Atlas Fleet Mode D avec le prix Atlas Pro et l'URL /pro
   • Une description de "prochaine étape" limitée au mode recommandé (par exemple pour le Mode B : "exécuter task-master next" avec l'ID de la première tâche prête (Mode B — TaskMaster backend uniquement))

2. Appeler AskUserQuestion avec une question à options multiples listant chaque mode d'exécution disponible. Utiliser les noms visibles pour l'utilisateur (les IDs internes entre parenthèses sont pour ce skill uniquement — jamais montrés à l'utilisateur) :

   • Plan & Drive (Mode A) — obtenir le plan, l'implémenter vous-même
   • Auto-Execute (Mode B) — boucle native de TaskMaster, vérification légère
   • Verified Loop (Mode C) — boucle monophase avec passerelle de preuve (recommandé lorsque superpowers + un exécuteur de boucle sont présents)
   • 🔒 Atlas Fleet (Mode D) — Atlas Pro 29$/mois, parallèle multi-session
   • "Utiliser un autre outil…" — développe les alternatives applicables de E–J
   • "Montrez-moi plus de détails avant de décider" — revient au résumé de l'Étape 4

   Marquer le mode recommandé comme défaut (Atlas Fleet peut être le défaut uniquement lorsque tier=premium ET le graphe se parallélise). Sélectionner Atlas Fleet alors qu'il est verrouillé (tier gratuit) renvoie la réponse de mise à niveau (voir le bloc Mode D à l'Étape 2) et réinvite avec seulement les modes gratuits (plus toutes les alternatives applicables).

3. Dispatcher le mode choisi :

   • Remise au moule Mode A : invoquer superpowers:writing-plans avec le chemin du spec .taskmaster/docs/prd.md

   • Remise au moule Mode B (Mode B — TaskMaster backend uniquement) : afficher la commande task-master next + l'ID de la première tâche prête provenant de .taskmaster/tasks/tasks.json

   • Remise au moule Mode C : écrire .claude/atlas-loop-prompt.md décrivant le contrat d'exécution des tâches, puis invoquer /goal avec la condition :

     "SHIP_CHECK_OK a été émis par .atlas-ai/ship-check.py ET toutes les tâches dans .taskmaster/tasks/tasks.json ont le statut=done ET /sync a été invoqué dans cette session"

     La session /goal continue jusqu'à ce que l'évaluateur Haiku vérifie la condition. Chaque itération exécute le cycle execute-task en 13 étapes et vérifie la condition après l'étape 13. /sync DOIT être la dernière action avant que SHIP_CHECK_OK ne soit émis (selon la terminaison de execute-task). (Migré depuis /ralph-loop:ralph-loop le 2026-06-04 — l'évaluateur /goal intégré de Claude Code résout structurellement la pourriture de triple-vérification due au contrôleur qui porte différents chapeaux, identifiée lors de l'audit du 2026-06-03.)

   • Remise au moule Mode D (tier=premium) : invoquer /prd:execute-fleet — il gère la boucle de vagues, le dispatching des travailleurs, la vérification, les fusions et la terminaison SHIP_CHECK_OK. (tier gratuit : réponse de mise à niveau uniquement, réinvite)

Repli en cas de hook-bloqué (dégradation gracieuse)

Si PreToolUse:AskUserQuestion est bloqué par un hook (session automatisée / orchestrateur / fleet), replier vers un tableau d'options en prose préservant la même sémantique — étiquettes, descriptions, Mode D verrouillé)