Créer une feature avec APEX v2

Ce tutoriel montre comment utiliser /kensho pour implémenter une feature, du cas simple au pipeline complet.

Vue d'ensemble

/kensho est le skill principal du framework. Il orchestre un pipeline de 8 steps (00 a 07) dont certains sont optionnels selon les flags.

L'ancien skill /feature a été fusionné dans /kensho via les flags -c (clarify) et -d (design).

Cas 1 — Implémentation simple

Ideal pour une modification connue, sans analyse produit nécessaire.

/kensho -a -s implement user registration

Flags :

• -a (auto) : passe les confirmations automatiquement
• -s (save) : sauvegarde les outputs dans docs/kensho/{task-id}/

Steps exécutés :

Step	Action
00 — Init	Parse les flags, génère un task-id
02 — Analyze	Explore le codebase, identifie les fichiers et patterns existants
03 — Plan	Planifie les changements fichier par fichier
04 — Execute	Implémente selon le plan
06 — Validate	Vérifie que le code compile et que les tests passent
07 — Finish	Commit conventionnel + résumé

Cas 2 — Feature avec analyse produit

Quand la feature touche plusieurs couches ou nécessite une réflexion architecture. C'est le remplacant direct de l'ancien /feature.

/kensho -c -d -a -s add user profile page

Flags supplémentaires :

• -c (clarify) : active le step 01 — clarification des besoins avec le agent analyst
• -d (design) : enrichit le step 03 — plan d'architecture avec le agent architect

Steps exécutés :

Step	Action	Agent
00 — Init	Parse les flags	—
01 — Clarify	Pose les questions, produit une spec avec user stories	analyst (opus)
02 — Analyze	Explore le codebase	—
03 — Plan	Concoit l'architecture + plan fichier par fichier	architect (opus)
04 — Execute	Implémente (agents parallèles si multi-stack)	executor (sonnet)
05 — Review	Review qualité + sécurité	code-reviewer (opus)
06 — Validate	Compilation + tests	—
07 — Finish	Commit + résumé	—

Remplace /feature

/kensho -c -d remplace l'ancien /feature. Il produit les mêmes outputs (spec + plan d'architecture) mais dans le pipeline unifié APEX v2.

Cas 3 — Pipeline complet

Pour les features critiques : paiement, authentification, sécurité.

/kensho -c -d -x -t -s add payment processing

Flags supplémentaires :

• -x (examine) : active la review adversariale dans le step 05
• -t (test) : ajoute la création et l'exécution des tests dans le step 06

Steps exécutés :

Step	Action
00 — Init	Parse les flags
01 — Clarify	Cadrage des besoins
02 — Analyze	Exploration codebase
03 — Plan	Architecture + plan d'implémentation
04 — Execute	Implémentation (agents parallèles)
05 — Review	Review adversariale + feedback loop vers fixers
06 — Validate	Compilation + tests + création de tests (-t)
07 — Finish	Commit + résumé

Agents parallèles

Au step 04 (Execute), APEX peut dispatcher plusieurs agents en parallèle si le plan identifie des domaines indépendants :

# Exemple : step-04-execute.md
agents:
  - name: backend-dev
    type: executor
    model: sonnet

    profile: rust
    prompt: "Implémente les tâches backend..."

  - name: frontend-dev
    type: executor
    model: sonnet

    profile: vue-typescript
    prompt: "Implémente les tâches frontend..."

Les deux agents partagent les mêmes artifacts (spec, plan, tasks) mais travaillent sur des fichiers différents.

Au step 05 (Review), les reviewers peuvent renvoyer des corrections :

1. Reviewers lancés en parallèle (qa + security + quality)
2. Findings collectés
3. Si findings critiques : fixers relancés en parallèle
4. Re-review (jusqu'à max_rounds ou 0 findings critiques)

Table d'adaptation par taille

Taille	Fichiers	Commande	Steps actifs
XS	1 fichier	/kensho -a -s {task}	00 → 02 → 04 → 06 → 07
S	2-3 fichiers	/kensho -a -s {task}	00 → 02 → 03 → 04 → 06 → 07
M	4-10 fichiers	/kensho -c -d -a -s {task}	Pipeline complet 00 → 07
L	10+ fichiers	/kensho -c -d -x -t -s {task}	Pipeline complet avec review adversariale et tests

XS saute les steps d'analyse produit

Pour 1-2 fichiers, -c (clarify) et -d (design) ajoutent de la friction sans valeur. Réservez-les aux tâches M et L.

Outputs produits

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

docs/kensho/01-user-registration/
├── context.md        ← task-id, flags, description, timestamp
├── spec.md           ← output du step 01 Clarify (si -c)
├── analysis.md       ← output du step 02 Analyze
├── plan.md           ← output du step 03 Plan
├── review.md         ← output du step 05 Review (si -x)
└── summary.md        ← output du step 07 Finish

Ces fichiers permettent de reprendre une tâche interrompue avec -r :

/kensho -r 01-user-registration

Reprendre une tâche interrompue

/kensho -r {task-id}

APEX relit docs/kensho/{task-id}/context.md, identifie le dernier step complété, et reprend depuis le suivant.

Flag -i pour configurer interactivement

Si vous ne connaissez pas encore les flags, utilisez -i (interactive) : APEX vous pose les questions et configure le pipeline avant de démarrer.

/kensho -i add user profile page

Référence rapide des flags

Flag	Nom	Effet
-a	auto	Passe les confirmations
-c	clarify	Active le step 01 — analyse produit (agent analyst)
-d	design	Enrichit le step 03 — architecture (agent architect)
-x	examine	Active la review adversariale au step 05
-t	test	Ajoute la création et exécution des tests au step 06
-s	save	Sauvegarde les outputs dans docs/kensho/
-e	economy	Désactive les subagents (économise les tokens)
-r	resume	Reprend une tâche existante
-i	interactive	Configure les flags interactivement