feature — pipeline de bout en bout

Exécute le cycle de vie de la fonctionnalité en invoquant les skills des phases. Les règles de chaque phase vivent dans son propre skill ; ce skill orchestre seulement — il choisit le mode d'autonomie, sélectionne les phases à exécuter, les pilote dans l'ordre, et conserve l'enregistrement de la exécution.

Annonce au démarrage : « Using the feature skill — {autonomy mode}, phases: {selected}. »

Les phases

/plan et /execute ne sont pas négociables — vous ne pouvez pas construire sans plan, et execute est l'essentiel. Tout le reste est optionnel par fonctionnalité.

Étape 0 : Choisir le mode d'autonomie + l'ensemble des phases — toujours en premier

Écrivez l'enregistrement de l'exécution (ci-dessous) au fur et à mesure de ces choix, puis annoncez-les.

0a. Mode d'autonomie

Détectez à partir de la demande ; ne posez la question que si aucun n'est clair.

Défaut en cas d'ambiguïté : ask — une question, les deux options ci-dessus.

0b. Ensemble des phases

Détection automatique de l'ensemble recommandé, puis : en mode approbation, présentez-le et laissez l'utilisateur l'ajuster ; en mode autonome, enregistrez les choix et continuez.

Heuristiques de détection (recommandez, ne les forcez pas dogmatiquement) :

• Research — incluez quand les exigences sont vagues/ouvertes. Force-inclusion pour la logique du domaine ERP (comptabilité, calcul de coûts, fiscalité, valorisation des stocks, RMA, MRP, planification) : n'inventez jamais la logique du domaine. Ignorez quand l'utilisateur a donné des exigences claires et détaillées pour une fonctionnalité non-domaine.
• Spec — incluez quand le changement touche 3+ fichiers, traverse les modules, ou ajoute un modèle de données (déclencheur propre de spec-writing). Ignorez pour une fonctionnalité simple et bien comprise avec des exigences claires — allez directement au plan.
• Plan / Execute — toujours sur une exécution nouvelle (une exécution reprise peut démarrer à Execute quand un plan approuvé existe déjà — voir Entering mid-pipeline).
• Test — incluez pour les flux visibles pour l'utilisateur. Ignorez quand l'utilisateur dit que c'est simple, veut vérifier manuellement, ou signale le coût des tests navigateur — mais notez-le dans l'enregistrement (« test skipped — user opts to verify manually »).
• Self-review — incluez par défaut (peu coûteux, détecte les Must-fix avant la PR). Ignorez uniquement sur demande.

Si les exigences sont floues et que research est candidate, en mode approbation demandez : « Do you have firm requirements, or should I research and draft them? »

Étape 0c : Ouvrir l'enregistrement de l'exécution — l'artifact de standardisation

Créez .ai/runs/{date}-{slug}.md avant la première phase sélectionnée (phase 1 sur une exécution nouvelle ; une phase ultérieure sur une exécution reprise — voir Entering mid-pipeline). C'est ce qui fait que dix ingénieurs sur la même fonctionnalité produisent des résultats comparables — un journal canonique unique de ce qui a été décidé et pourquoi.

# Feature run: {title}

- Date: {date}            <!-- ask the user or use the injected currentDate; skills have no clock -->
- Mode: approval-per-phase | fully-autonomous
- Request: {the user's ask, verbatim}
- Phase plan: research [run|skip — why] · spec [run|skip — why] · plan [run] · execute [run] · test [run|skip — why] · self-review [run|skip — why]

## Decisions            <!-- autonomous auto-resolutions at 🛑 gates; empty in approval mode -->
- {gate}: {decision} — {rationale} — {timestamp}

## Phase log
- {phase}: {outcome + artifact path}

## Outcome
- {PR link / final status}

Mettez-le à jour à chaque transition de phase et chaque fois qu'un portail autonome est auto-résolu. L'exécution vit dans .ai/runs/ (gitignored) — jamais dans l'arborescence du produit.

Exécuter les phases

Exécutez les phases sélectionnées strictement dans l'ordre ; ignorez les phases non sélectionnées. Annoncez chaque transition en une ligne (« Phase 3: planning — spec approved »). Un portail s'applique uniquement si sa phase s'exécute (ignorer spec → pas de portail Open-Questions).

• Mode approbation : avant chaque phase, pause pour le feu vert de l'utilisateur. Honorez les deux portails 🛑 comme arrêts humains.
• Mode autonome : à chaque portail 🛑, décidez, ajoutez la décision à la section Decisions de l'enregistrement de l'exécution, et continuez — pas de pause.

Entrée mid-pipeline

Commencez à la première phase sélectionnée dont l'artifact manque ou est obsolète :

Règles strictes

• Sur une exécution nouvelle, /plan et /execute s'exécutent toujours — ne les ignorez jamais. Une exécution reprise peut commencer après le plan uniquement quand un plan approuvé existe déjà (voir Entering mid-pipeline).
• En mode approbation, n'ignorez jamais un portail 🛑. En mode autonome, n'ignorez jamais l'enregistrement d'une décision auto-résolue de portail — l'enregistrement est la piste d'audit.
• Ne laissez jamais une phase écrire son artifact ailleurs qu'à l'emplacement canonique — les chemins du tableau des phases sont les seuls corrects.
• Si une phase ultérieure révèle que la spec/le plan était faux, arrêtez, mettez à jour l'artifact (et son changelog), re-gate (ou re-record en mode autonome), puis reprenez.
• Ignorer une phase est une décision enregistrée, pas une omission silencieuse — cela va dans l'enregistrement de l'exécution avec une raison.

Alternative : le conductor

Pour un seul élément étroitement délimité (un bug, une retouche d'utilisabilité, une petite fonctionnalité) avec des critères d'acceptation explicites, préférez /conductor — une boucle supervisée doer→gate→judge au lieu de ce pipeline par phases.