Ma stack Claude Code

Ma stack Claude Code

4 plugins. Tous gratuits. Tous open source. Une commande chacun.

Voilà exactement ce qui tourne sur mon Claude Code au quotidien, pourquoi je l'utilise, et comment l'installer en 10 minutes.

---

En résumé

Plugin	Ce que ça règle	Install
ponytail	Ton agent sur-code. 400 lignes là où il en faut 23.	/plugin marketplace add DietrichGebert/ponytail
claude-mem	Ton agent oublie tout entre deux sessions.	/plugin marketplace add thedotmack/claude-mem
mattpocock/skills	Ton agent code avant d'avoir compris ce que tu veux.	npx skills@latest add mattpocock/skills
impeccable	Ton agent produit du design générique.	npx impeccable install

L'ordre d'installation n'a pas d'importance. Mais si tu n'en installes qu'un, prends ponytail : c'est celui qui se voit immédiatement.

---

1. ponytail — le dev senior flemmard

"Le meilleur code est celui que tu n'as jamais écrit."

Le problème

Les agents de code sur-construisent. Tu demandes un date picker, il te sort un composant custom de 400 lignes avec sa propre gestion du clavier, ses états, ses tests. Alors qu'un <input type="date"> fait le job.

Le problème, c'est que ça s'accumule. Chaque feature ajoute de la complexité que personne n'a demandée, et six semaines plus tard ta codebase est illisible — pour toi comme pour l'agent.

Ce que fait ponytail

Ça injecte dans ton agent la mentalité du dev senior qui est là depuis plus longtemps que le système de versioning. Celui à qui tu montres cinquante lignes, qui ne dit rien, et qui les remplace par une.

