Développer plusieurs features en parallèle

Ce tutoriel montre comment utiliser /parallel pour implémenter plusieurs features simultanément, chacune dans un worktree git isolé.

Vue d'ensemble

/parallel est un orchestrateur qui lance plusieurs pipelines kensho (ou teams d'agents) en parallèle. Chaque feature tourne dans son propre worktree avec sa propre branche, puis tout est mergé automatiquement à la fin.

/parallel "feature A" "feature B" "feature C"

     Worktree A          Worktree B          Worktree C
     ┌─────────┐         ┌─────────┐         ┌─────────┐
     │ Agent 1 │         │ Agent 2 │         │ Agent 3 │
     │ kensho  │         │ kensho  │         │ kensho  │
     └────┬────┘         └────┬────┘         └────┬────┘
          │                   │                   │
          └───────────┬───────┘                   │
                      └───────────┬───────────────┘
                                  │
                           ┌──────┴──────┐
                           │   Merge &   │
                           │   Verify    │
                           └─────────────┘

Prérequis

• Un repo git avec un working tree propre (pas de changements non commités)
• Être sur la branche depuis laquelle vous voulez créer les features

Cas 1 — Deux features simples

Le cas le plus courant : deux features indépendantes à implémenter en même temps.

/parallel "add user registration form" "implement email notification service"

Ce qui se passe :

1. Init — Crée deux worktrees et deux branches :

   • ../worktree-user-registration → branche feature/par-01/user-registration
   • ../worktree-email-notification → branche feature/par-01/email-notification

2. Plan — L'architecte analyse les deux features ensemble et vérifie qu'elles ne touchent pas les mêmes fichiers

3. Dispatch — Un agent kensho démarre dans chaque worktree (en parallèle)

4. Monitor — Vous voyez la progression en temps réel :

   ┌──────────────────────────────────────────────────┐
   │  Feature 1 (registration)  ██████████████ done ✓ │
   │  Feature 2 (notification)  ████████░░░░░░ 60%    │
   └──────────────────────────────────────────────────┘

5. Integrate — Les branches sont mergées dans l'ordre de moindre conflit

6. Verify — Build + tests sur le résultat final

Cas 2 — Mode autonome avec tests

Pour un sprint complet sans intervention :

/parallel -a -t -s "add search functionality" "implement export to PDF" "add dark mode"

Flags :

• -a (auto) — Aucune confirmation demandée
• -t (test) — Chaque feature inclut la création de tests
• -s (save) — Tous les artefacts sauvegardés dans docs/parallel/

Combien de features ?

Maximum 5 features en parallèle. Au-delà, les ressources sont insuffisantes. Pour plus de 5 features, lancez /parallel en deux vagues.

Cas 3 — Mode team (front/back/tests)

Pour des features fullstack complexes, le mode team lance 3 agents spécialisés par feature :

/parallel -m team "user dashboard" "admin panel" "analytics page"

Par feature, 3 agents travaillent en parallèle :

Agent	Rôle	Modèle
executor-front	Composants UI, vues, state management	sonnet
executor-back	API endpoints, services, modèles BDD	sonnet
test-engineer	Tests unitaires, intégration, e2e	sonnet

Worktree "dashboard" ─┬─ executor-front ─── Vue components, Pinia stores
                      ├─ executor-back  ─── FastAPI endpoints, SQLAlchemy
                      └─ test-engineer  ─── pytest, Vitest

Un lead coordonne les 3 agents, résout les conflits internes, puis commit.

Gestion des conflits

Détection préventive (Step 01)

Avant le dispatch, l'architecte produit une matrice de conflits :

┌─────────────┬─────────────┬──────────────┬──────┐
│             │ registration│ notification │ Risk │
├─────────────┼─────────────┼──────────────┼──────┤
│ registration│     —       │ models/user  │ low  │
│ notification│ models/user │     —        │ low  │
└─────────────┴─────────────┴──────────────┴──────┘

Si le risque est high, vous recevez un avertissement avant de continuer.

Résolution automatique (Step 04)

Lors du merge, si un conflit git survient :

1. Un agent executor tente de le résoudre automatiquement
2. Si la résolution échoue, la feature est skipée
3. Les autres features sont quand même mergées
4. Vous pouvez merger manuellement la feature problématique après

Que faire si une feature échoue ?

/parallel est resilient : l'échec d'une feature ne bloque pas les autres.

┌────────────────────────────────────────────────────┐
│  Feature 1 (search)     ██████████████ done ✓      │
│  Feature 2 (export)     ██████████████ done ✓      │
│  Feature 3 (dark mode)  ████████░░░░░░ FAILED ✗    │
└────────────────────────────────────────────────────┘

Résultat : features 1 et 2 mergées. Feature 3 exclue.
Worktree et branche feature 3 conservés pour debug manuel.

Pour reprendre la feature échouée individuellement :

cd ../worktree-dark-mode
/kensho -r dark-mode    # reprend le kensho depuis le dernier step OK

Comparaison avec d'autres approches

Approche	Quand l'utiliser
/kensho seul	1 feature à la fois, contrôle interactif
/parallel mode kensho	2-5 features indépendantes, autonome
/parallel mode team	Features fullstack nécessitant front + back + tests
Plusieurs sessions manuelles	Besoin de contrôle interactif sur chaque feature

Outputs

Avec -s, retrouvez tous les artefacts dans docs/parallel/{id}/ :

docs/parallel/par-01-20260327/
├── 00-parallel-context.md     ← config, worktrees, branches
├── 01-parallel-plan.md        ← matrice de conflits
├── 02-dispatch-log.md         ← agents lancés
├── 03-monitor-report.md       ← résultats par feature
├── 04-integration-report.md   ← merges effectués
└── 05-verify-report.md        ← build, tests, résumé

Référence rapide

# Basique
/parallel "feat A" "feat B"

# Autonome + tests + sauvegarde
/parallel -a -t -s "feat A" "feat B" "feat C"

# Mode team (front/back/tests)
/parallel -m team "feat A" "feat B"

# Économique (pas de subagents)
/parallel -e "feat A" "feat B"

Flag	Effet
-a	Pas de confirmations
-t	Inclure les tests
-s	Sauvegarder les outputs
-m team	3 agents/feature (front+back+test)
-e	Mode économique