# Spec From Brief

> Utiliser quand l'utilisateur fournit un brief flou de fonctionnalité et veut une spec testable et exhaustive. Produit une user story INVEST, un scénario nominal Given/When/Then, des scénarios annexes et la liste des questions business non tranchées.

- Skill: `ludovic33fr/spec-from-brief` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ludovic33fr/spec-from-brief`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ludovic33fr/spec-from-brief/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: Ludovic33Fr (https://skillmd.com/u/ludovic33fr)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ludovic33fr/spec-from-brief

---


# spec-from-brief

## Fiche éditoriale

**Objectif.** Transformer un brief flou en spec testable et exhaustive.

**Entrées.** Brief initial, base documentaire produit.

**Sorties.** User story INVEST, scénario nominal Given/When/Then, scénarios annexes, questions business non tranchées.

**Cadence d'usage.** À chaque nouvelle fonctionnalité spécifiée.

## Mode opératoire

### Quand m'invoquer

L'utilisateur me fournit un brief texte (mail, slack, paragraphe de roadmap) et demande de le transformer en spec, ou évoque un besoin de "passer du brief à la story", ou demande une spec INVEST.

### Procédure

1. Lire le brief en entier sans interpréter.
2. Identifier l'**utilisateur cible** (rôle, contexte d'usage) ; si absent, l'inscrire en question business non tranchée.
3. Identifier le **bénéfice attendu** ; si absent, idem.
4. Reformuler en user story au format `En tant que <rôle>, je veux <action> afin de <bénéfice>`.
5. Tester la story contre INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Pour chaque lettre, dire si elle est tenue ; sinon dire pourquoi.
6. Construire le scénario nominal au format Given/When/Then.
7. Lister les scénarios annexes : cas limites, états système particuliers, erreurs prévisibles. Chacun en Given/When/Then.
8. Lister les **questions business non tranchées** : ambiguïtés du brief, choix de produit qui doivent être arbitrés avant la mise en chantier.
9. Produire la sortie au format ci-dessous.

### Format de sortie

```markdown
# Spec — {titre court de la fonctionnalité}

## User story (INVEST)

> En tant que {rôle}, je veux {action} afin de {bénéfice}.

**Test INVEST**
- Independent : {oui / non — explication}
- Negotiable : {oui / non — explication}
- Valuable : {oui / non — explication}
- Estimable : {oui / non — explication}
- Small : {oui / non — explication}
- Testable : {oui / non — explication}

## Scénario nominal

```
Given {prérequis}
When {action utilisateur}
Then {résultat observable}
```

## Scénarios annexes

### {nom du scénario annexe 1}
```
Given ...
When ...
Then ...
```

### {nom du scénario annexe 2}
...

## Questions business non tranchées

1. {question}
2. {question}
```

### Garde-fous

- Si une information manque dans le brief, **ne pas l'inventer**. Inscrire la question dans la section "Questions business non tranchées".
- Si la user story échoue clairement à un test INVEST (par ex. trop grosse pour être Small), dire explicitement laquelle découper plutôt que produire une fausse spec.
- Ne jamais produire de spec définitive en un coup quand le brief mentionne plusieurs fonctionnalités : proposer un découpage en plusieurs stories et demander quelle traiter en priorité.
- Pas d'estimation d'effort (jours, points). C'est le rôle de l'équipe en refinement.

### Exemple

**Input** :
> "On a besoin que les power users puissent exporter leurs dashboards. C'est urgent, on a perdu deux deals la semaine dernière."

**Output (résumé)** :

```markdown
# Spec — Export de dashboard pour power users

## User story (INVEST)
> En tant qu'utilisateur power, je veux exporter un dashboard afin de le partager hors de la plateforme.

**Test INVEST**
- Independent : oui
- Negotiable : oui
- Valuable : oui (perte de deals confirmée)
- Estimable : non — format d'export pas tranché
- Small : à confirmer selon les formats retenus
- Testable : oui une fois les formats tranchés

## Scénario nominal
```
Given un utilisateur power authentifié sur un dashboard qu'il possède
When il clique sur "Exporter"
Then un fichier est téléchargé localement dans le format choisi
```

## Questions business non tranchées
1. Quels formats d'export ? PDF, PNG, CSV, JSON ?
2. "Power user" est-il un rôle existant ou à créer ?
3. Faut-il auditer les exports (qui a exporté quoi quand) ?
4. Périmètre : un seul dashboard, plusieurs, tous ?
```

---

*Skill de l'Annexe 3 du livre [Le Product Manager Augmenté](../../README.fr.md). Voir [docs/livre.md](../../docs/livre.md) — chapitre 7.*