Discovery

---
name: discovery
description: "Découverte approfondie avant développement. Besoin vague, complexe ou multi-interprétable. Mots-clés : interview, pose-moi des questions, discovery. Ne se charge PAS quand : question simple, clarification rapide, demande technique directe et précise."
---

# Interview — Mode découverte structuré

Mode de découverte pour comprendre en profondeur un besoin avant de proposer une solution.

## Activation

- Demande explicite : `/interview`, "mode interview", "pose-moi des questions"
- Besoin flou : description vague, projet complexe, multiples interprétations possibles
- **Ne pas activer** si l'utilisateur a déjà un plan clair et des specs précises — le mode interview ralentirait inutilement

## Scoring de maturité

Évalue en continu la clarté du besoin :

| Niveau | État | Action |
|--------|------|--------|
| 1/5 | Idée vague | Exploration large |
| 2/5 | Concept défini | Creuser les détails |
| 3/5 | Features identifiées | Rechercher les alternatives |
| 4/5 | Choix techniques actés | Valider le découpage |
| 5/5 | Plan prêt | Passer au code |

Affiche le score à chaque étape : "📊 **Maturité : X/5**"

Passer au code avant 5/5 produit des itérations coûteuses — le temps investi ici économise des refactors.

## Workflow

### Phase 1 — Exploration initiale

1. **Reformuler** ce qui a été compris en 2-3 phrases
2. **Identifier** les zones floues
3. **Poser 2-3 questions ouvertes** maximum (pas un interrogatoire)

Questions de départ :
- "Quel problème concret essaies-tu de résoudre ?"
- "Qui va utiliser ça et dans quel contexte ?"
- "Tu pars de zéro ou tu améliores quelque chose d'existant ?"

### Phase 2 — Recherche d'alternatives

**Toujours chercher** avant de proposer du custom :
- Solutions open-source existantes (GitHub, npm, pip, etc.)
- Services/API qui font déjà le travail
- Patterns et architectures éprouvés

Utilise la recherche web pour trouver des alternatives concrètes.

Présenter :
> "J'ai trouvé X et Y qui font quelque chose de similaire. Voici leurs forces/limites. Tu veux s'en inspirer, les utiliser, ou partir sur du custom ?"

### Phase 3 — Approfondissement itératif

Pour chaque réponse :

1. **Reformuler avec une analogie** — "Si je comprends bien, c'est comme [analogie] mais avec [différence]"
2. **Se documenter** si un concept technique est mentionné — chercher la doc officielle, vérifier les bonnes pratiques
3. **Creuser** les implications non mentionnées :
   - Contraintes techniques (perf, sécu, scalabilité)
   - Cas limites et edge cases
   - Maintenance future
   - Utilisateurs et leurs parcours

### Phase 4 — Découpage en features

Quand la vision est claire (maturité 3+), proposer :

```
## Features identifiées

### MVP (essentiel pour que ça marche)
- [ ] Feature 1 : [description courte]
- [ ] Feature 2 : [description courte]

### V1 (important mais pas bloquant pour le lancement)
- [ ] Feature 3 : [description courte]

### Plus tard (nice-to-have)
- [ ] Feature 4 : [description courte]
```

"Ce découpage te semble cohérent ? Tu changerais les priorités ?"

### Phase 5 — Fiche projet

Quand la maturité atteint 5/5, générer une fiche synthétique :

```
## Fiche projet — [Nom]

**Problème :** [1-2 phrases]
**Solution :** [1-2 phrases]
**Utilisateurs :** [cible]
**Stack :** [choisi et justifié]
**Alternatives écartées :** [et pourquoi]

### Features MVP
- [liste]

### Choix techniques
- [décisions actées avec justification]

### Contraintes identifiées
- [perf, sécu, limites, etc.]
```

Cette fiche sert d'input direct pour `/codebloom:setup` ou pour lancer l'implémentation.

> "Récap final : [résumé]. On est alignés ? Je peux passer au plan détaillé ?"

## Règles

- **Max 3 questions par message** — sinon c'est un interrogatoire
- **Toujours reformuler** avant de poser la question suivante
- **Chercher les alternatives** — ne pas réinventer la roue
- **Utiliser des analogies** — ça force à vraiment comprendre
- **Accepter l'incertitude** — "Je ne suis pas sûr de comprendre X, tu peux préciser ?"
- **Pas de code avant 5/5** — coder trop tôt crée de la dette technique qu'on paie cher après

## 6 Forcing Questions — Valider avant de construire

Quand l'utilisateur veut construire un produit ou une feature significative, poser ces questions pour valider le besoin réel :

1. **Quelle preuve de comportement** (pas d'intérêt) que quelqu'un veut ça ? — "Tout le monde en a besoin" = signal que le problème n'est pas assez douloureux. "Sarah chez Acme passe 10h/semaine dessus" = signal réel.
2. **Quel est le workaround actuel ?** — Si personne ne contourne le problème, personne ne paiera pour la solution.
3. **Nommer la personne spécifique** la plus désespérée pour cette solution — Pas un persona, un humain réel.
4. **Quelle est la plus petite version** qui vaut le coup cette semaine ? — Force le MVP radical.
5. **As-tu regardé quelqu'un l'utiliser ?** Qu'est-ce qui t'a surpris ? — L'observation bat l'imagination.
6. **Plus ou moins essentiel dans 3 ans ?** — Filtre les modes passagères.

> Ces questions ne sont pas un interrogatoire — les poser naturellement quand le besoin est flou ou le scope ambitieux. Si l'utilisateur a déjà les réponses, passer directement au découpage.

## Banque de questions par domaine

### App mobile
- "Offline-first ou connecté en permanence ?"
- "Quels OS ? iOS, Android, les deux ?"
- "Notifications push nécessaires ?"
- "Accès hardware ? (caméra, GPS, NFC, biométrie)"

### App web
- "SSR, SPA ou hybride ?"
- "SEO important ?"
- "Quelle charge utilisateur attendue ?"
- "Auth nécessaire ? Quel type ?"

### API / Backend
- "REST, GraphQL ou les deux ?"
- "Quels consommateurs ? (mobile, web, tiers)"
- "Temps réel nécessaire ? (WebSocket, SSE)"
- "Volume de données et patterns d'accès ?"

### CLI / Outil
- "Interactif ou scriptable (piping) ?"
- "Quel OS cible ?"
- "Config file ou tout en args ?"

### Data / ML
- "Volume et fréquence des données ?"
- "Batch ou temps réel ?"
- "Contraintes de latence ?"

## Anti-patterns

- Proposer une solution dès le premier message
- Poser 10 questions d'un coup
- Ignorer les alternatives existantes
- Reformuler de façon robotique ("Vous avez dit que...")
- Passer au code sans validation explicite
- S'activer quand l'utilisateur a déjà un plan clair