Meneuse

En-tête — première ligne de chaque sortie, seule : VII · LE CHARIOT — meneuse

Voix — avant la première sortie, lire ${CLAUDE_PLUGIN_ROOT}/ressources/voix.md.

Racine — ${CLAUDE_PLUGIN_ROOT} est le dossier du plugin ulk ; dans tout fichier lu ensuite, ${CLAUDE_PLUGIN_ROOT} désigne ce même dossier.

meneuse — enchaînement d’agents en une passe

Références : ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/context-protocol.md · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/update-protocol.md · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/agent-teams.md · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/cli-tools-protocol.md

Orchestrateur multi-mode qui lance des workflows complets selon le besoin.

Actions

Le corps garde le raisonnement et l’aiguillage. Chaque procédure vit dans un fichier d’action, lu à la demande, un seul à la fois — jamais l’ensemble de ${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/ d’un coup.

#	Action	Fichier
01	Phase 0 : Todo Check (Universelle — tous les modes)	${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/01-todo-check.md
02	Mode: REVIEW (review)	${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/02-mode-review.md
03	Mode Agent Teams (expérimental)	${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/03-mode-agent-teams.md

Outils

CLI (prioritaire)

• gh : gestion GitHub (PR, issues, releases)
• vercel : déploiement et gestion Vercel
• neonctl : gestion base de données Neon

MCP (fallback si CLI absent)

• Figma MCP : extraction design tokens (pas de CLI complet disponible)
• Notion CLI : notion (brew install notion-cli + notion auth) — fallback MCP si absent — voir ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/notion-protocol.md
• Linear MCP : opérations GraphQL (pas de CLI officiel)

Vérification

Avant d’utiliser un outil externe, toujours :

1. command -v <tool> pour vérifier la présence
2. Si absent, vérifier /mcp pour un MCP configuré
3. Si ni l’un ni l’autre : continuer sans, lister le manque, et renvoyer vers ulk:outils pour la commande d’installation

Modes

Mode	Invocation	Workflow
audit	audit-complet	spec → [code+perf+a11y] → todo → report
legacy	legacy-revival	spec → audit → [simplify+perf] → fix → doc
release	pre-release	context → [audits] → fix → tests → GO/NO-GO
review	review	prompt → extraction → matrice complétude → Code Review natif → gaps → todo
ship	meneuse	simplify → doc → sync → README → release
frontend	frontend / suite frontend	DA (fondeuse) → [mouleuse + facadiere + portraitiste] → rapport UI

Pas de pipeline de code propre. Plan → code → vérification d’une tâche : journaliere → peseuse, toujours. journaliere est l’exécutante, peseuse la contrôleuse — ${CLAUDE_PLUGIN_ROOT}/skills/bruce/SKILL.md § SDLC ulk. Meneuse enchaîne audits, docs et release ; les tâches de code que ses modes produisent (gaps de review, correctifs de legacy, todo d’audit) sont rendues à Bruce pour cette boucle. Le mode review sur une seule issue n’est pas une matrice de plus : c’est peseuse.

---

Phase 0 : Todo Check (Universelle — tous les modes)

La vérification du todo qui précède tout workflow, quel que soit le mode. Elle résout DOC_MODE : issues par défaut (backlog = issues GitHub), obsidian si docs/spec.md/docs/todo.md existent.

À charger en premier, sans exception : c’est ce qui empêche de lancer un pipeline sur un backlog périmé.

→ ${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/01-todo-check.md

Mode: AUDIT (audit-complet)

Audit exhaustif d’un repository.

Workflow

1. Phase 1 (SEQ): greffiere mode=spec → issue spec (mode issues) ou docs/spec.md (mode obsidian)
2. Phase 2 (PARALLEL): recenseuse (audit complet — code, architecture, performance) + portiere + serruriere (sécurité)
3. Phase 3 (SEQ): Consolidation → greffiere mode=todo
4. Phase 3.5 (SEQ): skill /claude-md-improver → audit CLAUDE.md (score, optimisations)
5. Phase 4: Rapport docs/reports/audit-summary-YYYY-MM-DD.md

Note serruriere : tourne en sous-agent isolé (Task tool, patron de ${CLAUDE_PLUGIN_ROOT}/skills/bruce/SKILL.md § Invocation des sous-agents), son rapport remonte dans docs/audits/serruriere-YYYY-MM-DD.md. Seul le résumé (score + blockers) est intégré au rapport consolidé Phase 4 — le contexte principal n’absorbe pas les 50-100K tokens de l’audit complet.

Output

Métrique	Score	Source
Code	X/10	recenseuse
Performance	X/10	recenseuse — axe performance
Accessibilité	X/10	portiere — audit d’accessibilité WCAG
Sécurité	X/10	serruriere — 10 axes OWASP
CLAUDE.md	X/10	skill /claude-md-improver

---

Mode: LEGACY (legacy-revival)

Remise à niveau d’un projet legacy.

⚠️ Sessions longues : Le mode legacy implique souvent des sessions longues (5-6 phases). Insérer un eclusiere health check entre les phases 3 et 4 si le contexte dépasse 40 % (zone orange d’eclusiere).

Workflow

1. Phase 0b (OPT): restauratrice → reverse documentation complète (si demandé ou si aucune doc n’existe)
   • Produit docs/rewrite/ : cahier des charges, doc technique, doc user, user stories, glossaire, architecture
   • Recommandé si le projet n’a quasiment aucune documentation
2. Phase 1 (SEQ): greffiere mode=spec → archéologie du projet (peut exploiter docs/rewrite/ si Restauratrice a tourné)
3. Phase 2 (SEQ): recenseuse → diagnostic legacy
4. Phase 3 (PARALLEL): /simplify (bundled natif) + recenseuse (axe performance) 3b. Checkpoint contexte : Si Automemory eclusiere disponible et context_zone == “red” (> 60 % mesurés) → proposer /clear et reprendre
5. Phase 4 (SEQ): ravaudeuse → corrections
6. Phase 5 (SEQ): greffiere mode=sync + greffiere mode=todo
7. Phase 6: Rapport avant/après

Questions Pré-Revival

Ne poser que celles que le contexte ne tranche pas — via AskUserQuestion, une question par appel, l’option recommandée en premier :

1. Revival complète ou parties critiques ?
2. Reconstituer toute la documentation d’abord (Restauratrice) ? Ou spec seulement (greffiere mode=spec) ?
3. Tests existants ? Créer tests d’abord ?
4. Breaking changes acceptés ?
5. Priorité : stabilité, performance, maintenabilité ?

---

Mode: RELEASE (pre-release)

Checklist complète avant release avec verdict GO/NO-GO.

Workflow

1. Phase 1 (SEQ): Détection contexte (si la spec existe — issue spec en mode issues, docs/spec.md en mode obsidian — skip greffiere mode=spec)
2. Phase 2 (PARALLEL):
   • recenseuse (audit complet — code, architecture, performance) + portiere + serruriere (audits full codebase)
   • /code-review (review du diff ou de la PR — bugs, erreurs silencieuses)
3. Phase 3 (SEQ): ravaudeuse si blockers → tests
4. Phase 4 (SEQ): Vérification docs (CHANGELOG, version)
5. Phase 4.5 (SEQ, conditionnel): Checkpoint outcome — si des issues fermées (Closes #n) portent un ## Outcome dans leur corps, cartographe mode=advise donne un avis produit (« cet incrément sert quel outcome — est-il atteint / mesurable / en régression ? »). Consultatif, non-bloquant — n’entre pas dans les critères GO/NO-GO. Voir ${CLAUDE_PLUGIN_ROOT}/skills/bruce/SKILL.md § Mode Ship.
6. Phase 5: Checklist interactive
7. Phase 6: Verdict GO/NO-GO

Distinction : les audits (Phase 2a) analysent le codebase entier ; /code-review (Phase 2b) analyse le diff des changements récents. Les deux sont complémentaires. Note serruriere : tourne en sous-agent isolé (Task tool, même patron) → rapport dans docs/audits/serruriere-YYYY-MM-DD.md. Seuls les blockers CRITIQUE remontent dans le verdict GO/NO-GO.

Critères GO/NO-GO

Verdict	Conditions
✅ GO	Build pass, tests critiques pass, 0 blocker sécurité (serruriere CRITIQUE = 0)
⚠️ WARNINGS	Tests > 95%, perf légèrement hors target, findings sécurité HAUTE uniquement
❌ NO-GO	Build fail, tests critiques fail, ≥1 blocker sécurité serruriere CRITIQUE

Checkpoint cartographe (Phase 4.5) : purement consultatif. L’avis produit oriente la lecture du verdict mais ne le détermine pas — le GO/NO-GO reste fondé sur build / tests / sécurité. Un doute produit se note en WARNING, jamais en NO-GO automatique.

---

Mode: REVIEW (review)

La revue de complétude du code face à un prompt, une spec ou un cahier des charges — le mode le plus long de Meneuse.

À charger sur demande de review. Ne charger que l’étape en cours.

→ ${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/02-mode-review.md

Mode: SHIP (meneuse)

Livraison rapide en une commande.

Workflow

1. Phase 1: /simplify (bundled natif)
2. Phase 2: greffiere mode=spec + greffiere mode=todo + CHANGELOG
3. Phase 2.5 (conditionnel): greffiere (docs — si major ou >5 fichiers docs)
4. Phase 3: traductrice (sync Linear)
5. Phase 4: greffiere mode=sync (README + CLAUDE.md) + skill /claude-md-improver (audit + optimisation)
6. Phase 5: Build + tests + version bump + tag
7. Phase 6: /commit-push-pr — commit final + push + création PR

Phase 6 : Le plugin /commit-push-pr (commit-commands) gère automatiquement : création branche si sur main, commit, push, PR via gh pr create avec description et test plan.

Checkpoint outcome (optionnel, avant Phase 6) : hors mode express, si des issues fermées (Closes #n) portent un ## Outcome dans leur corps, proposer cartographe mode=advise (« cet incrément sert quel outcome ? ») avant le commit final. Non-bloquant — express le saute toujours (flux fire-and-forget). Voir ${CLAUDE_PLUGIN_ROOT}/skills/bruce/SKILL.md § Mode Ship.

Sous-modes

Commande	Comportement
meneuse	Standard avec checkpoints
meneuse express	Minimal de questions
meneuse --with-docs-cleanup	Force Phase 2.5

---

Mode: FRONTEND (suite frontend)

Orchestration de la suite frontend complète (design → composants → audit UI) : point d’entrée unique pour « frontend » / « suite frontend » routé par bruce (point d’entrée d’ulk).

Workflow

1. Phase 1 (SEQ): fondeuse (crée le design system) → direction artistique + docs/design.md (source de vérité design)
   • Skip si docs/design.md existe déjà et qu’aucun re-design n’est demandé
2. Phase 2 (PARALLEL): audits/génération frontend sur fichiers de sortie disjoints
   • mouleuse → composants shadcn/Figma conformes au design system
   • facadiere → audit UI + cohérence shadcn/tailwind
   • portraitiste → screenshots + audit a11y automatisé
3. Phase 3 (SEQ): Rapport UI consolidé docs/reports/frontend-YYYY-MM-DD.md

Garante design : coloriste reste la gardienne du design system (hors orchestration meneuse) — fondeuse génère, coloriste arbitre. Voir ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/design-source-protocol.md. Note : les 3 agents Phase 2 écrivent dans des rapports distincts → pas de conflit.

---

Patterns Communs

Passage de Contexte

Tous les modes utilisent le bloc CONTEXTE PROJET extrait de la spec (issue spec, ou docs/spec.md en mode obsidian) :

• Économie de tokens
• Agents skip la reconnaissance
• Cohérence entre agents

Exécution Parallèle

Agents indépendants lancés en parallèle :

• Gain de temps
• Pas de conflit : fichiers de sortie différents

Gestion d’Erreurs et Recovery

Situation	Action	Recovery
Agent échoue (timeout)	Logger l’erreur, demander si continuer	Relancer l’agent avec un scope réduit
Agent échoue (erreur)	Logger, afficher l’erreur	Sauter l’agent, noter dans le rapport, continuer
greffiere mode=spec échoue	Le reste du workflow en dépend	Relancer greffiere avec moins de fichiers ; second échec → arrêter et le dire
greffiere mode=todo échoue	Tâches non créées	Relancer greffiere mode=todo sur la spec existante ; second échec → continuer sans, et le noter dans le rapport
Audits parallèles : 1/3 échoue	Les 2 autres sont valides	Utiliser les 2 rapports réussis, noter l’audit manquant, proposer relancer
Build fail	Code potentiellement cassé	Lancer ravaudeuse sur la sortie du build
Tests fail	Régressions possibles	Lancer ravaudeuse ; AskUserQuestion seulement si le correctif touche au comportement voulu, « corriger (recommandé) » en premier
Conflit entre audits	Deux audits trouvent des recommandations contradictoires	Lead décide : prioriser sécurité > perf > style
Contexte mesuré > 60 % (/context)	Risque de context rot	Proposer /clear et reprendre, ou eclusiere health check

---

Agents Orchestrés

Agent	Utilisé par
greffiere mode=spec	audit, legacy, ship
greffiere mode=todo	audit, legacy, ship
greffiere mode=sync	legacy, ship
portiere — audit d’accessibilité WCAG	audit, release
recenseuse — axe performance	audit, legacy, release
serruriere	audit, release
interprete — audit UX générationnel	audit (sur demande — adéquation générationnelle)
ravaudeuse	legacy, release, ship
greffiere (docs)	ship
/simplify (natif)	legacy, ship
traductrice — release notes, sync Linear	ship
cartographe mode=advise	release, ship (checkpoint outcome — consultatif, non-bloquant)
skill /claude-md-improver	audit, ship
fondeuse · mouleuse · facadiere · portraitiste	frontend

---

Amorçage via Prompt Library

Catalogue : ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/prompt-library.json (52 prompts, généré) · protocole : ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/prompt-library-protocol.md.

À l’entrée d’un mode, meneuse lit ulk_phase + ulk_agents du catalogue pour proposer le prompt canonique d’amorçage de chaque étape avant de déléguer. Slots {nom} remplis avec le contexte projet (jamais de {path} littéral), injectés dans le CONTEXTE PROJET: du sous-agent. Catalogue = source unique : lu, jamais dupliqué. ≠ Dynamic Workflows (catalogue de formulations).

---

Commandes Rapides

# Audit complet
audit-complet

# Revival legacy
legacy-revival

# Check pre-release
pre-release

# Review complétude vs spec/prompt
review
review docs/spec.md          # mode obsidian ; en mode issues : review #<n° issue spec>
review #42                    # GitHub issue
review "Implémenter auth..."  # Prompt libre

# Ship it!
meneuse
meneuse express

---

---

Mode Agent Teams (expérimental)

Le mode expérimental Agent Teams, sa variable d’activation et ses limites.

À charger seulement si CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 est posé — sinon il n’y a rien à orchestrer.

→ ${CLAUDE_PLUGIN_ROOT}/skills/meneuse/actions/03-mode-agent-teams.md

Fable Mode — discipline d’exécution étagée

Skill externe fable-mode (mrtooher, registry — /ulk:outils). Réfèrent : ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/fable-mode-protocol.md.

Sur tout mode multi-agents (audit / legacy / release / ship), invoquer fable-mode pour cadrer le run : étager les phases en un plan écrit vivant, déléguer en parallèle les sous-travaux indépendants (les audits le sont par nature), et vérifier chaque retour avec un check failable avant consolidation (« le rapport existe et couvre ses N axes », pas « ça a l’air complet »). Auto-critique sceptique du rapport consolidé avant livraison. Pour les phases volumineuses, fable-sonnet/fable-haiku portent le pinning de modèle côté skill. Ne pas doubler avec un Dynamic Workflow déjà en cours.

---

Lancer en parallèle les agents indépendants (subagents ou Agent Teams), passer le contexte entre phases, consolider les résultats.