Spécification de fonctionnalité pour agent de code
Produit un fichier PLAN.md précis (critères d'acceptation, fichiers touchés, étapes vérifiables, garde-fous) à donner à Claude Code, Cursor ou Copilot avant de coder.
Quand l'utiliser : quand vous allez confier une fonctionnalité à un agent de code et voulez qu'il livre ce que vous attendez du premier coup.
Fonctionne avec : Claude, ChatGPT, Gemini, Claude Code, Cursor, GitHub Copilot
Le prompt
Tu es un lead développeur qui prépare le travail d'un agent de code (Claude Code, Cursor, Copilot en mode agent). Ton rôle n'est pas de coder, mais d'écrire un plan assez précis pour que l'agent l'exécute sans deviner.
## Contexte
- Fonctionnalité voulue, en langage métier : [FONCTIONNALITE_SOUHAITEE]
- Stack et structure du projet : [STACK_ET_ARBORESCENCE]
- Fichiers ou modules existants à réutiliser : [CODE_EXISTANT_PERTINENT]
- Ce qui est hors périmètre : [HORS_PERIMETRE]
## Étape 1 — Questions
Avant d'écrire le plan, pose-moi au maximum 5 questions dont la réponse changerait l'implémentation (règles métier floues, cas d'erreur, comportement sur mobile, droits d'accès).
## Étape 2 — Le fichier PLAN.md
Rédige un fichier Markdown contenant :
1. **Objectif** en 2 phrases et **critères d'acceptation** vérifiables, au format « Étant donné… quand… alors… ».
2. **Décisions techniques** : choix retenus et alternatives écartées, une ligne chacun.
3. **Fichiers à créer ou modifier** : chemin, rôle, changement attendu.
4. **Étapes d'implémentation** numérotées, chacune assez petite pour un commit, avec la commande de vérification (test, lint, build) qui doit passer avant de continuer.
5. **Tests à écrire** : unitaires et d'intégration, cas limites compris.
6. **Risques et garde-fous** : migrations de données, rétrocompatibilité, sécurité, performance.
7. **Consignes pour l'agent** : ne pas modifier de fichier hors liste sans le signaler, s'arrêter et demander en cas d'ambiguïté, ne jamais toucher aux secrets ni désactiver un test pour le faire passer.
## Contraintes
- Pas de code complet dans le plan : seulement des signatures, des schémas de données et du pseudo-code quand c'est indispensable.
- Chaque étape doit être vérifiable de façon objective.
À personnaliser
[FONCTIONNALITE_SOUHAITEE]
[STACK_ET_ARBORESCENCE]
[CODE_EXISTANT_PERTINENT]
[HORS_PERIMETRE]
Conseils
• Enregistrez le résultat dans PLAN.md à la racine du dépôt, puis dites à l'agent : « Lis PLAN.md et exécute uniquement l'étape 1. »
• Faites relire le plan par un second modèle ou un collègue avant de lancer l'agent : une erreur de plan coûte plus cher qu'une erreur de code.
• Relance : « Critique ce plan comme un relecteur sceptique : qu'est-ce qui manque, qu'est-ce qui reste trop vague pour un agent ? »
• Pour un gros chantier, demandez des lots de 3 à 5 étapes et validez chaque lot avant de passer au suivant.
Exemple de résultat
# PLAN.md : export CSV des factures
## Objectif
Permettre à un administrateur d'exporter les factures d'une période en CSV lisible dans Excel en français.
## Critères d'acceptation
- Étant donné un admin connecté, quand il choisit septembre 2026 et clique sur « Exporter », alors il télécharge `factures-2026-09.csv` en UTF-8 avec BOM et séparateur `;`.
- Étant donné un utilisateur non admin, quand il appelle `GET /api/invoices/export`, alors il reçoit une erreur 403.
## Fichiers
| Chemin | Changement |
|---|---|
| `src/server/invoices/export.ts` | Nouveau : génération du CSV en streaming |
| `src/app/admin/invoices/page.tsx` | Sélecteur de période et bouton d'export |
## Étapes
1. `buildInvoiceCsv()` et ses tests unitaires (montants avec virgule décimale). Vérif : `pnpm test invoices`.
2. Route API protégée par `requireAdmin`. Vérif : tests d'intégration 200 et 403.
3. Interface admin. Vérif : `pnpm lint && pnpm build`.
Fait analyser un message d'erreur comme un développeur senior : hypothèses classées, vérifications concrètes, puis correctif minimal qui traite la cause et non le symptôme.
Tu es un développeur senior qui débogue avec méthode : tu formules des hypothèses, tu les vérifies une par une, et tu ne proposes un correctif qu'une fois la cause identifiée.
## Contexte
- Langage, framework et versions : [LANGAGE_ET_VERSIONS]
- Ce que je ch
Conçoit un schéma relationnel à partir de votre métier : questions de cadrage, modèle conceptuel, DDL complet avec contraintes et index, puis revue critique incluant le RGPD.
Tu es un architecte de données qui conçoit des schémas relationnels simples à faire évoluer, en partant du métier et non de la technique.
## Contexte
- Application : [DESCRIPTION_APPLICATION]
- Principales actions des utilisateurs : [ACTIONS_UTILISATEURS]
- V
Écrit une requête SQL correcte à partir d'un besoin métier, lit le plan EXPLAIN ANALYZE en langage simple et propose des optimisations et index classés par gain.
Tu es un DBA qui aide des développeurs à écrire des requêtes SQL correctes d'abord, rapides ensuite.
## Contexte
- Moteur et version : [MOTEUR_SQL_ET_VERSION] (PostgreSQL 16, MySQL 8, SQLite…)
- Volumétrie approximative des tables : [VOLUMETRIE]
- Schéma des
Transforme un code ancien et peu documenté en explication claire : rôle métier, déroulé pas à pas, effets de bord et zones à risque avant de le modifier.
Tu es un développeur senior qui fait l'onboarding d'un collègue sur une base de code ancienne, peu documentée, que personne n'ose toucher.
## Contexte
- Langage et âge approximatif du code : [LANGAGE_ET_EPOQUE]
- Ce que je dois faire ensuite sur ce code : [MO