Les chiffres (et ce qu'ils valent vraiment)

Benchmark sur des sessions Claude Code réelles éditant un vrai repo open source (FastAPI + React), 12 tickets de feature, avec et sans le skill :

• ~54% de code en moins en moyenne
• jusqu'à 94% sur les tâches où l'agent sur-construit (le date picker : 404 → 23 lignes ; un color picker : 287 → 23)
• ~20% moins cher en tokens
• ~27% plus rapide

À savoir, parce que je préfère être honnête :

• Le 94% n'est pas la moyenne. C'est le plafond sur les tâches piégeuses. Sur du code déjà minimal, le gain est proche de zéro.
• Un dev (Colin Eberhardt) a testé si un simple prompt de 7 mots — "Follow YAGNI principles, and prefer one-liner solutions" — obtenait le même résultat. Il s'en approche. La différence, c'est que ponytail garde tous les garde-fous de sécurité, là où le prompt brut en perd.
• Sur des petits modèles locaux (type llama 3B), ça ne marche pas. Le modèle acquiesce et écrit le boilerplate quand même. C'est calibré pour des modèles qui suivent réellement les instructions.

Installation

# Dans Claude Code
/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

Ou en CLI :

claude plugin marketplace add DietrichGebert/ponytail
claude plugin install ponytail@ponytail

Marche aussi sur Codex, Copilot CLI, Cursor, Gemini CLI, OpenCode.

Les commandes

Commande	Usage
/ponytail	Applique la discipline sur la tâche en cours
/ponytail-review	Relit du code existant avec ce regard
/ponytail-audit	Scanne pour trouver la sur-construction
/ponytail-debt	Note les raccourcis que tu as différés (pour que "plus tard" ne devienne pas "jamais")
/ponytail-gain	Affiche le scoreboard d'impact mesuré
/ponytail-help	La liste complète

En pratique

Tu ne fais rien de spécial. Une fois installé, le ruleset est chargé en contexte et ton agent code différemment. Tu le vois au premier diff.

Le seul réflexe à prendre : /ponytail-review avant un commit un peu gros. Ça rattrape ce qui est passé entre les mailles.

Repo : github.com/DietrichGebert/ponytail

---

2. claude-mem — la mémoire persistante

Le problème

Tu bosses trois heures avec Claude Code. Vous résolvez un bug tordu, vous prenez cinq décisions d'architecture, vous établissez des conventions. Tu fermes.

Le lendemain, tu rouvres. Il ne sait rien. Tu recommences à zéro : tu réexpliques le projet, tu réexpliques pourquoi vous avez fait ce choix-là, tu réexpliques la convention de nommage. Et l'agent, ne sachant pas, refait les erreurs que vous aviez déjà corrigées.

Ce que fait claude-mem

Ça capture ce que l'agent fait pendant que tu bosses — les outils qu'il utilise, les fichiers qu'il touche, ce qui marche et ce qui casse. Ça compresse tout ça en résumés sémantiques avec le Claude Agent SDK. Et ça réinjecte le contexte pertinent au démarrage de la session suivante.

Résultat : tu ouvres une nouvelle session et il sait déjà où vous en étiez.

Installation

# Dans Claude Code
/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

Puis redémarre Claude Code. Le contexte des sessions précédentes apparaît automatiquement au démarrage.

Tout est stocké en local dans ~/.claude-mem/.

En pratique

Le vrai usage, c'est la recherche. Le skill mem-search se déclenche tout seul quand tu poses une question sur le passé :

> On a fixé quels bugs la session dernière ?

> Comment on avait implémenté l'auth ?

> Qu'est-ce qui a changé dans worker-service.ts ?

> Montre-moi le travail récent sur ce projet

> Il se passait quoi quand on a ajouté l'UI du viewer ?

Tu n'as pas de commande à retenir. Tu poses la question en langage naturel, il va chercher.

Bon à savoir

• Ça marche aussi avec Codex, Gemini, Copilot, OpenCode, OpenClaw.
• Il y a des modes (CLAUDE_MEM_MODE) selon le type de travail : code, chill, investigation. Et des modes par langue (code--fr, etc.).
• Un canal beta existe avec Endless Mode : une architecture de mémoire qui étend fortement la longueur de session. Les sessions standard saturent le contexte après ~50 utilisations d'outils. Ça repousse le mur. C'est de la beta, à tester sur un projet non critique.
• Si tu as un souci, décris juste le problème à Claude : le skill troubleshoot se déclenche et diagnostique.

Repo : github.com/thedotmack/claude-mem — Docs : docs.claude-mem.ai

---

3. mattpocock/skills — l'alignement avant le code

Le problème

C'est le plus gros échec du dev, avec ou sans IA : le malentendu. Tu penses que l'agent a compris. Il code. Tu regardes le résultat. Il n'avait rien compris.

Et c'est normal, parce que la plupart du temps, toi non plus tu ne sais pas exactement ce que tu veux — tu le découvres en voyant ce qui ne va pas.

Ce que fait ce pack

C'est le set de skills que Matt Pocock utilise en vrai, tous les jours, pour du développement sérieux. La philosophie est explicite : des skills petits, adaptables et composables, qui ne prennent pas le contrôle du processus — contrairement aux approches type GSD ou BMAD qui décident tout à ta place et deviennent impossibles à débugger quand ça part en vrille.

Installation

npx skills@latest add mattpocock/skills

Choisis les skills que tu veux et l'agent cible. Sélectionne impérativement /setup-matt-pocock-skills.

Puis, dans ton agent :

/setup-matt-pocock-skills

Il va te demander ton issue tracker (GitHub, Linear, ou fichiers locaux), tes labels de triage, et où sauvegarder les docs. Une fois par repo.

Version plugin (si tu préfères ne pas maintenir les fichiers toi-même) :

/plugin marketplace add mattpocock/skills
/plugin install mattpocock-skills@mattpocock

La différence : l'installer copie les fichiers dans ton projet, tu peux les modifier et te les approprier. Le plugin les garde en bundle read-only toujours à jour. À toi de voir si tu veux forker ou t'abonner.

Le skill à retenir : /grill-me

C'est celui que j'utilise le plus, et de loin.

Tu lances /grill-me, et l'agent t'interroge. Sans pitié. Il te pose vingt questions sur ce que tu veux construire, jusqu'à ce que chaque branche de l'arbre de décision soit tranchée.

C'est chiant. Et c'est exactement pour ça que ça marche. La moitié des questions, tu n'avais pas la réponse — tu ne t'étais juste pas rendu compte que la question existait.

Sa variante /grill-with-docs fait la même chose, mais en plus elle construit le langage partagé de ton projet dans un fichier CONTEXT.md.

L'exemple qui m'a convaincu :

• AVANT : "Il y a un problème quand une leçon dans une section d'un cours est rendue 'réelle' (c'est-à-dire qu'on lui donne une place dans le système de fichiers)"
• APRÈS : "Il y a un problème avec la cascade de matérialisation"

Une fois ce vocabulaire établi, l'agent nomme tes variables et tes fichiers de façon cohérente, navigue plus vite dans la codebase, et dépense moins de tokens à réfléchir parce qu'il a un langage plus dense.

Les autres skills qui valent le détour

Que tu invoques toi-même :

Skill	Usage
/grill-me	Se faire interroger sur un plan ou un design
/grill-with-docs	Pareil + construction du CONTEXT.md et des ADR
/to-spec	Transformer la conversation en cours en spec, publiée sur ton tracker
/to-tickets	Découper un plan en tickets "tracer bullet" avec leurs dépendances
/implement	Construire ce que décrit la spec, en pilotant /tdd et en finissant par /code-review
/improve-codebase-architecture	Scanner la codebase, sortir un rapport HTML des opportunités, puis creuser celle que tu choisis
/wayfinder	Planifier un chantier trop gros pour une seule session d'agent
/ask-matt	Tu ne sais pas quel skill utiliser ? Il te route.

Que l'agent déclenche tout seul quand la tâche s'y prête :

/tdd (boucle red-green-refactor), /diagnosing-bugs (reproduire → minimiser → hypothèse → instrumenter → corriger → test de régression), /code-review (double axe : standards du repo + fidélité à la spec, en sous-agents parallèles), /codebase-design, /domain-modeling, /research, /prototype, /resolving-merge-conflicts.

Mon workflow type

1. /grill-with-docs     → on s'aligne, le CONTEXT.md se construit
2. /to-spec             → la conversation devient une spec
3. /to-tickets          → la spec devient des tickets
4. /implement           → il construit, avec TDD et code review intégrés

Et une fois tous les deux ou trois jours : /improve-codebase-architecture, pour éviter que le projet ne devienne une boule de boue.

Repo : github.com/mattpocock/skills

---

4. impeccable — le design qui ne ressemble pas à de l'IA

Le problème

Tous les modèles ont été entraînés sur les mêmes templates SaaS. Donc tout ce qu'ils produisent se ressemble : mêmes cards fantômes, mêmes coins trop arrondis, mêmes gradients violets, même hiérarchie typographique molle.

Tu reconnais une landing page générée par IA en deux secondes. Tes visiteurs aussi.

Ce que fait impeccable

C'est un langage de design pour agents. Le skill de référence sur le sujet chez Anthropic, c'était frontend-design — impeccable est parti de là et va beaucoup plus loin : 23 commandes, une itération live dans le navigateur, et 58 règles de détection déterministes des anti-patterns du design généré par IA.

Le détail malin : le skill est recompilé par modèle. Le build pour Gemini tue sa manie du mouvement au survol des images. Le build pour Codex refuse les ghost cards et l'excès d'arrondi. Chaque modèle a ses tics, chaque build les interdit.

Installation

Depuis la racine de ton projet (Node 22.12+ requis) :

npx impeccable install

Puis dans ton agent :

/impeccable init

Cette étape établit le contexte design de ton projet. Ne la saute pas — sans elle, les commandes tournent à vide.

Alternative Claude Code :

/plugin marketplace add pbakaus/impeccable

Puis ouvre /plugin et installe-le depuis la liste.

Évite npx skills add pbakaus/impeccable : ça installe un build générique partagé au lieu de celui compilé pour ton outil.

Pour mettre à jour : npx impeccable update (et npx impeccable check te dit si tu es en retard).

Les commandes principales

Tout passe par le skill unique /impeccable :

/impeccable audit       # Trouver les problèmes
/impeccable polish      # Nettoyage final
/impeccable distill     # Retirer la complexité inutile
/impeccable critique    # Revue de design complète

Tape /impeccable seul pour voir les 23.

Parmi les autres : animate, clarify, colorize, typeset, layout, arrange, shape, bolder, quieter, delight, normalize, harden, optimize, overdrive, adapt, extract, onboard.

En pratique

La plupart des commandes acceptent une cible :

/impeccable audit the header
/impeccable polish the checkout form
/impeccable distill the pricing page
/impeccable typeset the blog article layout

Si tu utilises une commande tout le temps, épingle-la pour en faire un raccourci :

/impeccable pin audit

Tu obtiens /audit en direct.

Le premier test à faire

Prends une page qui existe déjà — même une landing page scaffoldée à l'arrache — et lance /impeccable polish. C'est le chemin le plus rapide pour comprendre ce que ça change. La différence se voit sans avoir besoin d'un œil de designer.

Repo : github.com/pbakaus/impeccable — Docs : impeccable.style

---

Installer les 4 en une fois

# 1. ponytail
claude plugin marketplace add DietrichGebert/ponytail
claude plugin install ponytail@ponytail

# 2. claude-mem
claude plugin marketplace add thedotmack/claude-mem
claude plugin install claude-mem
# → redémarrer Claude Code

# 3. skills de Matt Pocock
npx skills@latest add mattpocock/skills
# → sélectionner /setup-matt-pocock-skills, puis le lancer dans l'agent

# 4. impeccable (depuis la racine du projet)
npx impeccable install
# → puis /impeccable init dans l'agent

Compte 10 à 15 minutes en tout, la config incluse.

---

Comment je les combine

Ils ne se marchent pas dessus — chacun agit à un moment différent du cycle :

Moment	Outil	Ce qu'il fait
Avant de coder	/grill-with-docs	T'oblige à savoir ce que tu veux
Pendant	ponytail	Empêche l'agent de sur-construire
Pendant (UI)	/impeccable polish	Empêche le design générique
Après	claude-mem	Garde la mémoire pour la prochaine session

Le seul point d'attention : grill-me et ponytail tirent tous les deux vers la simplicité, chacun à sa façon. Ça ne crée pas de conflit, mais ton agent va te proposer des solutions plus petites que ce que tu avais en tête. C'est le but. Laisse-le faire une semaine avant de juger.

---

Les liens

• ponytail — github.com/DietrichGebert/ponytail
• claude-mem — github.com/thedotmack/claude-mem · docs.claude-mem.ai
• skills de Matt Pocock — github.com/mattpocock/skills
• impeccable — github.com/pbakaus/impeccable · impeccable.style

Tous les quatre sont open source, gratuits, et sous licence permissive. Rien à payer, rien à s'abonner.