---
description: Créer une documentation de planification complète pour une fonctionnalité
argument-hint: "<feature-slug>"
---

## Entrée utilisateur

```text
$ARGUMENTS
```

Tu **DOIS** parser l'entrée utilisateur pour extraire le slug de fonctionnalité (le nom du dossier dans `rpi/`).

## Objectif

Cette commande crée une documentation de planification complète pour une demande de fonctionnalité. Elle génère spécifications détaillées, design technique et plans d'implémentation dans le dossier RPI de la fonctionnalité.

**Prérequis** :
- Le dossier de fonctionnalité existe dans `rpi/{feature-slug}/`
- La recherche est terminée avec recommandation GO (`rpi/{feature-slug}/research/RESEARCH.md` existe)

**Emplacement de sortie** : tous les fichiers sont enregistrés dans `rpi/{feature-slug}/plan/`

**C'est l'étape 3 du workflow RPI** (après approbation GO par Research).

## Plan

1. **Charger le contexte** : lire le rapport de recherche et la constitution projet (si elle existe)
2. **Comprendre les exigences** : parser le périmètre et les exigences de fonctionnalité
3. **Analyser les exigences techniques** : relire architecture et dépendances
4. **Concevoir l'architecture** : créer architecture haut niveau et contrats API
5. **Découper l'implémentation** : créer un découpage de tâches par phases
6. **Générer la documentation** : créer les fichiers structurés
7. **Valider la sortie** : garantir que toutes les quality gates passent
8. **Rapporter la fin** : fournir résumé et prochaines étapes

## Phases

### Phase 0 : charger le contexte

**Prérequis** : slug fourni

**Processus** :
1. **Vérifier que la recherche est terminée** :
   - Vérifier que `rpi/{feature-slug}/research/RESEARCH.md` existe
   - Vérifier la recommandation GO (avertir si NO-GO ou CONDITIONAL)

2. **Lire les constats de recherche** :
   - Extraire l'analyse produit
   - Extraire la découverte technique
   - Extraire l'évaluation de faisabilité technique
   - Noter risques et contraintes

3. **Charger la constitution projet** (si elle existe) :
   - Chercher un document de constitution ou principes dans le dépôt
   - Extraire contraintes et préférences pertinentes

**Sorties** :
- Résumé de recherche
- Contexte constitutionnel (si trouvé)
- Contraintes de planification

**Validation** :
- [ ] Le rapport de recherche existe
- [ ] La recommandation GO est confirmée
- [ ] La constitution est chargée (si elle existe)

---

### Phase 1 : comprendre les exigences de fonctionnalité

**Prérequis** : Phase 0 terminée

**Processus** :
1. **Parser la description de fonctionnalité** depuis le rapport :
   - Extraire nom et objectif principal
   - Identifier les composants cibles
   - Comprendre si la fonctionnalité est orientée utilisateur ou technique
   - Déterminer le niveau de complexité

