Skip to content

ARTICLE 06

ulk : avantages et inconvénients

25 avril 2026 9 min ulk claude-code retour-experience pros-cons

ulk : avantages et inconvénients

Cet article tranche : ce qu’ulk apporte concrètement, ce que ça coûte, et dans quels cas il vaut mieux passer son chemin. Les affirmations sont sourcées sur le repo (CLAUDE.md, registry.json, _shared/).

Avantages

1. Vocabulaire partagé

Sur un projet équipe, « lance Sargeras » remplace une demi-page de prompt d’audit. Chaque membre invoque les mêmes agents, obtient la même structure de sortie. La doc du projet (CLAUDE.md après install) liste les agents clés, donc même un nouvel arrivant a la liste.

Bénéfice mesurable : moins de prompts ad hoc, moins de variance entre runs.

2. Reproductibilité

Les agents sont des fichiers markdown statiques. Le même /ulk:sargeras lancé par deux personnes différentes sur le même repo donnera des sorties très proches (à la non-déterminisme du LLM près). Source : framework/agents/registry.json est auto-généré et versionné.

3. Économie de contexte

Plusieurs leviers explicites :

  • Sub-agents systématiques pour les explorations lourdes (Règle 3 d’hygiène de contexte). Le sub-agent retourne uniquement la synthèse.
  • Skills locales (Figma, Swift, Flutter) : Claude lit le SKILL.md au lieu de raisonner sans guide.
  • Plugins officiels Anthropic délégués (/feature-dev, /simplify, /commit) : on n’écrit pas un re-implémentation. Source : framework/agents/_shared/plugins-protocol.md.
  • LLM locaux gratuits (apfel sur macOS 26+, ollama gemma3:1b) pour les micro-tâches : commit messages, classification, détection de secrets. 0 token Claude. Source : CLAUDE.md section “CLI Tools”.

4. CLI > MCP

Règle explicite (CLAUDE.md, section CLI Tools) : « CLI available → use it (0 tokens). » Quand un outil CLI existe localement (gh, vercel, neonctl, gws), il est préféré au MCP réseau. Conséquence : moins de tokens consommés en aller-retour, plus de vitesse.

5. Audits récurrents formalisés

  • Sargeras (45) — 10 axes (sécurité, perf, archi, tests, doc, code quality, CI/CD, a11y, coûts, conformité).
  • ED-209 (52) — sécurité dédiée.
  • Killbill (56) — coûts cloud avec killswitch réel.
  • Context Audit (55) — santé du contexte (token waste, MCP inutiles, CLAUDE.md bloaté).

Ces audits peuvent tourner en cloud routines sans machine locale (agent Routine 53). Triggers recommandés : daily 18h, weekly Monday, check_suite.completed (failed).

6. Mémoire entre sessions

Le Knowledge Vault Loop (Lovecraft 47) capture les décisions vers un vault Obsidian-compatible, distribue dans CLAUDE.md, et surface à chaque démarrage. Auto-intégré : 2b3 capture, Godspeed surface, Gandalf audite la santé. Source : CLAUDE.md section “Knowledge Vault Loop”.

Effet : on ne re-explique pas l’archi à chaque session.

7. Hygiène de contexte enseignée

Les 4 règles (/rewind, /clear, sub-agents, /compact proactif) sont héritées par tous les agents via _shared/base-rules.md. Skill /context-audit produit un score 0-100. Agent gandalf (34) vérifie le respect des règles. Source : framework/agents/_shared/context-hygiene-protocol.md.

C’est rare : peu de frameworks Claude Code formalisent l’hygiène à ce niveau.

8. Zéro lock-in

  • Agents = markdown sans dépendance.
  • Installation = copie de fichiers dans ~/.claude/.
  • Désinstallation = ./uninstall.sh.
  • Pas de service à payer, pas de SaaS.

9. Extensible

Numérotation globale préservée (prochain : 64). Convention d’authoring documentée (.claude/rules/agents-authoring.md). Le générateur framework/cheatheet/generate-registry.cjs met à jour le registre automatiquement.

Ajouter son propre agent prend une dizaine de minutes.

10. Communauté tierce intégrée

Skills bundlées par défaut : Figma (7), Swift (7), Flutter (2), context-audit, cwb-app-icon. Plugins officiels Anthropic délégués au lieu d’être réinventés.

→ on profite de l’écosystème.

Inconvénients

1. Courbe d’apprentissage

86 agents, 12 catégories, 7 phases, une vingtaine de protocoles partagés (_shared/), des dizaines de slash-commands. Même si « 10 agents suffisent pour démarrer », la lecture initiale du repo est dense.

Mitigation : CLAUDE.md racine donne un raccourci, et l’agent Bruce (25) est le seul nom à mémoriser pour démarrer.

2. Noms parfois opaques

