PLUGINS OPEN-SOURCE
roxabi-plugins
Une marketplace Claude Code — la couche réutilisable au-dessus de l'agent. Son fer de lance, dev-core, transforme une seule commande en tout le cycle de développement : cadrer, analyser, spécifier, planifier, implémenter, relire, livrer. Voici comment fonctionnent /dev et ses sous-skills.
Ce que c'est
Toute équipe sur Claude Code réinvente les mêmes choses — un CLAUDE.md, une commande de review maison, une façon de structurer les prompts de CI, un rituel de sync des docs. Ça marche, mais rien ne voyage d'un projet à l'autre. roxabi-plugins, c'est cette couche jetable rendue réutilisable : une marketplace open-source où chaque plugin embarque un bundle opinioné et éprouvé pour un domaine.
Un plugin est autonome. Il embarque trois types de briques, que Claude Code découvre à l'installation :
- Skills — des workflows à trigger-phrase. Tu décris une tâche en langage naturel ; le skill correspondant se déclenche. Aucune slash-command à mémoriser.
- Agents — des sous-process spécialisés (un ingénieur backend, un auditeur sécurité) qu'un skill invoque pour un travail ciblé.
- Hooks — des garde-fous qui se déclenchent à chaque appel d'outil : scan de secrets, formateur, commande de test imposée.
Les plugins sont agnostiques au projet. Chacun lit ta stack depuis .claude/stack.yml au runtime — {commands.test}, {backend.path}, {package_manager} — donc le même dev-core pilote un monorepo NestJS et un service Django sans changer une ligne.
L'installation tient en deux commandes : claude plugin marketplace add Roxabi/roxabi-plugins, puis claude plugin install dev-core.
dev-core en un coup d'œil
Le plugin phare. Il couvre tout l'arc, de l'issue GitHub à la PR fusionnée, et c'est celui qu'on détaille ici. Tout passe par une porte d'entrée unique : /dev.
Les trois hooks se déclenchent à chaque appel d'outil, sans skill — ils sont le plancher sous tout le reste.
| Hook | Déclencheur | Ce qu'il fait |
|---|---|---|
| Contrôle sécurité | PreToolUse · Edit/Write | Bloque les secrets en dur, les motifs d'injection SQL et de commande |
| Garde des tests | PreToolUse · Bash | Impose bun run test plutôt que bun test — ce dernier utilise le runner Bun et fait tourner le CPU à vide |
| Auto-format | PostToolUse · Edit/Write | Lance le formateur de stack.yml selon l'extension du fichier ; no-op silencieux si non configuré |
/dev, l'orchestrateur
C'est le cœur du plugin. /dev n'est pas un skill qui écrit du code — c'est une machine à états qui scanne où en est le travail, décide de la suite et délègue au bon sous-skill. Une seule porte pour tout le cycle de vie.
Tu le pointes sur une issue. Il s'occupe du reste.
| Commande | Ce qu'elle fait |
|---|---|
/dev #42 | Reprend / démarre depuis l'issue |
/dev "dark mode" | Trouve ou crée l'issue, puis démarre |
/dev #42 --from spec | Saute à une étape (warn si deps manquantes) |
/dev #42 --audit | Checkpoint de raisonnement avant spec / plan / implement |
Chaque invocation déroule la même boucle silencieuse : scanner l'état, trouver la première étape non faite, gater si une décision humaine est due, déléguer, puis re-scanner dans le même tour et continuer.
La progression est suivie à deux endroits, pour qu'une session puisse mourir et reprendre proprement :
- Les artifacts sur disque —
frames/,analyses/,specs/,plans/. Vérité inter-session ; c'est ainsi que/devsait que tu as déjà écrit la spec la semaine dernière. - La task list — vérité intra-session, plus une carte d'état en mémoire pour les étapes qui ne laissent aucun fichier (validate, review, fix).
Trois règles le gardent honnête et hors de ton chemin :
- Gates humains. L'approbation est demandée à frame, spec et plan — jamais d'auto-avance par-dessus une décision.
- Transitions silencieuses. Pas de « Running /X… », pas de « Moving to Y » — la sortie du skill suivant est le message.
- Compact pause. Après
/plan(en F-lite / F-full),/devs'arrête et recommande/compactavant de builder — le lourd contexte de planification est du poids mort pour les agents d'implémentation, qui démarrent à neuf.
Trois tiers
Avant de parcourir le pipeline, /dev jauge le travail. Le tier décide des étapes qui tournent et de celles qu'on saute — un fix de typo ne devrait pas subir une analyse profonde et un gate de spec.
| Tier | Critères | Pipeline |
|---|---|---|
| S | ≤3 fichiers, pas d'architecture, pas de risque | triage → implement → pr → validate → review → fix* → cleanup* |
| F-lite | Scope clair, domaine unique | frame → spec → plan → implement → verify → ship |
| F-full | Nouvelle architecture, besoins flous, >2 domaines | frame → analyze → spec → plan → implement → verify → ship |
* = conditionnel — ne tourne que si applicable.
Le pipeline : les sous-skills de /dev
Cinq phases, quatorze étapes. Chaque étape est un skill autonome auquel /dev délègue — ce sont ses sous-skills. Ils se regroupent en Frame → Shape → Build → Verify → Ship.
Chaque étape a une classe : gate ⛓ demande l'approbation humaine, adv avance automatiquement, verdict bifurque selon le résultat, loop itère.
| Phase | Étape → skill | Classe | Ce qu'elle fait | Sautée si |
|---|---|---|---|---|
| Frame | triage → /issue-triage | adv | Labels, taille, priorité, dépendances | déjà triée |
recheck → /recheck | adv | Drift-check avant de coder (git-drift, symbole disparu, dep résolue) | jamais | |
frame → /frame | gate | Cadre le problème depuis l'issue | tier S | |
| Shape | analyze → /analyze | adv | Analyse profonde + consultation d'experts | tiers S, F-lite |
spec → /spec | gate | Spec + critères d'acceptation, smart splitting | tier S | |
| Build | plan → /plan | gate | Plan d'implémentation en micro-tasks | tier S |
implement → /implement | adv | Écrit le code + les tests via les agents domaine | — | |
pr → /pr | adv | Ouvre la PR (Conventional Commits, lie l'issue) | — | |
| Verify | ci-watch → /ci-watch | adv | Dashboard CI live, dump des logs en cas d'échec | pas de PR |
validate → /validate | adv | Implémentation vs spec, quality gates | — | |
review → /code-review | verdict | Review multi-domaine → approuve ou demande des changements | — | |
fix → /fix | loop | Applique les constats acceptés (≤2 itérations, puis abandon) | déjà appliqué | |
| Ship | promote → /promote | — | staging → production | toujours (standalone) |
cleanup → /cleanup | adv | Supprime les worktrees / branches périmés | rien de périmé |
Avant la première étape de code, /dev amorce silencieusement un worktree git (/setup-worktree) sous .claude/worktrees/{N}-slug sur feat/{N}-slug. Tous les tiers buildent en isolation — jamais sur main ni staging.
De l'issue à la PR fusionnée
Déroulé de bout en bout (F-full ici), la chaîne ressemble à ça — les contours ambre marquent les gates humains, les nœuds en pointillé sont déclenchés par l'utilisateur, et code-review est un verdict qui soit fusionne, soit reboucle par /fix.
C'est entièrement reprenable. Tue la session en plein milieu, relance /dev #42 — le re-scan lit les artifacts sur disque et reprend exactement là où il en était. Idempotent par construction.
La couche agents
/dev orchestre ; il ne touche pas le code lui-même. Des skills comme implement et fix invoquent les agents — la seule couche qui écrit. Neuf au total, en trois tiers. Chacun porte un config guard (échoue vite si stack.yml manque), un chemin d'escalade et un seuil de confiance : sous 70–80 % de certitude, il s'arrête et demande plutôt que de deviner.
| Tier | Agents | Rôle |
|---|---|---|
| Domaine | frontend-dev · backend-dev · devops | Implémentation — UI, services, infrastructure & CI |
| Qualité | tester · fixer · security-auditor | Tests, correctifs de review acceptés, audit OWASP |
| Stratégie | architect · product-lead · doc-writer | ADRs, analyse & specs, documentation |
Lis-le à la source — l'orchestrateur, les sous-skills et les agents vivent tous en accès ouvert.
- Le repo · github.com/Roxabi/roxabi-plugins →
- dev-core · plugins/dev-core/README.md →