2. **Identifier les composants affectés** :
   - Composant principal
   - Composants secondaires (points d'intégration)
   - Utilitaires partagés nécessaires
   - Dépendances externes

3. **Rechercher les patterns existants** :
   - Chercher des fonctionnalités similaires dans la codebase
   - Relire l'architecture et les patterns de composants
   - Identifier code et patterns réutilisables

**Sorties** :
- Document de périmètre de fonctionnalité (interne)
- Liste des composants affectés
- Catalogue des patterns existants

**Validation** :
- [ ] Nom et objectif clairement définis
- [ ] Composants cibles identifiés
- [ ] Complexité évaluée

---

### Phase 2 : analyser les exigences techniques

**Prérequis** : Phase 1 terminée

**Processus** :
1. **Relire l'architecture composant** :
   - Lire README et documentation du composant
   - Relire la structure de code existante
   - Identifier les patterns architecturaux utilisés

2. **Identifier les dépendances techniques** :
   - Dépendances internes (autres composants, utilitaires partagés)
   - Dépendances externes (API, services, bibliothèques)
   - Exigences base de données/stockage
   - Besoins d'authentification/autorisation

3. **Évaluer les points d'intégration** :
   - API à créer ou modifier
   - Changements de schéma DB requis
   - Flows d'événements/messages
   - Intégration frontend-backend

4. **Évaluer les risques techniques** :
   - Breaking changes sur fonctionnalités existantes
   - Impacts performance
   - Préoccupations sécurité
   - Besoins de migration de données

**Sorties** :
- Document d'exigences techniques (interne)
- Carte des dépendances
- Diagramme des points d'intégration
- Évaluation des risques

**Validation** :
- [ ] Architecture composant comprise
- [ ] Toutes les dépendances identifiées
- [ ] Points d'intégration cartographiés
- [ ] Risques techniques évalués

---

### Phase 3 : concevoir l'architecture de fonctionnalité

**Prérequis** : Phases 1-2 terminées

**Agent** : senior-software-engineer

**Processus** :
1. **Concevoir l'architecture haut niveau** :
   - Structure composants/modules
   - Diagrammes de flux de données
   - Interfaces API
   - Changements de schéma DB

2. **Définir l'approche d'implémentation** :
   - Structure et organisation des fichiers
   - Patterns d'organisation du code
   - Stratégie de test
   - Approche de gestion d'erreurs

3. **Planifier les changements DB/stockage** (si applicable) :
   - Nouvelles collections/tables
   - Modifications de schéma
   - Stratégie de migration
   - Règles de validation des données

4. **Concevoir les contrats API** (si applicable) :
   - Formats request/response
   - Exigences d'authentification
   - Réponses d'erreur

5. **Planifier la stratégie de test** :
   - Exigences de tests unitaires
   - Scénarios de tests d'intégration
   - Cas de tests end-to-end

**Sorties** :
- Document de design d'architecture (interne)
- Spécifications API
- Design du schéma DB
- Stratégie de test

**Validation** :
- [ ] Architecture haut niveau conçue
- [ ] Approche d'implémentation définie
- [ ] Changements DB planifiés (si nécessaire)
- [ ] Contrats API spécifiés (si nécessaire)
- [ ] Stratégie de test complète

---

### Phase 4 : découper les tâches d'implémentation

**Prérequis** : Phases 1-3 terminées

**Processus** :
1. **Identifier les phases d'implémentation** :
   - Découper la fonctionnalité en 3-5 phases logiques
   - Chaque phase doit livrer une fonctionnalité opérationnelle et testable
   - Les phases doivent se construire progressivement

2. **Créer le découpage de tâches par phase** :
   - Lister les tâches d'implémentation spécifiques
   - Estimer la complexité (Low/Medium/High)
   - Identifier les dépendances entre tâches
   - Assigner aux zones de code appropriées

3. **Définir les critères de succès** :
   - Critères d'acceptation pour chaque phase
   - Exigences de test
   - Exigences de documentation

4. **Identifier les opportunités de parallélisation** :
   - Tâches faisables en parallèle
   - Travail frontend/backend parallèle
   - Développement de modules indépendants

**Sorties** :
- Plan d'implémentation par phases
- Découpage de tâches avec estimations
- Critères de succès par phase
- Graphe de dépendances

**Validation** :
- [ ] Fonctionnalité découpée en 3-5 phases logiques
- [ ] Chaque phase a des tâches spécifiques
- [ ] Toutes les tâches ont une estimation de complexité
- [ ] Dépendances clairement marquées
- [ ] Critères de succès définis

---

### Phase 5 : générer la documentation

**Prérequis** : Phases 1-4 terminées

**Agent** : documentation-analyst-writer (via Task tool)

**Processus** :
1. **Générer pm.md** (Product Requirements) :
   - Description de fonctionnalité et user stories
   - Alignement constitutionnel (si applicable)
   - Valeur business et métriques de succès
   - Personas utilisateurs et cas d'usage
   - Critères d'acceptation
   - Éléments hors périmètre

2. **Générer ux.md** (User Experience Design) :
   - Mockups UI (description textuelle)
   - Flows utilisateur et interactions
   - Considérations d'accessibilité
   - États d'erreur et edge cases

3. **Générer eng.md** (Technical Specification) :
   - Design d'architecture
   - Spécifications API
   - Changements de schéma DB
   - Stack technologique
   - Risques techniques et mitigation

4. **Générer PLAN.md** (Implementation Roadmap) :
   - Découpage d'implémentation par phases
   - Liste de tâches avec estimations par phase
   - Dépendances et ordre
   - Critères de succès par phase
   - Exigences de test
   - Checkpoints de validation

**Fichiers de sortie** (tous enregistrés dans `rpi/{feature-slug}/plan/`) :
- `pm.md` - Exigences produit
- `ux.md` - Design UX
- `eng.md` - Spécification technique
- `PLAN.md` - Roadmap d'implémentation détaillée

**Validation** :
- [ ] Les 4 fichiers sont présents (pm, ux, eng, PLAN)
- [ ] pm.md couvre les exigences business
- [ ] ux.md traite l'expérience utilisateur
- [ ] eng.md fournit la spécification technique
- [ ] PLAN.md contient l'implémentation par phases
- [ ] Aucun placeholder ne reste
- [ ] Le formatage Markdown est propre

---

## Délégation aux sous-agents

Cette commande orchestre des agents spécialistes :

| Phase | Agent | Type | Objectif |
|-------|-------|------|----------|
| Phase 3 | senior-software-engineer | Custom | Design d'architecture |
| Phase 5 | product-manager | Custom | Exigences produit (pm.md) |
| Phase 5 | ux-designer | Custom | Expérience utilisateur (ux.md) |
| Phase 5 | senior-software-engineer | Custom | Spécification technique (eng.md) |
| Phase 5 | documentation-analyst-writer | Built-in | Synthèse documentaire |

### Invocation des agents

**Agents custom** (product-manager, senior-software-engineer, ux-designer) :
- Claude Code les détecte automatiquement depuis `.claude/agents/`
- Référence-les naturellement : "Acting as the senior-software-engineer agent..."
- Aucune invocation Task tool nécessaire

**Agent built-in** (documentation-analyst-writer) :
- Utiliser Task tool avec `subagent_type="documentation-analyst-writer"`

---

## Rapport de fin

Rapporter les éléments suivants en cas de réussite :

### Sorties créées

**Documentation Folder**: `rpi/{feature-slug}/plan/`

Fichiers créés :
- **pm.md** : exigences produit et user stories ({Y} stories)
- **ux.md** : design d'expérience utilisateur ({Z} flows)
- **eng.md** : spécification technique ({A} API, {B} changements de schéma)
- **PLAN.md** : roadmap détaillée ({C} phases, {D} tâches)

### Résumé de fonctionnalité

- **Feature Name**: {feature-name}
- **Target Component**: {component-name}
- **Complexity**: {Simple/Medium/Complex}
- **Implementation Phases**: {N} phases
- **Total Tasks**: {M} tâches
- **Dependencies**: {Y} internes, {Z} externes

### Aperçu technique

- **Architecture Pattern**: {pattern-name}
- **APIs Added/Modified**: {N} API
- **Database Changes**: {Y} collections/tables
- **Testing Requirements**: {Z} suites de tests
- **Risk Level**: {Low/Medium/High}

### Phases d'implémentation

1. **Phase 1** : {phase-name} - {task-count} tâches
2. **Phase 2** : {phase-name} - {task-count} tâches
3. **Phase 3** : {phase-name} - {task-count} tâches
[Continuer pour toutes les phases...]

---

### Prochaines étapes

1. **Relire la documentation** :
   - Lire les docs de planification dans `rpi/{feature-slug}/plan/`
   - Relire la spec technique dans `eng.md`
   - Comprendre les phases d'implémentation dans `PLAN.md`

2. **Valider avec les parties prenantes** :
   - Revue produit de pm.md
   - Revue UX de ux.md
   - Revue technique de eng.md

3. **Commencer l'implémentation** :
   - Lancer `/rpi:implement "{feature-slug}"` pour exécuter l'implémentation par phases
   - Suivre les phases de PLAN.md
   - Compléter les portes de validation à chaque phase

---

## Gestion des erreurs

**Si le rapport de recherche n'existe pas** :
- Action : arrêter et informer l'utilisateur
- Message : "Research report not found. Run `/rpi:research` first."

**Si la recommandation de recherche est NO-GO** :
- Action : avertir l'utilisateur mais permettre de continuer
- Message : "Research recommended NO-GO. Proceed anyway? (y/n)"

**Si le composant cible n'existe pas** :
- Action : confirmer avec l'utilisateur s'il s'agit d'un nouveau composant
- Message : "Component not found. Is this a new component?"

**Si l'agent documentation échoue** :
- Action : générer la documentation directement
- Warning : "Documentation may not fully adhere to standards"

---

## Notes

- **Prerequisites** : recherche terminée avec recommandation GO
- **Part of RPI Workflow** : étape 3 sur 4 (Describe → Research → Plan → Implement)

**Bonnes pratiques** :
1. **Relire la recherche d'abord** : assure-toi de comprendre l'évaluation de viabilité
2. **Exploiter la découverte** : utilise la découverte technique de la phase recherche
3. **Être spécifique** : les plans détaillés mènent à une implémentation plus fluide
4. **Valider tôt** : relis les docs avant d'implémenter

---

## Action post-complétion

**IMPORTANT** : après avoir terminé le workflow de planification, demande TOUJOURS à l'utilisateur de compacter la conversation :

> **Context Management** : ce workflow de planification a consommé beaucoup de contexte. Pour libérer de l'espace pour l'implémentation, lance :
>
> ```
> /compact
> ```
>
> Cela résumera la conversation et préservera les décisions de planification tout en réduisant l'usage de tokens pour la phase d'implémentation.
