| name | feature-builder |
| description | Workflow multi-agent pour implémenter des features complètes avec décomposition en tâches, validation par étape et coordination d'agents spécialisés. Utiliser pour toute feature qui touche plusieurs couches (DB, API, modèles). |
| argument-hint | [-i] [-a] [-v] [-s] [-avs] <description de la feature> |
Orchestrer l'implémentation de features complètes via un système multi-agent avec décomposition en tâches, dépendances, et validation entre chaque phase. Le workflow est auto-maintenable : il peut évoluer en ajoutant de nouvelles étapes ou en modifiant les agents.
<quick_start>
/feature-builder -i ajouter la recherche sémantique NAF
/feature-builder -avs ajouter un endpoint d'export CSV
/feature-builder -vs créer le système d'enrichissement CRM
Flags combinables :
-i : mode interactif, affiche tous les flags et permet de choisir-a : mode autonome, validation automatique par l'agent reviewer-v : validation humaine obligatoire entre chaque phase-s : sauvegarder les outputs dans .claude/output/feature-builder/
Les flags se combinent : -avs = auto + validate + save, -vs = validate + save.
</quick_start>
| Court | Long | Description |
|-------|------|-------------|
| `-i` | `--interactive` | Affiche tous les flags disponibles et permet de les activer/désactiver avant de lancer |
| `-a` | `--auto` | Mode autonome : l'agent reviewer valide automatiquement |
| `-v` | `--validate` | Validation humaine obligatoire entre chaque phase |
| `-s` | `--save` | Sauvegarder les outputs dans `.claude/output/feature-builder/` |
Combinaison de flags :
Les flags courts se combinent en un seul bloc :
-avs équivaut à -a -v -s-vs équivaut à -v -s-as équivaut à -a -s-i se lance seul (les autres flags sont choisis interactivement)
Exemples :
/feature-builder -i ajouter un endpoint
/feature-builder -avs implémenter la feature
/feature-builder -vs ajouter la table NAF
/feature-builder -a corriger le bug
/feature-builder ajouter un champ
```yaml
auto_mode: false
validate_mode: true
save_mode: false
```
Ce workflow utilise les agents integres de Claude Code :
| Agent | Type | Role |
|---|
| DB | Snipper | Tables, indexes, loaders, CLI (perimetre : csv/, cli/, database/) |
| API | Snipper | Services, handlers, routes, modeles (perimetre : api/) |
| Review | code-reviewer | Validation, compilation, review (lecture seule) |
Les perimetres de fichiers sont definis dans le prompt de chaque agent pour eviter les conflits.
Le workflow se déroule en 5 phases séquentielles :
Phase 0 : Initialisation
→ Analyser la feature, décomposer en tâches
→ Identifier les agents nécessaires
→ Créer le plan avec dépendances
Phase 1 : Base de donnees (Snipper)
→ Creer les tables et indexes
→ Creer les loaders de donnees
→ Ajouter les commandes CLI
→ POINT DE VALIDATION
Phase 2 : API et services (Snipper)
→ Creer les modeles
→ Creer les services
→ Creer les handlers et routes
→ Enrichir les requetes existantes
→ POINT DE VALIDATION
Phase 3 : Review et correction (code-reviewer → Snipper si corrections)
→ Verifier compilation
→ Verifier coherence architecturale
→ Verifier securite SQL
→ Si BLOQUE : renvoyer au Snipper pour correction
→ POINT DE VALIDATION
Phase 4 : Finalisation
→ Résumé des changements
→ Liste des nouveaux endpoints
→ Commandes CLI disponibles
→ Proposition de commit
<validation_gates>
Chaque point de validation fonctionne selon le mode choisi :
Mode -v (validate, par défaut) :
- L'agent reviewer produit son rapport
- Le rapport est présenté à l'utilisateur
- L'utilisateur approuve ou demande des corrections
- Si corrections : les agents concernés sont relancés
- Retour au point de validation
Mode -a (auto) :
- L'agent reviewer produit son rapport
- Si APPROUVÉ : passage automatique à la phase suivante
- Si BLOQUÉ : les agents concernés corrigent automatiquement
- Maximum 3 itérations de correction avant escalade à l'utilisateur
Sans flag :
- L'agent reviewer produit son rapport
- L'utilisateur est consulté pour décider de la suite
</validation_gates>
<task_decomposition>
Chaque feature est décomposée selon cette hiérarchie :
Feature
├── Phase 1 : Tâches DB
│ ├── Sous-tâche 1.1 : Schéma de table
│ ├── Sous-tâche 1.2 : Indexes
│ ├── Sous-tâche 1.3 : Loader de données
│ └── Sous-tâche 1.4 : Commande CLI
├── Phase 2 : Tâches API
│ ├── Sous-tâche 2.1 : Modèles
│ ├── Sous-tâche 2.2 : Services
│ ├── Sous-tâche 2.3 : Handlers
│ └── Sous-tâche 2.4 : Routes
├── Phase 3 : Validation
│ └── Sous-tâche 3.1 : Review complète
└── Phase 4 : Finalisation
└── Sous-tâche 4.1 : Résumé et commit
Les sous-tâches d'une même phase peuvent être parallélisées si elles ne touchent pas les mêmes fichiers.
</task_decomposition>
<state_variables>
| Variable | Type | Description |
|---|
{feature_description} | string | Description de la feature |
{feature_id} | string | Identifiant kebab-case |
{interactive_mode} | boolean | Choix interactif des flags |
{auto_mode} | boolean | Validation automatique |
{validate_mode} | boolean | Validation humaine |
{save_mode} | boolean | Sauvegarde des outputs |
{phase} | int | Phase courante (0-4) |
{tasks} | list | Liste des tâches avec statut |
{review_iterations} | int | Nombre d'itérations de correction |
{output_dir} | string | Répertoire de sortie |
</state_variables>
<output_structure>
Quand {save_mode} = true :
.claude/output/feature-builder/{feature-id}/
├── 00-plan.md # Décomposition en tâches
├── 01-db-changes.md # Rapport phase DB
├── 02-api-changes.md # Rapport phase API
├── 03-review.md # Rapport de review
└── 04-summary.md # Résumé final
</output_structure>
<self_maintenance>
Ce workflow est conçu pour évoluer :
- Ajouter une phase : creer un fichier
steps/step-0N-*.md et l'inserer dans le workflow
- Modifier la validation : ajuster les seuils dans
<validation_gates>
- Ajouter des sous-tâches : étendre
<task_decomposition> selon les besoins
Le skill se met à jour en éditant ce fichier SKILL.md et les étapes dans steps/.
</self_maintenance>
<entry_point>
PREMIÈRE ACTION : Charger steps/step-00-init.md
</entry_point>
