---
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.
