31 hooks Claude Code sous-exploites — du DVD logo a l'orchestration multi-agents¶

Resume¶

@itseieio publie une demo virale (17K likes, 932K vues) d'un hook Claude Code qui affiche un logo DVD rebondissant pendant que Claude reflechit. La demo est fun, mais l'insight technique est ailleurs : dans les replies, il explique que "hooking into the thinking state is trivial" et pointe vers la doc officielle des hooks. Cette doc revele 31 hook events distincts organises en 5 categories (session, per-turn, agentic loop, async/background, additionnel). La plupart sont sous-exploites par la communaute et plusieurs sont directement applicables a l'orchestration multi-agents.

Analyse critique¶

Les 31 hooks — inventaire complet¶

Session-Level (3) : - SessionStart : demarrage/reprise de session - SessionEnd : fin de session - InstructionsLoaded : chargement de CLAUDE.md et .claude/rules/*.md

Per-Turn (2) : - UserPromptSubmit : avant que Claude traite un prompt (notre hook 7.A constitutional-inject) - Stop : quand Claude finit de repondre

Agentic Loop (10) : - PreToolUse : avant execution d'un tool (notre hook 7.B guard-push) - PostToolUse : apres succes d'un tool (notre hook 7.C prettier) - PostToolUseFailure : apres echec d'un tool - PermissionRequest : quand un dialogue de permission apparait - PermissionDenied : quand le mode auto refuse un tool - SubagentStart : quand un subagent spawn - SubagentStop : quand un subagent finit - TaskCreated : quand le tool TaskCreate est utilise - TaskCompleted : quand une tache est marquee complete - Elicitation : quand un serveur MCP demande un input utilisateur

Async/Background (7) : - Notification : notifications Claude Code (avec matchers : permission_prompt, idle_prompt, auth_success, elicitation_dialog) - ConfigChange : changement de fichier de config - CwdChanged : changement de repertoire de travail - FileChanged : changement de fichier surveille - WorktreeCreate : creation d'un worktree - WorktreeRemove : suppression d'un worktree - ElicitationResult : reponse utilisateur a une elicitation MCP

Additionnel (3+) : - StopFailure : fin de tour par erreur API - PreCompact : avant compaction du contexte - PostCompact : apres compaction du contexte - TeammateIdle : quand un agent team member est idle

Types de handlers¶

Chaque hook supporte 4 types de handlers : 1. command : script shell recevant du JSON sur stdin 2. http : POST vers une URL 3. prompt : evaluation single-turn LLM 4. agent : subagent avec acces aux outils

Ce qu'on utilise deja (3 sur 31)¶

• UserPromptSubmit → hook 7.A constitutional-inject (injection RULES.md a chaque tour)
• PreToolUse (matcher Bash) → hook 7.B guard-push (bloque git push sans Gate 8 GO)
• PostToolUse (matcher Edit|Write) → hook 7.C prettier (formatage automatique)

3 hooks sur 31. On exploite moins de 10% de la surface disponible.

Ce qu'on devrait utiliser pour LOTR¶

Le handler type http est la cle pour LOTR¶

Chaque hook peut etre configure en type http — un POST vers une URL. Si on configure les hooks des Ringbearers pour poster vers http://localhost:7899 (notre broker claude-peers), le Lord recoit les events nativement sans scraping, sans cmux capture, sans polling.

Architecture cible :

Ringbearer (session Claude Code)
  ├─ hook Stop → POST localhost:7899/send-message
  ├─ hook SubagentStop → POST localhost:7899/send-message
  ├─ hook PreCompact → POST localhost:7899/send-message
  ├─ hook Notification(idle) → POST localhost:7899/send-message
  └─ hook StopFailure → POST localhost:7899/send-message

Lord (One Ring)
  └─ poll-messages depuis broker → route vers Signal

C'est une refonte complete de la supervision LOTR : au lieu de 1300 lignes de bash qui scrapent du texte dans des panes cmux, le Lord recoit des events structures via HTTP. Chaque event a un payload JSON avec session_id, transcript_path, cwd, etc.

Pertinence ProbatioVault¶

Impact fort — change potentiellement l'architecture de supervision LOTR.

Ce que ca remplace¶

Ce que ca ne remplace pas¶

• L'envoi de commandes au Ringbearer (cmux send-keys ou gov_ask_po) — les hooks sont des listeners, pas des emetteurs
• Le broker peers (claude-peers-mcp) — toujours necessaire pour la messagerie bidirectionnelle
• Signal — toujours necessaire pour le canal mobile

Action recommandee¶

1. Court terme : configurer le hook Stop en type http sur un Ringbearer de test. Verifier que le POST arrive bien au broker peers. Si oui, c'est la validation que l'architecture hook-driven fonctionne.

2. Moyen terme : refactorer gov-lord.sh pour recevoir les events par hooks HTTP au lieu du polling cmux. Garder le polling cmux comme fallback (si les hooks ne fonctionnent pas, on revient au scraping). C'est une evolution de [L4] Monitor tool dans le TODO.

3. Mettre a jour le TODO : l'item [L4] "Monitor tool — remplacer le polling cmux par event-driven" peut etre reformule comme "Hooks HTTP Stop/SubagentStop/PreCompact vers broker peers". C'est plus precis et plus realiste que "utiliser le Monitor tool" (qui est un outil different).

Hooks candidats pour notre matrice TODO existante¶