Test bench · 2026-05-10

claude-code-templates (davila7)

Registry CLI npm pour bootstrap un setup Claude Code — agents, commands, skills, MCPs, hooks via `npx claude-code-templates@latest --agent X --yes`. v1.28.16 stable, 27k★, MIT, 152 releases. Site catalog : aitmpl.com.

Pourquoi tester

Premier outil testé qui ressemble fortement à claude-mem en surface (CLI registry pour Claude Code, install via `npx`). Question : est-ce un nouveau claude-mem (invasive, pas d'uninstall) ou un design propre ? Bonus : 152 releases stables et un site catalog (aitmpl.com) qui donne envie de browser sans s'engager.

Ce qu'on a testé

  • Snapshot baseline : md5 ~/.claude/CLAUDE.md + settings.json + listing plugins/marketplaces/cache + 23 plugins installés.
  • Code audit avant exécution : lecture tracking-service.js (telemetry opt-out), health-check.js (pure read-only), package.json (pas de postinstall script).
  • --health-check dans sandbox (CCT_NO_TRACKING=true) : output diagnostique complet (OS, Node, RAM, Anthropic API, Claude Code 2.1.131, 90 allow rules, 2 personal agents). Aucune écriture.
  • --list-agents : read-only confirmé, zéro global agent.
  • --agent development-tools/code-reviewer --dry-run --yes : install quand même survenue (bug --dry-run silencieux), mais project-local (./.claude/agents/code-reviewer.md seul), zéro pollution `~/.claude/`.
  • Cleanup : rm -rf cct-sandbox. Baseline `~/.claude/` strictement préservée (md5 inchangés).

Verdict

Ce qui est solide

  • • Project-local install par défaut (pas `~/.claude/`)
  • • --health-check genuinely read-only
  • • Zéro Claude Code plugin / marketplace pollution
  • • Cleanup = rm un fichier .md
  • • Lifecycle complet (--list/remove/update-agent)
  • • Telemetry opt-out propre (env vars)
  • • MIT, 152 releases, sponsored "Claude for OSS"

Ce qui pète

  • • --dry-run silencieusement ignoré avec --agent
  • • Catalogue communautaire de qualité variable (7+ sources)
  • • Marketing-driven (Trendshift, sponsors multiples)
  • • Dashboards localhost à isoler (analytics/chats/tunnel)

Décision

Adopt avec caveats. Premier outil testé qui passe le protocole sans drame. --health-check entre dans la boîte à outils ad-hoc. Pour les composants : browser aitmpl.com, lire le .md avant d'installer, install ciblé project-local si l'agent passe la revue. Le bug --dry-run est noté mais pas bloquant car le footprint est trivial à inspecter et nettoyer.

Leçons à reprendre

Le test produit 6 patterns réutilisables — certains pour adopter des outils similaires, d'autres pour durcir le protocole /test-tool :

  1. 01

    Le contre-exemple de claude-mem

    Même surface de problème (CLI registry pour Claude Code) mais design diamétralement opposé : `--health-check` est genuinely read-only, install par défaut project-local (pas global), pas d'enregistrement marketplace, cleanup trivial (`rm` un fichier .md). C'est la preuve qu'un outil tiers Claude Code peut être bien designé — claude-mem n'avait pas d'excuse.

  2. 02

    Project-local install > global install

    Tout va dans `./.claude/agents/`, `./.claude/commands/`, etc. — jamais `~/.claude/`. Conséquence : chaque projet Claude Code a sa stack de composants explicite, versionnée dans git si on veut. Aucun risque de drift global. Pattern à privilégier pour tout futur outil de ce genre.

  3. 03

    `--dry-run` silencieusement ignoré : pattern à tester systématiquement

    Le tool documente `--dry-run` ("show what would be copied without actually copying") mais avec `--agent X --dry-run --yes` il télécharge et écrit le fichier quand même. Aucune erreur, aucun warning. C'est exactement le pattern qui nous a fait rejeter claude-mem `--help`. À ajouter au protocole `/test-tool` : ne JAMAIS faire confiance à un flag de safety sans le tester en sandbox dédié.

  4. 04

    Telemetry opt-out propre : env vars > prompts

    CCT envoie des analytics anonymes à Supabase (fire-and-forget, 5s timeout, jamais bloquant). Opt-out via `CCT_NO_TRACKING=true`, `CCT_NO_ANALYTICS=true`, ou `CI=true`. Pattern propre : pas de prompt intrusif au premier run, opt-out facile, erreurs silencieuses. À distinguer des patterns hostiles (consent forcé, fail-on-network).

  5. 05

    Aggregator pattern : la qualité varie

    CCT agrège des composants de 7+ sources externes (anthropic/skills, obra/superpowers, wshobson/agents, K-Dense-AI bio/chem, alirezarezvani roles, awesome-claude-code, NerdyChefsAI). L'agent `code-reviewer` testé est solide (scaled diff reading, automated pre-checks). Mais on ne peut pas généraliser. Heuristique : avant tout install, lire le `.md` source — un agent communautaire est juste un prompt long, l'auditer avant de l'invoquer.

  6. 06

    Dashboards localhost : utile mais à isoler

    `--analytics`, `--chats`, `--plugins`, `--skills-manager`, `--teams` lancent des dashboards web sur localhost. Mode `--tunnel` exposerait via Cloudflare Tunnel. Non testés ici, mais à approcher avec prudence : un dashboard qui lit `~/.claude/projects/` peut afficher des conversations sensibles. Pour toute exposure réseau, vérifier auth/scope avant d'activer.

Cas d'usage retenus pour notre stack

  • ✓ npx claude-code-templates@latest --health-check comme diagnostic ad-hoc
  • ✓ Browse aitmpl.com comme catalogue de référence
  • ✓ Install ciblé d'agents communautaires après avoir lu le .md source
  • ✗ Pas d'install global (--create-agent) tant qu'on n'a pas une raison forte — nos skills/agents perso couvrent
  • ✗ Pas confiance dans --dry-run tant que le bug n'est pas fixé
↗ GitHub ↗ npm ↗ aitmpl.com ↗ docs

Test mené 2026-05-10 sur npm v1.28.16 · protocole formalisé dans le skill /test-tool.