Générateur de fichiers de configuration créé avec le harnais Claude Code - ConfigDeck

J’ai créé un petit outil appelé ConfigDeck (https://configdeck.dev/ko).
Les générateurs de fichiers de configuration sont un sujet assez courant, mais la façon de le construire était un peu expérimentale, donc j’avais envie de partager ce retour d’expérience.

Qu’est-ce que c’est

À chaque début de projet, copier-coller depuis un ancien projet des fichiers de configuration comme .eslintrc, prettier.config ou tsconfig est fastidieux, donc j’ai créé un outil où l’on choisit des options puis télécharge le résultat.

• Prise en charge de 9 types de fichiers de configuration : ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
  .gitignore, .editorconfig, .env.example
• Presets de stack : React+Vite, Next.js, Astro, Node.js, etc., pour générer plusieurs fichiers d’un coup
• Migration de .eslintrc vers eslint.config.mjs (conversion Flat Config)
• Prise en charge du coréen et de l’anglais
• Site 100 % statique (Cloudflare Pages, 0 KB de JS sur les pages de contenu)
• Les entrées sont traitées uniquement dans le navigateur, sans envoi externe

Stack technique : Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict

Comment je l’ai construit — j’ai beaucoup délégué à l’IA

Cette fois, j’ai essayé d’utiliser Claude Code pour structurer le processus de développement lui-même.
Le travail humain s’est surtout limité à définir la direction du projet et à faire des points d’étape ; pour l’implémentation, j’ai essayé de confier le plus possible à l’IA. Il y a eu de bonnes choses comme beaucoup de tâtonnements, mais je me suis dit qu’en rendant le processus public, cela pourrait servir de référence à celles et ceux qui tentent des approches similaires.

J’ai rendu publiques toutes les configurations utilisées dans le répertoire .claude/ du dépôt :
https://github.com/jsg3121/configDeck/tree/main/.claude

• Documentation du harnais (CLAUDE.md, conventions, ADR, etc.)
• Agents par domaine (config-maker, ui-publisher, ux-designer,
  qa-agent, seo-specialist, etc.)
• Compétences slash (/lint-check, /code-review, /seo-audit, /research, etc.)
• Historique des décisions techniques via les ADR
• Hooks d’automatisation (formatage PostToolUse, vérification build/lint au Stop)

Pendant la rédaction, ce à quoi j’ai surtout fait attention, c’est l’approche « Why-First ». En expliquant non seulement les règles mais aussi leur raison d’être, j’ai eu l’impression que l’IA jugeait les cas limites de façon plus cohérente.

J’ai organisé la collaboration entre agents globalement selon ce flux :

product-planner → ux-designer → ui-publisher → qa-agent
(cadrage) (conception) (implémentation) (validation)

Pour la QA, j’ai prévu des sous-agents unit-tester / e2e-tester / static-analyzer, puis qa-agent rassemble les résultats et produit un rapport.

Tâtonnements

Points positifs

• Le fait de consigner les décisions dans des ADR permet de revenir facilement, même longtemps après, à la question « pourquoi c’est construit comme ça ? ».
• En documentant les conventions dans le harnais, les résultats semblent rester relativement cohérents même d’une session à l’autre.
• Le découpage des agents par domaine évite de mélanger cadrage et implémentation dans un même contexte, ce qui rend le suivi plus simple.

Difficultés

• Au début, faute de harnais, le style des livrables variait à chaque fois, et il a fallu plusieurs itérations pour arriver à la forme actuelle.
• Le coût en tokens s’est révélé plus lourd que prévu, donc j’utilise aussi un guide séparé pour choisir entre conversation principale / compétences / agents selon l’ampleur du travail.
• Comme l’IA peut parfois rapporter qu’un résultat est bon alors qu’il ne l’est pas vraiment, le fait d’automatiser la vérification du build / lint via un hook Stop s’est avéré utile.

Je ne peux pas encore dire que j’ai trouvé la bonne réponse, et il existe sûrement de meilleures façons de faire.

Liens

• Site : https://configdeck.dev/ko
• Dépôt : https://github.com/jsg3121/configDeck
• Répertoire du harnais : https://github.com/jsg3121/configDeck/tree/main/.claude

[heycalmdown]

C’est une idée amusante. Comme on ne travaille pas toujours uniquement sur des projets greenfield, il serait intéressant aussi, à l’inverse, de pouvoir lui donner un fichier de config existant devenu chaotique pour qu’il explique à quoi sert chaque option et permette de les activer ou désactiver.