traduction
This commit is contained in:
@@ -0,0 +1,634 @@
|
||||
---
|
||||
description: Exécuter une implémentation par phases avec portes de validation
|
||||
argument-hint: "<feature-slug> [--phase N] [--validate-only]"
|
||||
---
|
||||
|
||||
## 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 exécute l'implémentation par phases de fonctionnalités à partir de la documentation de planification. Elle orchestre des agents spécialisés, impose des portes de validation et garantit la conformité constitutionnelle pendant toute l'implémentation.
|
||||
|
||||
**Prérequis** :
|
||||
- Le dossier de fonctionnalité existe dans `rpi/{feature-slug}/`
|
||||
- La planification est terminée (`rpi/{feature-slug}/plan/PLAN.md` existe)
|
||||
|
||||
**Emplacement de sortie** : `rpi/{feature-slug}/implement/`
|
||||
|
||||
**C'est l'étape 4 du workflow RPI** (étape finale - implémentation réelle).
|
||||
|
||||
## Flags
|
||||
|
||||
- `--phase N` : exécute une phase spécifique (1-8), sinon démarre à la phase 1
|
||||
- `--validate-only` : valide seulement la phase courante, sans implémenter
|
||||
- `--skip-validation` : saute la porte de validation et continue (à utiliser avec prudence)
|
||||
|
||||
## Agents disponibles
|
||||
|
||||
Tous les agents utilisent le **modèle Opus** pour une qualité maximale.
|
||||
|
||||
### Agent d'implémentation
|
||||
|
||||
| Agent | Type | Quand l'utiliser |
|
||||
|-------|------|------------------|
|
||||
| `senior-software-engineer` | Custom | Toutes les tâches d'implémentation |
|
||||
|
||||
### Agents de support
|
||||
|
||||
| Agent | Type | Objectif |
|
||||
|-------|------|----------|
|
||||
| `Explore` | Built-in | Exploration de code pré-implémentation |
|
||||
| `code-reviewer` | Custom | Revue de code et validation qualité |
|
||||
| `constitutional-validator` | Custom | Validation contre la constitution projet |
|
||||
| `documentation-analyst-writer` | Built-in | Génération de documentation |
|
||||
|
||||
### Routage des agents
|
||||
|
||||
Toutes les tâches d'implémentation sont prises en charge par l'agent `senior-software-engineer`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : charger le contexte et les règles
|
||||
|
||||
**Prérequis** : slug extrait de l'entrée utilisateur
|
||||
|
||||
**Processus** :
|
||||
|
||||
### 0.1 Charger la constitution projet
|
||||
|
||||
1. Chercher un document de constitution ou de principes dans le dépôt
|
||||
2. S'il existe, extraire :
|
||||
- Contraintes techniques (type safety, tests, isolation composant)
|
||||
- Principes business (standards qualité, workflow)
|
||||
- Frontières architecturales
|
||||
3. Stocker les contraintes pour les appliquer pendant l'implémentation
|
||||
|
||||
### 0.2 Charger les consignes propres au domaine
|
||||
|
||||
Selon les fichiers à modifier, charger les consignes projet pertinentes :
|
||||
- Vérifier les README propres aux composants
|
||||
- Vérifier les guides de style de code
|
||||
- Vérifier la documentation d'exigences de test
|
||||
|
||||
### 0.3 Analyser le périmètre d'implémentation
|
||||
|
||||
1. Lire `rpi/{feature-slug}/plan/PLAN.md`
|
||||
2. Identifier tous les fichiers à modifier
|
||||
3. Mapper les fichiers vers l'agent d'implémentation
|
||||
|
||||
**Sorties** :
|
||||
- Résumé du contexte constitutionnel
|
||||
- Règles de domaine chargées
|
||||
- Mapping fichiers-agent
|
||||
- Plan d'exécution des phases
|
||||
|
||||
**Validation** :
|
||||
- [ ] Constitution chargée (si elle existe)
|
||||
- [ ] Règles de domaine chargées pour les fichiers affectés
|
||||
- [ ] Tous les fichiers mappés aux agents
|
||||
- [ ] Plan d'exécution compris
|
||||
|
||||
---
|
||||
|
||||
## Workflow d'implémentation par phases
|
||||
|
||||
### Boucle d'implémentation de phase
|
||||
|
||||
Pour chaque phase dans PLAN.md :
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ Phase N: [Phase Name] │
|
||||
├─────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ 1. Code Discovery (Explore Agent) │
|
||||
│ └─→ Comprendre le code existant avant de le changer │
|
||||
│ │
|
||||
│ 2. Implementation (senior-software-engineer) │
|
||||
│ └─→ Implémenter les livrables de la phase │
|
||||
│ │
|
||||
│ 3. Self-Validation │
|
||||
│ └─→ L'ingénieur valide contre la checklist de phase │
|
||||
│ │
|
||||
│ 4. Code Review (code-reviewer Agent) │
|
||||
│ └─→ Sécurité, correction, maintenabilité │
|
||||
│ │
|
||||
│ 5. User Validation Gate │
|
||||
│ └─→ STOP et demander l'approbation utilisateur │
|
||||
│ ├─→ PASS: passer à la phase suivante │
|
||||
│ ├─→ CONDITIONAL PASS: noter les problèmes, continuer │
|
||||
│ └─→ FAIL: corriger les problèmes, revalider │
|
||||
│ │
|
||||
│ 6. Documentation Update │
|
||||
│ └─→ Mettre à jour le statut de phase dans PLAN.md │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Étape 1 : découverte du code (par phase)
|
||||
|
||||
**Agent** : Explore (Built-in, via Task tool)
|
||||
|
||||
**Objectif** : ancrer l'implémentation dans la réalité du code avant tout changement.
|
||||
|
||||
**Processus** :
|
||||
1. Lancer l'agent Explore via Task tool avec `subagent_type="Explore"`
|
||||
2. Demander l'analyse des fichiers affectés par la phase courante
|
||||
3. Comprendre patterns existants, points d'intégration et contraintes
|
||||
|
||||
**Prompt de l'agent Explore** :
|
||||
```
|
||||
Analyze the codebase to prepare for implementing Phase N of [feature-name].
|
||||
|
||||
Files to be modified in this phase:
|
||||
[List files from PLAN.md]
|
||||
|
||||
Investigate and document:
|
||||
|
||||
1. **Current Implementation**
|
||||
- How do these files currently work?
|
||||
- What patterns are used?
|
||||
- What functions/classes will be affected?
|
||||
|
||||
2. **Integration Points**
|
||||
- What other files import or use these modules?
|
||||
- What APIs or interfaces will change?
|
||||
- What tests cover this code?
|
||||
|
||||
3. **Dependencies**
|
||||
- What libraries are used?
|
||||
- What internal utilities are available?
|
||||
- What constraints exist from current code?
|
||||
|
||||
4. **Patterns to Follow**
|
||||
- What coding style is used in these files?
|
||||
- What naming conventions are followed?
|
||||
- What error handling patterns exist?
|
||||
|
||||
5. **Risks and Considerations**
|
||||
- What could break if we change this?
|
||||
- What edge cases exist?
|
||||
- What backward compatibility concerns?
|
||||
|
||||
Provide a discovery summary to inform implementation.
|
||||
```
|
||||
|
||||
**Sortie** : résumé de découverte pour l'agent d'implémentation
|
||||
|
||||
---
|
||||
|
||||
## Étape 2 : implémentation (par phase)
|
||||
|
||||
**Agent** : senior-software-engineer
|
||||
|
||||
**Processus** :
|
||||
1. Utiliser l'agent senior-software-engineer
|
||||
2. Fournir le contexte de découverte de l'étape 1
|
||||
3. Implémenter tous les livrables de la phase
|
||||
4. Respecter les contraintes constitutionnelles et règles projet
|
||||
|
||||
**Template de prompt de l'agent d'implémentation** :
|
||||
```
|
||||
Acting as the [agent-name] agent, implement Phase N deliverables for [feature-name].
|
||||
|
||||
## Context
|
||||
- Constitutional Constraints: [from Phase 0]
|
||||
- Domain Rules: [from Phase 0]
|
||||
- Discovery Summary: [from Step 1]
|
||||
|
||||
## Phase N Deliverables
|
||||
[List from PLAN.md]
|
||||
|
||||
## Files to Modify
|
||||
[List files with specific changes from PLAN.md]
|
||||
|
||||
## Implementation Requirements
|
||||
1. Follow existing code patterns identified in discovery
|
||||
2. Honor constitutional constraints (type safety, testing, etc.)
|
||||
3. Follow project-specific rules (if applicable)
|
||||
4. Write tests for new functionality
|
||||
5. Include appropriate logging
|
||||
6. Handle errors gracefully
|
||||
|
||||
## Quality Checklist
|
||||
- [ ] Code follows existing patterns
|
||||
- [ ] Type annotations present where applicable
|
||||
- [ ] Tests written and passing
|
||||
- [ ] No breaking changes to existing functionality
|
||||
- [ ] Logging added for observability
|
||||
- [ ] Error handling comprehensive
|
||||
|
||||
Implement all deliverables and report what was done.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Étape 3 : auto-validation
|
||||
|
||||
**Agent** : senior-software-engineer (même que l'étape 2)
|
||||
|
||||
**Processus** :
|
||||
1. L'agent valide l'implémentation contre la checklist de phase
|
||||
2. Lancer le linting (utiliser le linter configuré du projet)
|
||||
3. Lancer les tests pertinents pour les changements
|
||||
4. Vérifier que le build réussit
|
||||
|
||||
**Commandes de validation** (à adapter à ton projet) :
|
||||
|
||||
```bash
|
||||
# Run linter
|
||||
[your-linter-command]
|
||||
|
||||
# Run tests
|
||||
[your-test-command]
|
||||
|
||||
# Build/compile
|
||||
[your-build-command]
|
||||
```
|
||||
|
||||
**Checklist d'auto-validation** :
|
||||
- [ ] Tous les livrables implémentés
|
||||
- [ ] Linting OK
|
||||
- [ ] Tests OK
|
||||
- [ ] Build OK
|
||||
- [ ] Aucune régression dans les tests existants
|
||||
- [ ] Contraintes constitutionnelles respectées
|
||||
- [ ] Règles de domaine suivies
|
||||
|
||||
---
|
||||
|
||||
## Étape 4 : revue de code
|
||||
|
||||
**Agent** : code-reviewer (Custom, auto-invoqué)
|
||||
|
||||
**Processus** :
|
||||
1. Invoquer l'agent code-reviewer pour relire les changements
|
||||
2. Se concentrer sur correction, sécurité, maintenabilité
|
||||
3. Corriger les blockers avant de continuer
|
||||
|
||||
**Prompt de l'agent de revue de code** :
|
||||
```
|
||||
Acting as the code-reviewer agent, review the Phase N implementation for [feature-name].
|
||||
|
||||
## Files Changed
|
||||
[List modified files]
|
||||
|
||||
## Changes Made
|
||||
[Summary of implementation]
|
||||
|
||||
## Review Focus
|
||||
- Correctness & tests
|
||||
- Security & dependency hygiene
|
||||
- Architectural boundaries
|
||||
- Clarity over cleverness
|
||||
|
||||
## Constitutional Constraints
|
||||
[From Phase 0]
|
||||
|
||||
Provide review using standard output format.
|
||||
```
|
||||
|
||||
**Verdicts de revue** :
|
||||
- **APPROVED** : passer à la validation utilisateur
|
||||
- **APPROVED WITH SUGGESTIONS** : noter les suggestions, continuer
|
||||
- **NEEDS REVISION** : corriger, relire à nouveau
|
||||
|
||||
---
|
||||
|
||||
## Étape 5 : porte de validation utilisateur
|
||||
|
||||
**CRITIQUE** : cette étape REQUIERT une interaction utilisateur. NE PAS continuer automatiquement.
|
||||
|
||||
**Processus** :
|
||||
1. Présenter la checklist des livrables de phase
|
||||
2. Montrer ce qui a été implémenté (fichiers modifiés, fonctionnalités ajoutées)
|
||||
3. Présenter les critères de validation depuis PLAN.md
|
||||
4. Montrer les résultats de revue de code
|
||||
5. **STOP et attendre la décision utilisateur**
|
||||
|
||||
**Format de demande de validation** :
|
||||
```
|
||||
## Phase N Validation Request
|
||||
|
||||
### Deliverables Completed
|
||||
- [x] [Deliverable 1] - [implementation summary]
|
||||
- [x] [Deliverable 2] - [implementation summary]
|
||||
- ...
|
||||
|
||||
### Files Changed
|
||||
| File | Change Type | Lines |
|
||||
|------|-------------|-------|
|
||||
| [file] | [add/modify] | [±N] |
|
||||
|
||||
### Tests
|
||||
- [x] Unit tests: PASS
|
||||
- [x] Integration tests: PASS
|
||||
- [x] Build: SUCCESS
|
||||
|
||||
### Code Review
|
||||
- Verdict: [APPROVED / APPROVED WITH SUGGESTIONS]
|
||||
- Issues: [None / List]
|
||||
|
||||
### Validation Criteria (from PLAN.md)
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- ...
|
||||
|
||||
---
|
||||
|
||||
**Please validate Phase N:**
|
||||
- **PASS**: Phase complete, proceed to Phase N+1
|
||||
- **CONDITIONAL PASS**: Note issues below, proceed with caution
|
||||
- **FAIL**: Specify issues to fix before proceeding
|
||||
```
|
||||
|
||||
**Décisions utilisateur** :
|
||||
- **PASS** : passer à la phase suivante
|
||||
- **CONDITIONAL PASS** : documenter les problèmes, passer à la phase suivante
|
||||
- **FAIL** : corriger les problèmes, relancer les étapes 2-5
|
||||
|
||||
---
|
||||
|
||||
## Étape 6 : mise à jour documentaire
|
||||
|
||||
**Processus** :
|
||||
1. Mettre à jour `rpi/{feature-slug}/plan/PLAN.md` avec le statut de phase
|
||||
2. Mettre à jour `rpi/{feature-slug}/implement/IMPLEMENT.md` avec les résultats de validation
|
||||
3. Ajouter la validation de chaque phase à IMPLEMENT.md
|
||||
|
||||
### Suivi de statut de phase
|
||||
|
||||
Mettre à jour les checkboxes dans PLAN.md :
|
||||
```markdown
|
||||
- [ ] Phase N: Not Started
|
||||
- [~] Phase N: In Progress
|
||||
- [x] Phase N: Validated (PASS)
|
||||
- [!] Phase N: Conditional Pass (with notes)
|
||||
- [-] Phase N: Failed Validation (needs rework)
|
||||
```
|
||||
|
||||
### Template IMPLEMENT.md
|
||||
|
||||
```markdown
|
||||
# Implementation Record
|
||||
|
||||
**Feature**: [feature-slug]
|
||||
**Started**: [Date]
|
||||
**Status**: [IN_PROGRESS / COMPLETED]
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: [Phase Name]
|
||||
|
||||
**Date**: [Date]
|
||||
**Verdict**: [PASS / CONDITIONAL PASS / FAIL]
|
||||
|
||||
### Deliverables
|
||||
- [x] [Deliverable 1]
|
||||
- [x] [Deliverable 2]
|
||||
|
||||
### Files Changed
|
||||
[List with line counts]
|
||||
|
||||
### Test Results
|
||||
[Test output summary]
|
||||
|
||||
### Code Review
|
||||
[Review verdict and notes]
|
||||
|
||||
### Notes
|
||||
[Any additional notes]
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: [Phase Name]
|
||||
[Same structure as Phase 1...]
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
**Phases Completed**: [N] of [N]
|
||||
**Final Status**: [COMPLETED / IN_PROGRESS]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Gestion des erreurs
|
||||
|
||||
### Échecs d'implémentation
|
||||
|
||||
**Si l'implémentation échoue** :
|
||||
1. Documenter l'échec précis
|
||||
2. Analyser la cause racine
|
||||
3. Essayer une approche alternative (max 2 tentatives)
|
||||
4. Si ça échoue encore, STOP et demander l'avis utilisateur
|
||||
5. NE PAS passer à la phase suivante avec une implémentation cassée
|
||||
|
||||
**Message** : "Implementation failed: [error]. Attempted [N] approaches. User guidance needed."
|
||||
|
||||
### Échecs de tests
|
||||
|
||||
**Si les tests échouent** :
|
||||
1. Analyser la cause (bug code vs bug test)
|
||||
2. Corriger le problème
|
||||
3. Relancer les tests
|
||||
4. Si persistant, documenter et demander à l'utilisateur
|
||||
5. NE PAS marquer la phase terminée avec des tests en échec
|
||||
|
||||
**Message** : "Tests failing: [failures]. Fix attempted but unsuccessful. User review needed."
|
||||
|
||||
### Échecs de build
|
||||
|
||||
**Si le build échoue** :
|
||||
1. Vérifier les erreurs de types
|
||||
2. Vérifier les imports manquants
|
||||
3. Vérifier les erreurs de syntaxe
|
||||
4. Corriger et rebuilder
|
||||
5. Si persistant, escalader à l'utilisateur
|
||||
|
||||
**Message** : "Build failing: [error]. Unable to resolve automatically."
|
||||
|
||||
### Échecs d'agent
|
||||
|
||||
**Si un agent échoue ou timeout** :
|
||||
1. Réessayer une fois avec les mêmes entrées
|
||||
2. Si ça échoue encore, continuer sans la contribution de cet agent
|
||||
3. Documenter la lacune dans la demande de validation
|
||||
|
||||
**Message** : "Agent [name] failed. Proceeding without contribution."
|
||||
|
||||
---
|
||||
|
||||
## Rapport de fin
|
||||
|
||||
À la réussite de toutes les phases :
|
||||
|
||||
```markdown
|
||||
## Implementation Complete
|
||||
|
||||
### Feature Summary
|
||||
- **Feature**: [feature-name]
|
||||
- **Phases Completed**: [N] of [N]
|
||||
|
||||
### Phases Executed
|
||||
| Phase | Status | Notes |
|
||||
|-------|--------|-------|
|
||||
| Phase 1 | PASS | [summary] |
|
||||
| Phase 2 | PASS | [summary] |
|
||||
| ... | ... | ... |
|
||||
|
||||
### Files Modified
|
||||
| File | Change Type | Lines |
|
||||
|------|-------------|-------|
|
||||
| [file] | [type] | [±N] |
|
||||
|
||||
### Tests Added
|
||||
- [test files]
|
||||
|
||||
### Code Review Summary
|
||||
- Blockers Fixed: [N]
|
||||
- Suggestions Addressed: [N]
|
||||
|
||||
### Constitutional Compliance
|
||||
- [ ] Type safety maintained
|
||||
- [ ] Tests written
|
||||
- [ ] Component isolation respected
|
||||
- [ ] No breaking changes
|
||||
|
||||
### Artifacts Created
|
||||
- `rpi/{feature-slug}/plan/PLAN.md` (updated with phase status)
|
||||
- `rpi/{feature-slug}/implement/IMPLEMENT.md` (all phase validations)
|
||||
|
||||
### Next Steps
|
||||
1. Create PR with changes
|
||||
2. Request final human review
|
||||
3. Deploy to staging
|
||||
4. Verify in staging environment
|
||||
5. Deploy to production
|
||||
|
||||
### PR Notes
|
||||
|
||||
**Title**: [{feature-slug}] [Brief description]
|
||||
|
||||
**Summary**:
|
||||
[What was implemented]
|
||||
|
||||
**Changes**:
|
||||
- [List key changes]
|
||||
|
||||
**Testing**:
|
||||
- [How tested]
|
||||
|
||||
**Rollout**:
|
||||
- [Deployment steps]
|
||||
|
||||
**Rollback**:
|
||||
- [Rollback procedure if issues]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Gates
|
||||
|
||||
### Quality gate par phase
|
||||
|
||||
Avant de marquer une phase comme terminée :
|
||||
|
||||
- [ ] Tous les livrables implémentés
|
||||
- [ ] Linting OK
|
||||
- [ ] Tests OK
|
||||
- [ ] Build OK
|
||||
- [ ] Revue de code passée
|
||||
- [ ] Validation utilisateur reçue
|
||||
- [ ] Documentation mise à jour
|
||||
|
||||
### Quality gate finale
|
||||
|
||||
Avant de marquer l'implémentation complète :
|
||||
|
||||
- [ ] Toutes les phases validées
|
||||
- [ ] Aucun test en échec
|
||||
- [ ] Build complet OK
|
||||
- [ ] Conformité constitutionnelle vérifiée
|
||||
- [ ] Règles de domaine suivies
|
||||
- [ ] Notes de PR générées
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
### Quand utiliser cette commande
|
||||
|
||||
- Après que `/rpi:plan` a généré PLAN.md
|
||||
- Quand une implémentation par phases avec portes de validation est nécessaire
|
||||
- Pour les fonctionnalités qui exigent une implémentation structurée
|
||||
|
||||
### Quand NE PAS utiliser cette commande
|
||||
|
||||
- Corrections de bugs (trop lourd, corrige directement)
|
||||
- Changements très simples (<30 minutes de travail)
|
||||
- Prototypage exploratoire
|
||||
- Changements documentation-only
|
||||
|
||||
### Bonnes pratiques
|
||||
|
||||
1. **Relire PLAN.md d'abord** : comprendre ce que tu implémentes
|
||||
2. **Faire confiance à la découverte du code** : laisser l'agent Explore informer l'implémentation
|
||||
3. **Suivre les patterns existants** : laisser la découverte du code informer l'implémentation
|
||||
4. **Ne pas sauter la validation** : les portes existent pour détecter tôt les problèmes
|
||||
5. **Documenter au fil de l'eau** : mettre à jour le statut après chaque phase
|
||||
6. **Demander quand bloqué** : mieux vaut demander que continuer incorrectement
|
||||
|
||||
### Partie du workflow RPI
|
||||
|
||||
Étape 4 sur 4 (Describe → Research → Plan → **Implement**)
|
||||
|
||||
---
|
||||
|
||||
## Exemples de commandes
|
||||
|
||||
### Exécuter toutes les phases
|
||||
|
||||
```bash
|
||||
/rpi:implement "my-feature"
|
||||
```
|
||||
|
||||
### Exécuter une phase spécifique
|
||||
|
||||
```bash
|
||||
/rpi:implement "my-feature" --phase 3
|
||||
```
|
||||
|
||||
### Valider seulement (sans implémentation)
|
||||
|
||||
```bash
|
||||
/rpi:implement "my-feature" --phase 2 --validate-only
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Action post-complétion
|
||||
|
||||
**IMPORTANT** : après avoir terminé l'implémentation (toutes les phases ou une progression significative), demande TOUJOURS à l'utilisateur de compacter la conversation :
|
||||
|
||||
> **Context Management** : ce workflow d'implémentation a consommé beaucoup de contexte. Pour préserver la progression et libérer de l'espace, lance :
|
||||
>
|
||||
> ```
|
||||
> /compact
|
||||
> ```
|
||||
>
|
||||
> Cela résumera la conversation et préservera le statut d'implémentation tout en réduisant l'usage de tokens pour le travail futur.
|
||||
|
||||
**Quand demander le compact** :
|
||||
- Après que toutes les phases sont terminées
|
||||
- Après chaque grande phase (si implémentation multi-session)
|
||||
- Si le contexte devient bas pendant l'implémentation
|
||||
@@ -0,0 +1,416 @@
|
||||
---
|
||||
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.
|
||||
@@ -0,0 +1,381 @@
|
||||
---
|
||||
description: Rechercher et analyser la viabilité d'une fonctionnalité - porte de décision GO/NO-GO
|
||||
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/`).
|
||||
|
||||
**Format d'entrée attendu** : `rpi/{feature-slug}/REQUEST.md`
|
||||
|
||||
## Objectif
|
||||
|
||||
Cette commande effectue une recherche et une analyse complètes des demandes de fonctionnalité **avant** le début de la phase de planification. Elle agit comme une porte GO/NO-GO critique pour déterminer si une idée de fonctionnalité doit passer à la planification détaillée.
|
||||
|
||||
**Objectifs clés** :
|
||||
- Évaluer le product-market fit et la valeur utilisateur
|
||||
- Évaluer la faisabilité et la complexité techniques
|
||||
- Identifier risques et blockers potentiels
|
||||
- Déterminer la bonne approche (build, buy, partner ou decline)
|
||||
- Formuler une recommandation go/no-go avec justification claire
|
||||
|
||||
**Prérequis** :
|
||||
- Le dossier de fonctionnalité existe dans `rpi/{feature-slug}/`
|
||||
- Le fichier de demande existe dans `rpi/{feature-slug}/REQUEST.md`
|
||||
|
||||
**Emplacement de sortie** : `rpi/{feature-slug}/research/RESEARCH.md`
|
||||
|
||||
**C'est l'étape 2 du workflow RPI** (après la description initiale en étape 1).
|
||||
|
||||
## Plan
|
||||
|
||||
1. **Charger le contexte** : lire la description depuis `rpi/{feature-slug}/` et la constitution projet (si elle existe)
|
||||
2. **Parser la demande** : utiliser l'agent requirement-parser pour extraire les exigences structurées
|
||||
3. **Exécuter la recherche multi-phase** :
|
||||
- Phase 1 : parser la demande (agent requirement-parser)
|
||||
- Phase 2 : analyse produit avec alignement constitutionnel (agent product-manager)
|
||||
- Phase 2.5 : découverte technique (agent Explore) - **CRITIQUE : exploration profonde du code**
|
||||
- Phase 3 : faisabilité technique (agent senior-software-engineer)
|
||||
- Phase 4 : évaluation stratégique (agent technical-cto-advisor)
|
||||
- Phase 5 : génération du rapport (agent documentation-analyst-writer)
|
||||
4. **Synthétiser la recommandation** : combiner toutes les analyses en recommandation go/no-go claire
|
||||
5. **Valider la sortie** : vérifier les quality gates
|
||||
6. **Rapporter la fin** : fournir recommandation, prochaines étapes et emplacement du rapport
|
||||
|
||||
## Phases
|
||||
|
||||
### Phase 0 : charger le contexte
|
||||
|
||||
**Prérequis** : slug fourni, `rpi/{feature-slug}/REQUEST.md` existe
|
||||
|
||||
**Processus** :
|
||||
1. **Lire la description de fonctionnalité** :
|
||||
- Lire `rpi/{feature-slug}/REQUEST.md` (requis)
|
||||
- Extraire exigences et objectifs depuis REQUEST.md
|
||||
|
||||
2. **Chercher une constitution projet** (optionnel) :
|
||||
- Chercher un document de constitution ou de principes dans le dépôt
|
||||
- Emplacements courants : `constitution.md`, `PRINCIPLES.md`, `.project/constitution.md`
|
||||
- Si trouvé, extraire principes clés, contraintes et objectifs
|
||||
|
||||
3. **Créer le contexte de recherche** :
|
||||
- Synthétiser en résumé concis pour les agents
|
||||
- Identifier les critères clés d'alignement
|
||||
|
||||
**Sorties** :
|
||||
- Résumé de description de fonctionnalité
|
||||
- Principes constitutionnels (si trouvés)
|
||||
- Critères d'alignement pour évaluation
|
||||
|
||||
**Validation** :
|
||||
- [ ] Le dossier de fonctionnalité existe dans `rpi/{feature-slug}/`
|
||||
- [ ] La description de fonctionnalité est extraite
|
||||
- [ ] La constitution est vérifiée et chargée (si elle existe)
|
||||
|
||||
---
|
||||
|
||||
### Phase 1 : parser la demande de fonctionnalité
|
||||
|
||||
**Prérequis** : Phase 0 terminée
|
||||
|
||||
**Agent** : requirement-parser (domaine planning)
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent requirement-parser** avec la description de fonctionnalité
|
||||
2. **L'agent extrait** :
|
||||
- Nom et type de fonctionnalité
|
||||
- Composant(s) cible(s)
|
||||
- Buts et objectifs
|
||||
- Exigences fonctionnelles et non fonctionnelles
|
||||
- Contraintes et hypothèses
|
||||
- Estimation de complexité
|
||||
- Questions de clarification (le cas échéant)
|
||||
|
||||
3. **Relire les résultats de parsing** :
|
||||
- Si des questions de clarification existent, **STOP et demander à l'utilisateur** avant de continuer
|
||||
|
||||
**Sorties** :
|
||||
- Document d'exigences structurées
|
||||
- Métadonnées de fonctionnalité (nom, type, composant, complexité)
|
||||
- Questions de clarification (le cas échéant)
|
||||
|
||||
---
|
||||
|
||||
### Phase 2 : analyse produit avec alignement constitutionnel
|
||||
|
||||
**Prérequis** : Phase 1 terminée, exigences claires
|
||||
|
||||
**Agent** : product-manager
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent product-manager** avec :
|
||||
- Exigences parsées de la Phase 1
|
||||
- Contexte constitutionnel de la Phase 0
|
||||
|
||||
2. **L'agent analyse** :
|
||||
- **User Value** : qui bénéficie ? quel impact ?
|
||||
- **Market Fit** : cela s'aligne-t-il avec les besoins marché ?
|
||||
- **Product Vision** : cela s'insère-t-il dans la stratégie produit ?
|
||||
- **Constitutional Alignment** : cela s'aligne-t-il avec les principes projet ?
|
||||
- **Constraints Check** : cela viole-t-il des contraintes constitutionnelles ?
|
||||
|
||||
3. **L'agent fournit** :
|
||||
- Score de viabilité produit (High/Medium/Low)
|
||||
- Évaluation de valeur utilisateur
|
||||
- Évaluation d'alignement stratégique
|
||||
- Recommandation de priorité
|
||||
- Préoccupations produit ou red flags
|
||||
|
||||
**Sorties** :
|
||||
- Évaluation de viabilité produit
|
||||
- Analyse de valeur utilisateur
|
||||
- Score d'alignement stratégique
|
||||
- Résumé d'alignement constitutionnel (si applicable)
|
||||
|
||||
---
|
||||
|
||||
### Phase 2.5 : découverte technique (exploration du code)
|
||||
|
||||
**Prérequis** : Phases 1-2 terminées, viabilité produit établie
|
||||
|
||||
**Agent** : Explore (via Task tool avec `subagent_type="Explore"`)
|
||||
|
||||
**Objectif** : **PHASE CRITIQUE** - analyser profondément la codebase existante AVANT d'évaluer la faisabilité technique.
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent Explore** avec les composants cibles
|
||||
2. **L'agent investigue** :
|
||||
- **Existing Implementation** : quel code existe déjà pour une fonctionnalité similaire ?
|
||||
- **Integration Points** : quels systèmes/modules cette fonctionnalité toucherait-elle ?
|
||||
- **Current Architecture** : comment le système courant est-il structuré ?
|
||||
- **Data Models** : quels schémas DB ou structures de données existent ?
|
||||
- **Dependencies** : quelles bibliothèques/services sont déjà intégrés ?
|
||||
- **Existing Patterns** : quels patterns et conventions de code sont utilisés ?
|
||||
|
||||
3. **L'agent fournit** :
|
||||
- **Current State Summary** : ce qui existe aujourd'hui
|
||||
- **Integration Analysis** : où la fonctionnalité proposée s'insérerait
|
||||
- **Code Conflicts** : ce qui casserait ou entrerait en conflit
|
||||
- **Leverage Opportunities** : ce qui peut être réutilisé vs reconstruit
|
||||
- **Technical Constraints** : contraintes réelles venant du code existant
|
||||
|
||||
**Sorties** :
|
||||
- Résumé de l'implémentation courante
|
||||
- Carte des points d'intégration
|
||||
- Conflits de code identifiés
|
||||
- Composants réutilisables identifiés
|
||||
- Contraintes techniques issues du code
|
||||
|
||||
**Critique** : cette phase garantit que la Phase 3 repose sur la **réalité du code**, pas sur des hypothèses.
|
||||
|
||||
---
|
||||
|
||||
### Phase 3 : évaluation de faisabilité technique
|
||||
|
||||
**Prérequis** : Phases 1-2.5 terminées, code exploré
|
||||
|
||||
**Agent** : senior-software-engineer
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent senior-software-engineer** avec :
|
||||
- Exigences parsées de la Phase 1
|
||||
- Contexte produit de la Phase 2
|
||||
- **Résultats de découverte technique de la Phase 2.5**
|
||||
|
||||
2. **L'agent analyse** (informé par les découvertes de Phase 2.5) :
|
||||
- **Technical Approach** : quelles options d'implémentation ?
|
||||
- **Complexity** : à quel point est-ce difficile à construire ?
|
||||
- **Dependencies** : quels systèmes/services sont nécessaires ?
|
||||
- **Technical Debt** : cela crée-t-il ou réduit-il de la dette technique ?
|
||||
- **Risks** : quels sont les risques techniques ?
|
||||
|
||||
3. **L'agent fournit** :
|
||||
- Score de faisabilité technique (High/Medium/Low)
|
||||
- Approche recommandée (avec alternatives)
|
||||
- Estimation de complexité (Simple/Medium/Complex)
|
||||
- Risques techniques et mitigations
|
||||
|
||||
**Sorties** :
|
||||
- Score de faisabilité technique
|
||||
- Approche d'implémentation recommandée
|
||||
- Estimation de complexité et d'effort
|
||||
- Risques techniques et mitigations
|
||||
|
||||
---
|
||||
|
||||
### Phase 4 : évaluation stratégique
|
||||
|
||||
**Prérequis** : Phases 1-3 terminées
|
||||
|
||||
**Agent** : technical-cto-advisor
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent technical-cto-advisor** avec les sorties de toutes les phases précédentes
|
||||
|
||||
2. **L'agent synthétise** :
|
||||
- **Overall Assessment** : combinaison des perspectives produit + technique
|
||||
- **Strategic Alignment** : alignement avec principes d'ingénierie ET constitution projet
|
||||
- **Risk vs. Reward** : la valeur vaut-elle l'effort et le risque ?
|
||||
- **Alternative Options** : build, buy, partner, defer ou decline ?
|
||||
|
||||
3. **L'agent fournit** :
|
||||
- **Go/No-Go Recommendation** : décision claire avec niveau de confiance
|
||||
- **Rationale** : raisonnement détaillé
|
||||
- **Recommended Approach** : si "go", meilleure voie à suivre
|
||||
- **Conditions** : prérequis éventuels pour continuer
|
||||
- **Risks** : risques clés si on continue
|
||||
|
||||
**Sorties** :
|
||||
- Recommandation Go/No-Go
|
||||
- Justification stratégique
|
||||
- Approche recommandée
|
||||
- Résumé des risques
|
||||
|
||||
---
|
||||
|
||||
### Phase 5 : générer le rapport de recherche
|
||||
|
||||
**Prérequis** : Phases 1-4 terminées
|
||||
|
||||
**Agent** : documentation-analyst-writer (via Task tool)
|
||||
|
||||
**Processus** :
|
||||
1. **Lancer l'agent documentation-analyst-writer** avec toutes les sorties de phases
|
||||
|
||||
2. **L'agent génère un rapport** avec sections :
|
||||
- **Executive Summary** : aperçu d'un paragraphe avec recommandation
|
||||
- **Feature Overview** : nom, type, composant, objectifs
|
||||
- **Requirements Summary** : exigences fonctionnelles et non fonctionnelles clés
|
||||
- **Product Analysis** : valeur utilisateur, market fit, alignement stratégique
|
||||
- **Technical Discovery** : état actuel, points d'intégration, contraintes du code
|
||||
- **Technical Analysis** : faisabilité, approche, complexité, risques
|
||||
- **Strategic Recommendation** : go/no-go avec justification détaillée
|
||||
- **Next Steps** : quoi faire selon la recommandation
|
||||
|
||||
3. **L'agent crée le fichier Markdown** : `rpi/{feature-slug}/research/RESEARCH.md`
|
||||
|
||||
**Sorties** :
|
||||
- Rapport de recherche complet enregistré dans `rpi/{feature-slug}/research/RESEARCH.md`
|
||||
|
||||
---
|
||||
|
||||
## Délégation aux sous-agents
|
||||
|
||||
Cette commande orchestre 6 agents spécialistes :
|
||||
|
||||
| Phase | Agent | Type | Emplacement |
|
||||
|-------|-------|------|-------------|
|
||||
| Phase 1 | requirement-parser | Custom | .claude/agents/requirement-parser.md |
|
||||
| Phase 2 | product-manager | Custom | .claude/agents/product-manager.md |
|
||||
| Phase 2.5 | Explore | Built-in | Task tool avec subagent_type="Explore" |
|
||||
| Phase 3 | senior-software-engineer | Custom | .claude/agents/senior-software-engineer.md |
|
||||
| Phase 4 | technical-cto-advisor | Custom | .claude/agents/technical-cto-advisor.md |
|
||||
| Phase 5 | documentation-analyst-writer | Built-in | Task tool avec subagent_type="documentation-analyst-writer" |
|
||||
|
||||
---
|
||||
|
||||
## Rapport de fin
|
||||
|
||||
Rapporter les éléments suivants en cas de réussite :
|
||||
|
||||
### Research Recommendation
|
||||
|
||||
**Decision**: [GO | NO-GO | CONDITIONAL GO | DEFER]
|
||||
|
||||
**Confidence**: [High | Medium | Low]
|
||||
|
||||
**Rationale** (1-2 phrases) :
|
||||
[Raisons clés de la recommandation]
|
||||
|
||||
---
|
||||
|
||||
### Research Summary
|
||||
|
||||
**Feature**: {feature-name}
|
||||
**Type**: {feature-type}
|
||||
**Component**: {target-component}
|
||||
**Complexity**: {Simple | Medium | Complex}
|
||||
|
||||
**Scores**:
|
||||
- Product Viability: [High/Medium/Low]
|
||||
- Technical Feasibility: [High/Medium/Low]
|
||||
- Overall Assessment: [High/Medium/Low]
|
||||
|
||||
**Key Risks**:
|
||||
1. {risk-1}
|
||||
2. {risk-2}
|
||||
3. {risk-3}
|
||||
|
||||
---
|
||||
|
||||
### Emplacement du rapport
|
||||
|
||||
**Full Research Report**: `rpi/{feature-slug}/research/RESEARCH.md`
|
||||
|
||||
---
|
||||
|
||||
### Prochaines étapes
|
||||
|
||||
Selon la recommandation **[GO/NO-GO]** :
|
||||
|
||||
**If GO** :
|
||||
1. Relire le rapport : `rpi/{feature-slug}/research/RESEARCH.md`
|
||||
2. Passer à la planification : `/rpi:plan "{feature-slug}"`
|
||||
|
||||
**If CONDITIONAL GO** :
|
||||
1. Relire les conditions dans le rapport
|
||||
2. Traiter les conditions avant de continuer
|
||||
3. Relancer la recherche si nécessaire
|
||||
|
||||
**If DEFER** :
|
||||
1. Relire la recommandation de calendrier dans le rapport
|
||||
2. Revenir dessus quand le timing est approprié
|
||||
|
||||
**If NO-GO** :
|
||||
1. Relire la justification dans le rapport
|
||||
2. Considérer les alternatives mentionnées
|
||||
3. Archiver pour référence future
|
||||
|
||||
---
|
||||
|
||||
## Gestion des erreurs
|
||||
|
||||
**Si REQUEST.md n'existe pas** :
|
||||
- Action : arrêter et informer l'utilisateur
|
||||
- Message : "Feature request file `rpi/{feature-slug}/REQUEST.md` not found. Create the feature folder and REQUEST.md first (Step 1: Describe in Plan Mode)."
|
||||
|
||||
**Si la description est trop vague** :
|
||||
- Action : requirement-parser identifiera les questions de clarification
|
||||
- Message : "Need more information. Please answer:"
|
||||
- Suite : attendre les réponses, puis continuer
|
||||
|
||||
**Si les agents échouent ou timeout** :
|
||||
- Action : réessayer une fois
|
||||
- Suite : si le retry échoue, demander à l'utilisateur s'il faut continuer avec une recherche incomplète
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- **When to Use** : après que l'étape 1 (Describe) a créé le dossier de fonctionnalité
|
||||
- **Critical Gate** : évite l'effort gaspillé sur des fonctionnalités non viables
|
||||
- **Part of RPI Workflow** : étape 2 sur 4 (Describe → Research → Plan → Implement)
|
||||
|
||||
---
|
||||
|
||||
## Action post-complétion
|
||||
|
||||
**IMPORTANT** : après avoir terminé le workflow de recherche, demande TOUJOURS à l'utilisateur de compacter la conversation :
|
||||
|
||||
> **Context Management** : ce workflow de recherche a consommé beaucoup de contexte. Pour libérer de l'espace pour les étapes suivantes, lance :
|
||||
>
|
||||
> ```
|
||||
> /compact
|
||||
> ```
|
||||
>
|
||||
> Cela résumera la conversation et préservera les constats importants tout en réduisant l'usage de tokens pour les commandes suivantes.
|
||||
Reference in New Issue
Block a user