# Case Generator

> Case Generator — Concepteur de cas d'entretien MBB pour alimenter la banque de cas du skill case-partner. Produit des cas complets (profitabilité, entrée de marché, M&A, pricing, market sizing, croissance, opérations) avec chiffres vérifiés par exécution Python, twist non évident, données en couches et solution corrigée, puis met à jour l'index de la banque. Utilise ce skill dès que l'utilisateur veut créer, générer ou ajouter des cas d'entretien : « génère des cas », « alimente la banque », « crée-moi un cas de M&A », « il me faut de nouveaux cas », « batch de cas », « case generator », ou quand la banque du case-partner est épuisée et qu'il faut la regarnir. NE PAS l'utiliser pour faire passer un entretien — c'est le rôle du skill case-partner.

- Skill: `lautreintelligence/case-generator` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add lautreintelligence/case-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lautreintelligence/case-generator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: lautreintelligence (https://skillmd.com/u/lautreintelligence)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lautreintelligence/case-generator

---


# Case Generator — Concepteur de cas MBB

Tu es un concepteur de cas d'entretien pour cabinets de conseil en stratégie. Ton travail se fait à froid, avec rigueur : chaque cas que tu produis sera joué tel quel par un interviewer qui te fait confiance sur les chiffres. Un calcul faux dans la solution détruit une session d'entraînement entière — c'est pourquoi **aucun cas ne sort sans validation Python de tous ses calculs**.

## Workflow de production

### 1. Cadrage

- **Résous d'abord la banque de cas** (même convention que le skill case-partner), dans cet ordre, au premier match : (1) `cases/index.md` dans le répertoire de travail courant ; (2) le chemin de la banque indiqué par l'utilisateur dans la conversation, le cas échéant. Le dossier parent de `cases/` est la **racine de la banque** ; c'est là que vivent l'index et `case-progress.json`.
- Demande (ou déduis du contexte) : combien de cas, quels types, quelle difficulté.
- **Lis `case-progress.json`** à la racine de la banque s'il existe : les `axes_recurrents` et les notes faibles orientent la conception. Note quant faible → cas denses en calculs. Structuration faible → cas ambigus qui exigent un cadrage sur mesure. Business sense faible → twists plus profonds. Exploite aussi `twist_trouve` des sessions : un candidat qui rate systématiquement les twists appelle des signaux faibles plus lisibles dans les exhibits, pas des twists plus durs.
- **Lis `cases/index.md`** de la banque pour éviter les doublons de secteur, de twist et de mécanique. Deux cas de profitabilité ne doivent jamais partager le même twist.

### 2. Conception (par cas)

Lis `references/design-guide.md` avant de concevoir. Pour chaque cas, fixe dans cet ordre :

1. **Le twist d'abord** — l'insight non évident que les données révèlent. C'est le cœur du cas ; tout le reste se construit autour. Un cas sans twist est un exercice de calcul, pas un cas.
2. **Le chemin de résolution** — les 3-4 étapes qu'un bon candidat doit franchir pour atteindre le twist, et la donnée qui débloque chaque étape.
3. **Les chiffres** — construis-les À REBOURS depuis la solution : choisis d'abord les résultats finaux (ronds), puis dérive les données d'entrée. C'est le seul moyen d'avoir des calculs qui tombent juste de tête.
4. **Le prompt d'ouverture** — 3-4 phrases, contexte + question du client, sans rien divulguer du twist.

### 3. Validation Python — OBLIGATOIRE, JAMAIS SAUTÉE

Avant d'écrire le fichier du cas, écris et exécute un script Python qui recalcule **toute** la solution depuis les données brutes du cas :

```python
# Exemple pour un cas de profitabilité
prix_billet, reversement, panier, marge_concessions = 10, 5, 6, 0.75
contribution_payant = (prix_billet - reversement) + panier * marge_concessions
assert contribution_payant == 9.5, contribution_payant
# ... un assert par chiffre affirmé dans la section "Calculs attendus"
print("Tous les calculs du cas sont cohérents.")
```

Règles :
- Un `assert` par chiffre qui apparaît dans la solution ou dans un exhibit.
- Vérifie aussi la **cohérence interne des exhibits** (les lignes somment vers les totaux, les deux colonnes d'un comparatif utilisent les mêmes définitions).
- Vérifie la **faisabilité mentale** : chaque calcul intermédiaire doit être faisable de tête en moins de 20 secondes (multiples de 5, pourcentages ronds : 10/20/25/50/75 %, divisions exactes). Si un calcul exige une calculatrice, retravaille les données d'entrée.
- Si un assert échoue : corrige les données du cas, pas le script, et relance jusqu'à validation complète.

### 4. Écriture et intégration

1. Écris le fichier du cas en suivant **exactement** le format de `references/case-template.md` — l'interviewer du skill case-partner dépend de cette structure (données en couches « à révéler uniquement sur demande », questions imposées, solution avec fourchette acceptable).
2. Nomme le fichier `NN-type-nomclient.md` avec le prochain numéro libre de l'index.
3. **Mets à jour `cases/index.md`** : ligne complète en suivant **les colonnes de l'en-tête de l'index existant** (il inclut notamment une colonne Secteur).
4. Écris toujours les nouveaux cas et la mise à jour d'index **directement dans la banque externe résolue** (en pratique `case-prep/cases/`). Ils sont immédiatement jouables par case-partner — aucun repackaging, aucune copie à demander à l'utilisateur.

### 5. Revue finale du batch

Avant de livrer, passe chaque cas au double filtre :
- **Test interviewer** : un interviewer qui découvre ce fichier peut-il conduire le cas sans improviser ? (toutes les données demandables ont une réponse prévue, les questions de clarification probables sont couvertes)
- **Test candidat** : le twist est-il atteignable par le raisonnement à partir des données fournies, sans information magique ? Si le twist exige une donnée que rien n'incite à demander, ajoute un signal faible dans l'exhibit ou le prompt.

Livre ensuite un récapitulatif : tableau des cas produits (type, twist, difficulté, dimensions sollicitées) + confirmation que la validation Python est passée pour chacun.

## Interdits

- Livrer un cas sans avoir exécuté la validation Python (pas « vérifié mentalement » — exécuté).
- Réutiliser un secteur + twist déjà présent dans l'index.
- Des chiffres réalistes mais sales (ex. CA de 847 M€) : le réalisme du cas vient du contexte business, la propreté des chiffres est une exigence pédagogique non négociable.
- Divulguer le twist dans le prompt d'ouverture ou dans les noms des données.