/parallel

6 steps v1.8.0

Développement multi-features en parallèle dans des git worktrees isolés. Orchestre plusieurs pipelines kensho (ou teams d'agents) simultanément, chacun dans son propre worktree avec sa propre branche.

Quand l'utiliser

• 2+ features indépendantes à implémenter en parallèle
• Sprint avec plusieurs tâches à traiter simultanément
• Refactoring multi-domaines (front + back + tests)

Quand NE PAS l'utiliser

Utilisez plutôt :

• 1 seule feature → /kensho
• Besoin de contrôle interactif → /kensho dans des sessions séparées
• Travail CI/CD → /ci-fixer

Usage

# 2 features en parallèle (mode kensho par défaut)
/parallel "add user authentication" "implement payment system"

# 3 features avec teams front/back/tests par feature
/parallel -m team "auth flow" "dashboard redesign" "api v2 endpoints"

# Autonome avec tests et sauvegarde
/parallel -a -t -s "add search" "add notifications" "add export"

Flags

Flag	Nom	Description
-a	auto	Sauter les confirmations dans les kensho enfants
-t	test	Inclure les étapes de test dans chaque feature
-s	save	Sauvegarder les outputs dans docs/parallel/{parallel-id}/
-m	mode	kensho (1 agent/feature) ou team (front+back+test/feature)
-e	economy	Propager le mode économique aux agents enfants

Pipeline

/parallel "feat A" "feat B" "feat C"
         │
    ┌────┴────┐
    │ 00-Init │  Parse features, crée les worktrees
    └────┬────┘
         │
    ┌────┴────┐
    │ 01-Plan │  Analyse croisée, détection conflits
    └────┬────┘
         │
  ┌──────┴──────┐
  │ 02-Dispatch │  Lance 1 agent par worktree (parallèle)
  └──────┬──────┘
         │
  ┌──────┴──────┐
  │ 03-Monitor  │  Suivi progression, gestion erreurs
  └──────┬──────┘
         │
  ┌──────┴────────┐
  │ 04-Integrate  │  Merge branches, résolution conflits
  └──────┬────────┘
         │
  ┌──────┴──────┐
  │ 05-Verify   │  Build + tests sur le résultat intégré
  └─────────────┘

Steps détaillés

Step 00 — Init

• Parse les descriptions de features (chaque string quoted = 1 feature)
• Vérifie que le working tree est propre
• Crée un worktree par feature : ../worktree-{slug}
• Crée une branche par feature : feature/{parallel-id}/{slug}
• Charge les profiles et modèles (comme kensho)

Step 01 — Plan

• Délègue à l'agent architect (opus)
• Analyse toutes les features ensemble pour détecter les conflits
• Produit une matrice de conflits (Feature × Feature × fichiers partagés)
• Détermine l'ordre d'intégration optimal (moins de conflits → merge en premier)

Step 02 — Dispatch

• Lance un agent par feature en parallèle dans son worktree
• Mode kensho : un agent general-purpose exécute le pipeline complet
• Mode team : un lead coordonne 3 agents (backend, frontend, tests)
• Tous les agents tournent en background

Step 03 — Monitor

• Attend les notifications de complétion (pas de polling)
• Affiche un tableau de bord de progression
• Une feature en échec ne bloque pas les autres
• Gate : tous les agents terminés → next

Step 04 — Integrate

• Merge les branches dans l'ordre planifié (step 01)
• Si conflit : délègue à un executor pour résoudre
• Nettoie tous les worktrees (succès et échecs)
• Supprime les branches features (avec confirmation, sauf si -a)

Step 05 — Verify

• Build complet sur la branche intégrée
• Exécution des tests
• Si échec : délègue au debugger (max 3 tentatives)
• Rapport final avec statistiques

Modes d'exécution

Mode kensho (défaut)

Un seul agent par worktree. Il analyse, planifie, implémente et valide la feature de bout en bout.

/parallel "feature A" "feature B"

Worktree A ─── Agent kensho ─── analyse → plan → code → validate → commit
Worktree B ─── Agent kensho ─── analyse → plan → code → validate → commit

Mode team

Trois agents spécialisés par worktree, coordonnés par un lead :

/parallel -m team "feature A" "feature B"

Worktree A ─┬─ executor-front (sonnet)  ─── composants, vues, state
            ├─ executor-back (sonnet)   ─── API, services, modèles
            └─ test-engineer (sonnet)   ─── tests unitaires, intégration

Limites

• Maximum 5 features en parallèle (protection contre l'épuisement des ressources)
• Le working tree doit être propre avant de lancer (git status vide)
• Les worktrees sont créés dans le répertoire parent du projet
• La détection de conflits est advisory — elle ne bloque pas l'exécution

Outputs

Avec -s, les artefacts sont sauvegardés dans docs/parallel/{parallel-id}/ :

docs/parallel/par-01-20260327/
├── 00-parallel-context.md     ← features, worktrees, config
├── 01-parallel-plan.md        ← matrice de conflits, ordre d'intégration
├── 02-dispatch-log.md         ← agents lancés, statuts
├── 03-monitor-report.md       ← résultats par feature
├── 04-integration-report.md   ← merges, conflits résolus
└── 05-verify-report.md        ← build, tests, résumé final