Skip to content
Conduit

skill

claude-code-setup

Frutzmann/claude-code-setupcommunitylistedunreviewed
Use skill

Set up

Skills are installed by placing their folder where your agent loads skills.

Download ZIP from GitHub Open the repository

The download comes from github.com/Frutzmann/claude-code-setup itself, not from our server, so what you get is exactly what its author published.

Install instructions come from the README

Skills do not use an MCP config. Follow the steps in the README below.

README

synced Oct 26, 2026

Mon setup Claude Code

À tous ceux qui ont répondu présent pour ce setup, le voici. Mon setup Claude Code.

Tout tourne en prod. Et pour anecdote, les hooks m'ont d'ailleurs bloqué 3x pendant le nettoyage de ce repo.

L'architecture multi-modèles

C'est le cœur du setup : avec qui je travaille ?

Eh bien c'est très simple. Aucune ligne de code ne s'écrit dans ma session principale.

Imagine être littéralement le CEO de ta session. Ton seul boulot, c'est la vision et la stratégie. Et c'est exactement ce que je fais. Et Fable 5 est parfait pour ça.

Fable 5, c'est mon assistant. Il agit comme intermédiaire entre le CEO et son équipe d'agents.

Peut-être alors que tu te poses cette question : "Comment on code dans cette config ?"

Très simple : une fois que tout a été correctement planifié avec Fable 5, il invoque une équipe de sous-agents sous Sonnet 5 pour exécuter.

De temps en temps il y a des sous-agents sous Opus, qui agissent comme des experts qui interviennent 5 minutes dans les projets.

D'ailleurs cette technique ne vient pas de moi. Elle vient des développeurs de Claude Code eux-mêmes : le pattern "Fable orchestrator, Sonnet workers" apporte 96 % de la performance de Fable pour 46 % de son coût. Cette info ne vient pas de moi (tu trouveras toutes les sources en annexe).

Voilà. Et prends note : tout le setup tourne actuellement autour de cette stratégie.

La planification fait 80 % du boulot.

L'équipe de sous-agents

Mon équipe. Tout simplement.

Je l'ai construite comme une équipe IT classique, pour compenser les défauts naturels de Claude Code : la fainéantise et les raccourcis brutaux dès que personne ne contrôle.

Le casting :

  • dev-agent : le worker. Il exécute un ticket (ou un plan), ne touche que les fichiers qu'on lui a attribués, et s'arrête (STUCK) après deux échecs du même test au lieu de bricoler.
  • adversary : l'adversaire, en lecture seule. Il n'écrit jamais de code : il attaque la spec avant qu'on code (mode CONTRAT), diagnostique un test qui échoue deux fois (mode DOUBLE-ÉCHEC) et cherche ce qui casse un ticket déclaré fini (mode FINI). Chaque constat est prouvé par fichier:ligne, sinon il ne l'écrit pas.
  • verifier-agent : en fin de flux, il reprend chaque critère d'acceptation, l'exécute et rend OK / KO / NON PROUVÉ. Le "ça a l'air bon" ne passe pas.

Ce flux est en essai depuis le 2026-10-05. Il remplace l'ancien duo breaker-agent (casseur qui jouait l'app) + reviewer-agent (relecture) : les deux sont archivés dans archive/agents/ pour référence.

L'adversaire et le verifier ne sont pas une lubie : l'équipe Claude Code écrit elle-même qu'un reviewer au contexte frais est moins biaisé que l'agent qui a produit le code (sources en annexe).

Et si tu veux pousser la review et le cassage encore plus loin : les modèles seraient apparemment excellents pour détecter les failles des autres modèles. Tu peux donc ajouter un petit GPT 5.6 adversarial dans l'équipe, via le plugin Codex officiel d'OpenAI. C'est cadeau : /plugin install codex@openai-codex (repo : https://github.com/openai/codex-plugin-cc). Tu obtiens /codex:adversarial-review, exactement ce que son nom promet.

Les 3 fichiers sont dans agents/, prêts à copier dans ~/.claude/agents/.

Les hooks

Ma préférée. Et quasiment personne n'en parle sur les réseaux.

Au-delà d'empêcher Claude Code de lire tes fichiers d'environnement ou d'afficher tes secrets, c'est ce qui va faire en sorte que Claude suive tes instructions.

Par exemple : s'il décide de coder lui-même au lieu de déléguer à un sous-agent, le hook va détecter cela de façon déterministe, et va littéralement interdire l'écriture de code à ta session principale.