Les noms d’agents reposent sur de la pop culture (Sargeras = Warcraft, 2b3 = boy band français, Killbill = Tarantino). Cohérence interne forte (cf. billet #4), mais :

  • Un dev qui ne connaît pas ces univers doit faire l’effort de mémoriser.
  • Sur une équipe internationale, certaines références (2 Be 3) ne parlent pas à tout le monde.

Mitigation : registry.json contient les descriptions fonctionnelles ; les alias langage naturel ("audit omniscient" pour Sargeras) sont supportés.

3. Surface d’attaque cognitive

Quand on a 86 agents, il y a une tentation à toujours en chercher un. « Lequel utiliser pour ça ? » peut devenir une procrastination. Bruce (25) est censé arbitrer, mais on peut quand même tomber dans le travers.

Mitigation : se limiter au top 10 (cf. billet #4) tant qu’on ne maîtrise pas.

4. Dépendance à Claude Code

ulk ne fonctionne qu’avec Claude Code (CLI Anthropic). Si Anthropic change l’API, change le format des skills, ou change la grammaire des slash-commands, tout ulk doit être adapté. Dépendance fournisseur réelle.

Mitigation : les agents étant du markdown standard, ils sont portables vers d’autres outils LLM (Cursor, Aider) avec adaptation manuelle.

5. Coût LLM non maîtrisé directement

ulk économise du contexte (sub-agents, CLI > MCP, LLM locaux pour les micro-tâches), mais reste un usage intensif de Claude Opus/Sonnet. Sur un gros audit Sargeras, plusieurs centaines de milliers de tokens peuvent passer.

Mitigation : Killbill (56) audite les coûts cloud (Vercel, GitHub, Neon). Sur les coûts API Claude, ULK-186 est livré : Bruce Phase 5.1 lit api-usage.jsonl et affiche une alerte coût avant chaque audit (« ≈ Xk tokens, ≈ $Y »). ULK-184 (hook PreToolUse) et ULK-185 (skill /killbill api-budget) sont en cours. En attendant : suivre les usages côté console Anthropic.

6. Tests structurels, pas comportementaux

Depuis avril 2026 (Epic ULK-181→183), un système de golden file tests valide la structure des agents : présence du frontmatter requis, sections H2 critiques, patterns d’invocation. Code : framework/tests/agents-golden.test.mjs + fixtures dans framework/tests/agents/<agent>.golden.md. Source du commit : feat(tests): couverture golden files étendue à 81 agents (ULK-183 complet).

Limite : ces tests sont structurels et déterministes (gratuits, rapides, sans appel API). Ils ne testent pas le comportement à l’exécution d’un agent — donc une modif sémantique d’un prompt qui change la qualité de la sortie LLM peut passer sans alerte. Pour valider le comportement, il faut toujours exécuter manuellement.

Mitigation : les protocoles _shared/ minimisent la duplication ; les golden files détectent les régressions structurelles ; un test de comportement reste à inventer.

7. Communauté limitée

Projet d’un auteur (math.drouet). Pas de gros volume de contributeurs externes. Si l’auteur arrête la maintenance, le projet stagne.

Mitigation : MIT-compatible, fork facile, contenu auto-suffisant.

8. Frictions sur projet non-greenfield

Sur un projet existant, ulk ajoute un dossier ~/.claude/ (utilisateur) plus quelques fichiers (CLAUDE.md, docs/spec.md, docs/todo.md) si on suit le pipeline Shuri. Une équipe qui a déjà sa propre convention de doc peut résister.

Mitigation : Shuri peut être désactivé, on peut utiliser ulk uniquement pour les audits (Sargeras, ED-209, Killbill) sans toucher à la doc.

9. macOS-friendly avant tout

Plusieurs intégrations sont macOS-spécifiques :

  • apfel (Apple Intelligence local) → macOS 26+ Apple Silicon uniquement.
  • Skill cwb-app-icon → iOS/macOS (génération .appiconset).
  • Hooks comme --with-xavier-hook testés sur macOS.

Source : CLAUDE.md section “CLI Tools” et “Community Skills”.

Mitigation : ollama gemma3:1b reste multiplateforme, l’essentiel des agents fonctionne sur Linux/Windows.

10. Pas de garantie sur les sorties

Les agents définissent un protocole, pas une sortie déterministe. Le LLM peut produire un rapport légèrement différent à chaque run. Pour un usage compliance/audit auditable, ça reste un guide, pas une preuve.

Mitigation : les rapports peuvent être archivés (Sargeras écrit un fichier daté) ; pour la conformité formelle, faire valider par un humain.

Quand utiliser ulk

Cas où le rapport bénéfice/coût est très favorable :

  • Dév solo qui jongle entre plusieurs projets — Xavier + Lovecraft transforment l’expérience.
  • Équipe qui veut un vocabulaire IA partagé — /ulk:bruce au lieu d’un Notion de prompts.
  • Projet en prod avec coûts cloud à surveiller — Killbill seul peut payer le temps d’install.
  • Audit récurrent (sécurité, perf, dette) — Sargeras + ED-209 en cloud routines.
  • Création de projet from scratch — Bruce → Tony → Shuri → project-decomposer fait gagner une demi-journée de cadrage.

Quand passer son chemin

  • Vous n’utilisez pas Claude Code (Cursor, Copilot, Aider). ulk est inutilisable tel quel.
  • Vous êtes très débutant Claude Code — apprenez d’abord /clear, /compact, sub-agents, skills, MCP. ulk vient ensuite.
  • Vous travaillez exclusivement sur du code privé sensible sans IA externe autorisée. Réglez d’abord la politique d’usage IA de l’organisation.
  • Vous voulez du déterministe (audits SOC2 formels, etc.). Un linter classique reste plus défendable.
  • Votre projet est un script de 200 lignes — l’overhead d’install n’est pas justifié.

Verdict en une phrase

ulk est une boîte à outils d’agents Claude Code spécialisés, pertinente quand on dépasse le mono-script et qu’on veut formaliser ce qu’on répète tous les jours — au prix d’une courbe d’apprentissage, d’une dépendance à Claude Code, et d’une discipline d’usage qu’il faut maintenir.

Suite

  • Billet #5 : 3 use cases concrets avec commandes.
  • Vidéo : démo complète de bout en bout.
  • Slides : version condensée pour talk en public.