Un hook, c'est du code qui s'exécute à chaque action, que Claude soit d'accord ou non. L'équipe de Claude Code appelle ça du contrôle déterministe (encore une fois, c'est sourcé).

Les 10 hooks du repo, en 3 familles.

Protection :

  • block-dangerous.mjs : bloque les commandes destructrices avant exécution
  • protect-files.mjs : verrouille les fichiers sensibles, en lecture comme en écriture, y compris quand la tentative passe par une commande shell

Qualité forcée :

  • block-direct-code-edit.mjs : interdit à la session principale d'éditer du code source. Les sous-agents passent, l'orchestrateur non. C'est lui qui force l'architecture de la section précédente.
  • test-gate.mjs et review-gate.mjs : la session ne peut pas se terminer si un plan avec must_haves existe sans rapport de vérification PASS
  • exit-plan-gate.mjs : à la sortie du plan mode, détecte les must_haves et aiguille vers le bon workflow
  • adversary-gate.mjs : en mode équipe, une tâche nommée T3: ... ne peut pas passer à "terminée" tant que .claude/verdicts/T3.md ne commence pas par VERDICT: PASS (le verdict de l'adversaire). Les tâches sans ID de ticket ne sont pas concernées.
  • jev-advisor.mjs (facultatif, mode observation) : après un test en échec, et avant une écriture hors des fichiers du ticket (.ticket.json), il demande un avis à un modèle externe (API TypeSafe) et l'injecte dans le contexte, préfixé [Jev, observation]. Il ne bloque jamais. Il lui faut la variable d'environnement TYPESAFE_API_KEY ; sans elle, il ne fait rien.

Système :

  • skill-activation.mjs : force le déclenchement des skills au bon moment. Archi sous-côté.
  • context-backup.mjs : sauvegarde le contexte avant chaque compaction

L'anecdote promise en intro : pendant le nettoyage de ce repo, ces hooks ont bloqué mon assistant 3 fois. Un grep contenant des mots sensibles, un rm -rf, une écriture directe dans un dossier protégé. Le système s'est défendu pendant qu'on l'emballait.

Dernier point, et c'est l'erreur classique : copier le dossier hooks/ ne suffit pas. Un hook ne tourne que s'il est câblé dans settings.json. Le câblage complet est dans settings.example.json.

Les skills

Je pense que tu sais déjà ce que c'est. Mais parce qu'un rafraîchissement de mémoire ne fait jamais de mal, voici ce qu'est un skill dans les grandes lignes.

C'est une série d'instructions écrites dans un fichier persistant, que Claude lira à chaque fois qu'il a besoin de respecter un ensemble de règles. Ça garantit l'homogénéité d'un output récurrent. Et en plus ça gaspille très peu de contexte : le frontmatter, qui est un tl;dr du skill, sert justement à l'indexer de manière suffisamment précise pour savoir si Claude en a besoin ou non. Il ne charge pas tout le fichier, seulement le frontmatter.

Mes 4 skills principaux :

  • dev : le coordinateur du cycle DEFINE → EXECUTE → ATTACK → VERIFY, en trois modes. Léger (≤ 2 fichiers, pas d'UI) : il code lui-même en TDD. Complet : il extrait d'abord la spec de toi (comportement attendu, invariants, edge cases), délègue au dev-agent, lance l'adversaire si ça touche l'UI ou un invariant, puis le verifier-agent. Équipe (spec-driven) : il écrit une spec avec les contrats entre modules, la fait attaquer par l'adversaire, attend ton go, découpe en tickets à fichiers exclusifs, lance un dev-agent par ticket en worktree isolé, fait valider chaque ticket par l'adversaire, fusionne, puis vérifie. C'est lui qui fait tourner l'équipe de la section 3. Le détail (gabarits de dispatch, conventions du mode équipe) est dans ses references/, chargé seulement à l'étape où il sert.
  • plan : l'architecte. Zéro code, zéro fichier créé. Il produit un plan avec des must_haves testables, que les gates de la section 4 utiliseront pour bloquer la session tant que tout n'est pas vérifié.
  • review : le QA. Tests structurels, fonctionnels, audit sécurité. Zéro complaisance, et il s'appuie sur le /code-review natif au lieu de le réinventer.
  • ops : la livraison. Typecheck, lint, tests, build. Le push vient en dernier, jamais avant.

Chaque skill embarque ses references/ (TDD, clean code, API design...), chargées à la demande seulement.

Et un 5e, qui est cadeau : /find-skills. Celui-ci permet directement à Claude Code d'aller chercher des skills qui existent déjà, au service de tes projets. L'écosystème est sur https://skills.sh (installation en une commande : npx skills).

L'autonomie : /goal et /loop

Deux commandes natives, deux philosophies.

/goal, c'est la condition : Claude travaille jusqu'à ce que ta condition soit vraie, point. Un petit modèle évalue après chaque tour et le renvoie bosser tant que ce n'est pas atteint. Exemple : /goal tous les tests de test/auth passent et le lint est propre. Le piège classique est de donner un objectif flou. Donne-lui un critère vérifiable (des tests qui passent, un seuil chiffré) et il ne s'arrêtera ni trop tôt ni trop tard.

/loop, c'est l'horloge : la même prompt relancée à intervalle. /loop 2m vérifie si le déploiement est terminé et dis-moi ce qui s'est passé. Sans intervalle, Claude choisit lui-même son rythme selon ce qu'il surveille.

La règle pour choisir : un résultat à atteindre, /goal. Un système externe à surveiller ou une tâche récurrente, /loop.

Là encore c'est l'équipe Claude Code qui en parle le mieux : leur taxonomie officielle des loops est en annexe, elle vaut la lecture.

Le testing E2E navigateur

Mon duo pour vérifier qu'une feature marche vraiment, pas juste qu'elle compile.

Claude in Chrome : l'extension officielle Anthropic. Claude pilote ton navigateur, voit les pages, et surtout capture des screenshots. Pour de l'UI, ça permet le test avant/après en images : tu vois littéralement ce que ta feature a changé.

Playwright MCP : le serveur officiel Microsoft, taillé pour l'E2E agentique. Il pilote le navigateur par l'arbre d'accessibilité plutôt que par la vision, ce qui le rend rapide et fiable en headless. C'est lui que tu branches dans un pipeline.

En résumé : Chrome pour voir, Playwright pour automatiser.

Plugins & MCP

Les plugins que je fais tourner, et pourquoi :

  • superpowers : pour du briefing archi avancé
  • claude-mem : mémoire permanente. Utile surtout si tu as oublié de faire des fichiers de sauvegarde
  • context7 : pour être à jour sur la doc. Le best.
  • frontend-design : pour limiter au max l'AI slop
  • codex : pour interagir de façon adversariale avec GPT 5.6 (facultatif, les débats entre agents Claude sont très efficaces aussi)
  • vercel : le déploiement
  • typescript-lsp / pyright-lsp : les facilités agents sur le code

Pour les MCP, pas de liste imposée : c'est vraiment selon les outils que TU utilises. Chez moi il y a du SEO, de l'email, un vault Obsidian. Chez toi ce sera autre chose. La seule règle non négociable : jamais une clé API en dur dans .mcp.json. Toujours une variable d'environnement.

Installation

Cinq minutes, montre en main.

git clone <ce-repo>
cd claude-code-setup

# Copier les briques dans ton setup global
cp -R rules hooks agents skills ~/.claude/

# CLAUDE.md : fusionne avec le tien si tu en as déjà un
cp CLAUDE.md ~/.claude/CLAUDE.md

Dernière étape, la seule où il faut réfléchir : ouvre settings.example.json et fusionne son contenu dans ton ~/.claude/settings.json. C'est le câblage des hooks. Sans ça, tout le dossier hooks/ reste décoratif.

Et si tu ne veux pas te prendre la tête : clone le repo, ouvre Claude Code dedans, et colle ce prompt.

Installe ce setup chez moi : copie rules/, hooks/, agents/ et skills/ dans ~/.claude/.
Si j'ai déjà un CLAUDE.md global, fusionne intelligemment (garde mes règles, ajoute celles du repo).
Fusionne ensuite le contenu de settings.example.json dans ~/.claude/settings.json sans écraser mes réglages existants, et montre-moi le diff avant d'écrire.
Termine en listant les hooks actifs.

Redémarre ta session Claude Code, et vérifie que ça marche : demande-lui d'écrire un fichier .py dans la session principale. S'il se fait bloquer, tout est en place.

Sources

Tout ce que j'avance dans ce repo est sourcé. Dans l'ordre des sections :

Architecture multi-modèles :

Équipe de sous-agents :

Hooks :

CLAUDE.md et rules :

Skills :

Autonomie :

E2E navigateur :

↑↓ navigate openesc close