Claude Code / Codex
Prompts d'instructions et collection de modèles

Lis le fichier d'instructions que toi (cet agent) charges (CLAUDE.md / AGENTS.md, etc.),
pointe les points faibles que les agents IA ont tendance à ignorer, puis réécris-le
sous une forme efficace.

Points à examiner :
- Transformer les formulations vagues en impératifs (toujours faire X / ne jamais faire Y)
- Ajouter une « définition de terminé » et des étapes de vérification (exécution de lint / test)
- Rendre les interdictions concrètes jusqu'à la cible (noms de répertoires, noms de commandes)
- Si c'est trop long, le réduire au seul noyau que tu veux faire appliquer

Liste d'abord les points faibles sous forme de puces, puis produis la version
réécrite complète et applique-la à ce fichier d'instructions.

Après avoir identifié les vraies commandes build / test / lint de ce dépôt,
ajoute une section « Définition de terminé » au fichier d'instructions que tu charges
(CLAUDE.md / AGENTS.md, etc.).

Exigences :
- En faire une liste de contrôle sous la forme « ne pas signaler terminé tant que tout ce qui suit n'est pas satisfait »
- Indiquer explicitement les vraies commandes de lint et de test
- Inclure : ne laisser aucun TODO ni log de débogage dans les fichiers modifiés, et relire ton propre diff

Ne casse pas le contenu existant ; ajoute uniquement la section.

Détecte automatiquement le langage et le framework de ce dépôt, et ajoute les
règles de bonnes pratiques correspondantes au fichier d'instructions que tu charges
(CLAUDE.md / AGENTS.md, etc.).

Exemples :
- Next.js : frontière Server/Client (par défaut Server, garder use client au minimum)
- Laravel : validation via les Form Requests, conventions de migration
- Python : annotations de type, ne jamais écraser ni fabriquer les données brutes

Ajoute une note d'une ligne sur la base de ta détection (à partir de quels fichiers tu as jugé)
avant d'ajouter. Ne duplique rien de ce qui est déjà écrit.

Ajoute les « règles absolues » suivantes au fichier d'instructions que tu charges
(CLAUDE.md / AGENTS.md, etc.), adaptées à la configuration de ce dépôt.

- Ne jamais committer de secrets, de .env ou d'identifiants
- Ne jamais push / force-push sauf instruction explicite
- Valider les entrées à la frontière / ne jamais assouplir de toi-même l'authentification ou l'autorisation
- Ne jamais exécuter de commandes destructrices (DROP / TRUNCATE / migrate:fresh, etc.) sur la base de production
- Chaque fois que tu changes le comportement, toujours ajouter ou mettre à jour les tests

Si des règles similaires existent déjà, ne les duplique pas ; comble seulement ce qui manque.

Convertis le contenu de ce `CLAUDE.md` au format `AGENTS.md` pour
OpenAI Codex et écris-le.

- Conserve le sens, mais remets-le en forme dans une structure facile à lire
  pour Codex (titres, puces)
- Conserve telles quelles les commandes, les règles absolues et la définition de terminé
- Produis-le sous le nom `AGENTS.md` à la racine

Convertis le contenu de ce `CLAUDE.md` au format Project Rules de Cursor
(fichiers `.mdc` sous `.cursor/rules/`).

- Découpe les règles en unités significatives
- Sépare les règles qui doivent toujours s'appliquer de celles qui ne s'appliquent
  qu'à des types de fichiers spécifiques
- Définis les conditions d'application appropriées (globs, etc.) en tête de chaque fichier

Inspecte la structure de ce monorepo et crée les fichiers d'instructions que toi
(cet agent) charges (Claude Code utilise CLAUDE.md, Codex utilise AGENTS.md, etc.),
découpés comme suit.

- À la racine : les règles communes à tout le dépôt
  (conventions de commit, protection des secrets, la définition de terminé globale)
- Dans chaque répertoire de paquet/application : seulement les règles et les commandes spécifiques à cette stack

Évite la duplication, et ajoute dans chaque paquet une note d'une ligne disant « suivre les
règles communes à la racine ». À la fin, rends compte sous forme de liste de ce que tu as placé dans quel répertoire.

# Projet : <name>

## Qu'est-ce que c'est
Une présentation de l'application en un paragraphe. Ce qu'elle fait, qui l'utilise, et la
stack technique (langage, framework, BDD, runtime).

## Commandes
- Serveur de dev : `npm run dev`
- Build :          `npm run build`
- Test :           `npm test`
- Lint :           `npm run lint`

## Conventions
- Le langage est TypeScript (strict). Ne pas utiliser `any`.
- Respecter le style du fichier en cours d'édition. Toujours passer le Lint avant de terminer.
- Garder les changements minimes ; ne pas toucher aux lignes sans rapport (pas de reformatage sans rapport).

## Règles absolues (strictement appliquées)
- Avant de signaler terminé, toujours exécuter les tests et le Lint ci-dessus et les faire passer.
- Ne jamais, au grand jamais, committer de secrets, de .env ou d'artefacts de build.
- Préférer la modification de fichiers existants à la création de nouveaux.
- Quand les exigences sont vagues, poser exactement une question de clarification avant un changement important.

## Hors limites (sauf instruction contraire)
- Configuration CI, versions des dépendances, configuration de l'infrastructure.

# <name>

- Stack : <ex. Next.js + TypeScript + PostgreSQL>
- Toujours exécuter avant de terminer : `npm run lint` et `npm test` (les deux doivent passer)
- Respecter le style existant. Ne pas reformater les lignes sans rapport.
- Ne pas committer de secrets ni de .env. Ne pas push avant d'en recevoir l'instruction.
- En cas d'imprécision, ne pas deviner ; poser exactement une question.

# Next.js (App Router) + TypeScript

## Stack
Next.js (App Router), TypeScript strict, Tailwind CSS, <your-ORM>

## Commandes
- Dev :   `npm run dev`
- Build : `npm run build`   # doit passer sans erreur de type
- Lint :  `npm run lint`
- Test :  `npm test`

## Règles d'architecture
- Par défaut, des Server Components. N'ajouter "use client" que lorsque l'état, les effets ou
  les API du navigateur sont nécessaires. Garder les Client Components petits et aux feuilles.
- Récupérer les données dans les Server Components ou les Route Handlers.
  Ne pas récupérer les données initiales dans useEffect.
- Co-localiser les composants avec leur segment de route. L'UI partagée va dans `components/`.
- Toujours valider par schéma les entrées externes à la frontière (ex. Zod).

## Conventions
- Pas de `any`. Donner des types de retour explicites aux fonctions publiques.
- Utiliser les design tokens / classes Tailwind existants. Ne pas ajouter de couleurs de toi-même.
- Garder `page.tsx` mince ; pousser la logique dans des fonctions et des composants.

## Définition de terminé
`npm run build`, `npm run lint` et `npm test` passent tous avec le code de sortie 0.
Pas de `any`, pas d'exports inutilisés, aucun console.log oublié.

# React (Vite) + TypeScript

## Commandes
- Dev :   `npm run dev`
- Build : `npm run build`
- Lint :  `npm run lint`
- Test :  `npm test` (Vitest + Testing Library)

## Règles
- Composants fonctionnels et Hooks uniquement. Ne pas utiliser de composants de classe.
- Garder l'état au minimum, dans l'ordre « local -> Context -> bibliothèque d'état ».
  Ne pas remonter l'état au niveau global inutilement.
- Confiner les effets de bord à useEffect, et écrire correctement le tableau de dépendances.
- Séparer l'UI de la logique. Regrouper la récupération des données dans des hooks dédiés (useXxx).
- Accessibilité : donner aux éléments interactifs des rôles et un fonctionnement clavier appropriés.

## Conventions
- Pas de `any`. Définir les props avec des types.
- Respecter le style des composants et styles existants.

## Définition de terminé
`npm run build`, `npm run lint` et `npm test` passent avec le code de sortie 0.

# API Node.js (Express / Hono) + TypeScript

## Commandes
- Dev :   `npm run dev`
- Build : `npm run build`
- Test :  `npm test`
- Lint :  `npm run lint`

## Règles
- Valider par schéma toutes les entrées (body, query, params, headers) à la frontière.
- Ne pas avaler les erreurs. Les renvoyer typées via un gestionnaire d'erreurs central.
- Lire les secrets depuis les variables d'environnement. Ne pas les coder en dur dans le code.
- Stratifier l'accès à la BDD (route -> service -> repository).
- Renvoyer une forme JSON cohérente (unifier la forme du succès et de l'échec).

## Règles absolues
- Ne pas contourner ni assouplir de toi-même la logique d'authentification / autorisation.
- Toujours vérifier l'autorisation en ajoutant un endpoint exposé publiquement.
- Ne pas logger d'informations personnelles, de jetons ni de mots de passe.

## Définition de terminé
`npm test` (cas nominal + cas d'erreur) et `npm run lint` passent.

# Laravel + PHP

## Commandes
- Serveur : `php artisan serve`
- Migrer :  `php artisan migrate`
- Test :    `php artisan test`
- Format :  `./vendor/bin/pint`   # exécuter avant de terminer

## Conventions (suivre la manière Laravel)
- Utiliser les relations Eloquent. Éviter le SQL brut sans raison claire.
- Valider les entrées dans des classes Form Request. Ne pas le faire dans les contrôleurs.
- Garder les contrôleurs minces. Pousser la logique métier vers des Services / Actions.
- Chaque changement de schéma reçoit une nouvelle migration. Ne pas éditer celles déjà exécutées.
- Utiliser les routes nommées et le route model binding.

## Règles absolues
- Ne jamais, au grand jamais, committer `.env` ou de vrais identifiants.
- Ne pas exécuter de commandes destructrices comme `migrate:fresh` sur la base de production.
- Chaque fois que tu changes le comportement, toujours ajouter ou mettre à jour les tests (`php artisan test`).

## Définition de terminé
`php artisan test` et `./vendor/bin/pint --test` passent tous les deux.

# Python / analyse de données

## Environnement
- Utiliser le venv du projet `.venv`. Ne pas installer globalement.
- Installation : `pip install -r requirements.txt`
- Exécution : `python -m src.main`
- Test : `pytest`
- Format : `ruff check .` et `ruff format .`

## Conventions
- Ajouter des annotations de type à chaque signature de fonction. Exécuter `mypy src` si configuré.
- Ne pas mettre de logique dans les notebooks. Le code réutilisable va dans `src/`.
- Fixer la graine (seed) pour tout ce qui utilise de l'aléatoire, afin que les résultats soient reproductibles.

## Règles absolues sur les données (les plus importantes)
- Ne pas combler ni fabriquer silencieusement les valeurs manquantes. S'il y a des valeurs
  manquantes, les signaler et confirmer comment les traiter.
- Ne pas écraser les fichiers de données brutes. Écrire la sortie dans `data/processed/`.
- Documenter toutes les hypothèses (filtres, lignes exclues, unités) dans les commentaires du code.

## Définition de terminé
`pytest` passe, `ruff check .` est propre, et les résultats se reproduisent depuis un état propre.

# Go

## Commandes
- Build :  `go build ./...`
- Test :   `go test ./...`
- Format : `gofmt -w .` et `go vet ./...`

## Conventions
- Ne pas avaler les erreurs. Toujours les gérer avec `if err != nil`, et les renvoyer
  avec du contexte (`fmt.Errorf("...: %w", err)`).
- Garder l'imbrication peu profonde grâce aux retours anticipés.
- N'utiliser la concurrence que lorsque c'est nécessaire. Surveiller les fuites de goroutine et les races
  (faire passer `go test -race`).
- Commenter les symboles exportés. Préférer la bibliothèque standard.

## Règles absolues
- Ne pas ajouter d'abstractions ou d'interfaces inutiles (les créer quand le besoin survient).
- Avant d'ajouter une dépendance, vérifier d'abord si la bibliothèque standard suffit.

## Définition de terminé
`go build ./...`, `go vet ./...` et `go test -race ./...` passent tous.

# Rust

## Commandes
- Build :  `cargo build`
- Test :   `cargo test`
- Lint :   `cargo clippy -- -D warnings`
- Format : `cargo fmt`

## Conventions
- Ne pas utiliser à la légère `unwrap()` / `expect()` dans le code de production.
  Gérer `Result` / `Option` correctement avec `?` ou match.
- `unsafe` est interdit par principe. Si c'est vraiment nécessaire, en indiquer la raison dans un commentaire.
- Suivre le compilateur sur l'emprunt et les durées de vie. Repenser la conception avant
  de s'échapper avec `clone()`.
- Rendre les types d'erreur significatifs avec `thiserror` / `anyhow`, etc.

## Définition de terminé
`cargo build` et `cargo test` passent, et
`cargo clippy -- -D warnings` ne signale aucun avertissement.

# Ruby on Rails

## Commandes
- Serveur : `bin/rails server`
- Migrer :  `bin/rails db:migrate`
- Test :    `bin/rails test` (ou `bundle exec rspec`)
- Format :  `bundle exec rubocop -A`

## Conventions (suivre la manière Rails)
- Respecter « la convention plutôt que la configuration » ; ne pas inventer sa propre structure.
- Éviter les contrôleurs / modèles surchargés. Pousser la logique dans des Services / Concerns.
- Restreindre les entrées avec les strong parameters.
- Éviter les N+1 (utiliser `includes`).
- Les changements de schéma reçoivent une nouvelle migration. Ne pas éditer celles déjà exécutées.

## Règles absolues
- Ne jamais, au grand jamais, committer `.env` ou des identifiants.
- Ne pas exécuter de commandes destructrices sur la base de production.
- Quand tu changes le comportement, ajouter ou mettre à jour les tests.

## Définition de terminé
Les tests et `bundle exec rubocop` passent.

# SQL / migrations de base de données

## Règles absolues (la protection des données passe en premier)
- Ne pas exécuter de toi-même d'opérations destructrices sur les données de production
  (DROP / TRUNCATE / DELETE ou UPDATE sans condition).
- Les migrations doivent fournir une procédure de rollback, pas seulement le sens avant.
- Ne pas éditer les migrations déjà exécutées. Toujours en ajouter de nouvelles.
- Supprimer ou renommer les colonnes par étapes (« ajouter -> migrer -> retirer ») ; ne pas le faire d'un seul coup.

## Conventions de requête
- Éviter `SELECT *` ; spécifier les colonnes nécessaires.
- Vérifier que les conditions WHERE / JOIN peuvent utiliser un index.
- Découper les grosses mises à jour en lots pour garder le temps de verrou court.
- Pour les requêtes de vérification destructrices, confirmer d'abord le nombre de lignes concernées avec un `SELECT` avant d'exécuter.

## Définition de terminé
L'application et le rollback réussissent tous deux dans un environnement équivalent à la
préproduction, et tu as confirmé l'absence de changements non voulus sur les données existantes.

# Approche pilotée par les tests

En changeant le comportement, suivre cette boucle à chaque fois :
1. Écrire d'abord un « test qui échoue » exprimant le comportement souhaité.
2. Exécuter le test et confirmer qu'il échoue pour la bonne raison.
3. Écrire le minimum de code nécessaire pour faire passer le test.
4. Exécuter toute la suite de tests et confirmer que tout est vert.
5. Refactoriser en restant au vert.

## Règles absolues
- Ne pas supprimer ni ignorer des tests pour faire passer la suite.
- Ne pas affaiblir les assertions pour passer au vert.
- Si un test est vraiment faux, expliquer pourquoi avant de le modifier.
- Du code nouveau sans tests n'est pas « terminé ».

## Définition de terminé
Toute la suite passe, la couverture n'a pas baissé, et revenir en arrière sur
l'implémentation fait échouer le nouveau test (c'est-à-dire que c'est un test significatif).

# Approche de débogage

Procéder dans cet ordre. Ne pas corriger en devinant :
1. Établir les étapes de reproduction (comment déclencher le bug).
2. Écrire le comportement attendu et le comportement réel, une phrase chacun.
3. Formuler une hypothèse. La vérifier avec des logs ou une repro minimale avant de corriger.
4. Une fois la cause identifiée, appliquer la correction minimale.
5. Après correction, confirmer que le bug a disparu via les étapes de repro et que les tests existants passent.
6. Si possible, ajouter un test de régression qui capture ce bug.

## Règles absolues
- Ne pas changer plusieurs endroits à la fois tant que la cause est inconnue.
- Ne pas s'arrêter à « ça marche pour l'instant ». Expliquer pourquoi c'est corrigé.
- Ne pas mêler de refactorisation sans rapport au débogage.

# Approche de refactorisation

## Principe fondamental
Ne pas changer le comportement observable de l'extérieur. Ne pas changer les sorties ni les
effets de bord pour aucune entrée.

## Étapes
1. Confirmer d'abord que des tests existent pour la zone visée et qu'ils sont verts.
   Sinon, écrire d'abord des tests de caractérisation qui fixent le comportement actuel.
2. Changer par petites étapes uniques, en exécutant les tests après chaque étape.
3. Garder un commit = un type d'amélioration.

## Règles absolues
- Ne pas mêler ajouts de fonctionnalités ou corrections de bugs à la refactorisation (en faire un travail séparé).
- Si un test passe au rouge, s'arrêter sur-le-champ. Ne pas continuer.
- Ne pas changer de toi-même les signatures d'API publiques (confirmer d'abord si nécessaire).

## Définition de terminé
Tous les tests restent verts, et le code est plus lisible avec moins de duplication.

# Comment rédiger un document de conception

Avant d'implémenter, rédige d'abord ce qui suit en prose (ne pas écrire de code) :

## 1. Objectif
Le problème à résoudre, et les conditions permettant de le considérer atteint (critères de réussite).

## 2. État actuel et contraintes
La configuration existante, les dépendances et les contraintes à respecter (performance, compatibilité, échéance).

## 3. Proposition de conception
- L'approche choisie, et les approches envisagées puis rejetées (et pourquoi).
- Le flux de données, les interfaces clés et les fichiers à modifier.

## 4. Risques et questions ouvertes
Ce qui pourrait casser, les hypothèses à confirmer et les points nécessitant une décision.

## 5. Plan
Découper l'implémentation en petites étapes, ordonnées en unités vérifiables.

## Règles
- Ne pas commencer à implémenter tant que cette conception n'est pas approuvée.
- Lister les inconnues sous « questions ouvertes » ; ne pas les combler par tes propres hypothèses.

# Comment réaliser des changements importants

## Principe fondamental
Éviter un changement géant. Le découper pour que chaque étape soit indépendamment revisible,
testable et (idéalement) déployable.

## Étapes
1. Décomposer les changements menant à la forme finale en une séquence de petites étapes
   indépendantes, et la présenter.
2. Pour chaque étape, écrire « quoi / pourquoi / portée de l'impact » en 1-2 lignes.
3. Après chaque étape, exécuter toute la suite de tests et confirmer le vert avant de continuer.
4. Avancer en préservant la rétrocompatibilité (ajouter -> migrer -> retirer l'ancien chemin).

## Règles absolues
- Ne pas réécrire une large zone en une fois et « tout tester ensemble plus tard ».
- Si une étape devient trop importante, la découper davantage.
- Garder chaque étape à une granularité réversible.

## Définition de terminé
Les tests sont verts une fois toutes les étapes terminées, et chaque commit intermédiaire n'est pas cassé non plus.

# Instructions de revue de code

Passe en revue les changements, regroupe-les par gravité, et rends compte dans cet ordre :
1. CRITICAL - failles de sécurité, perte de données, plantages, authentification cassée
2. HIGH     - bugs de logique, conditions de course, gestion d'erreurs manquante
3. MEDIUM   - problèmes de performance, tests manquants, nommage déroutant
4. LOW      - remarques de style mineures (seulement s'il n'y a aucun problème de niveau supérieur)

## Comment rendre compte
- Pour chaque constat : fichier:ligne / ce qui ne va pas / pourquoi c'est important / une correction concrète.
- Ne citer que le plus petit extrait pertinent. Ne pas coller le fichier entier.
- Si un changement est correct, le dire explicitement. Ne pas fabriquer de problèmes.

## Choses à ne pas faire
- Ne pas enterrer de vrais bugs sous une pile de remarques LOW.
- Ne pas réécrire des fichiers entiers. Proposer le plus petit diff.
- Sauf préjudice réel, ne pas signaler de lignes hors de la portée du diff.

## Sortie
Terminer par un verdict en une ligne : APPROVE / REQUEST CHANGES / BLOCK, avec une raison.

# Règles Git / PR

## Commits
- Utiliser Conventional Commits : `type(scope): résumé`
  type : feat, fix, refactor, test, docs, chore.
- Un commit = un changement logique. Le garder petit et revisible.
- Dans le corps, écrire le « pourquoi » plutôt que le « quoi ».

## Règles absolues
- Ne pas faire `git push` sauf instruction explicite.
- Ne pas force-push, rebase ni amend sur les branches partagées / main.
- Ne pas committer de secrets, de .env, d'identifiants ni de gros binaires.
- Ajouter les fichiers par nom. Ne pas tout balayer avec `git add -A`.

## Pull requests
- Titre en 70 caractères maximum. Le corps est « Résumé » + « Plan de test (liste de contrôle) ».
- Signaler tout changement cassant.
- Ne pas merger. Créer la PR et rendre compte de l'URL.

# Instructions de revue de sécurité

Vérifie les changements dans l'ordre selon les angles suivants, et rends compte de tout
problème trouvé avec une note de gravité :
- Validation des entrées manquante (injection : SQL / commande / XSS / SSRF)
- Lacunes d'authentification/autorisation (vérifications de permission manquantes, élévation de privilèges)
- Exposition de secrets (clés/jetons codés en dur, sortie dans les logs)
- Réglages par défaut non sûrs (exposition excessive, CORS laxiste, redirections non validées)
- Vulnérabilités connues dans les dépendances, usage de crypto / RNG non sûr

## Comment rendre compte
- Pour chaque constat : emplacement / scénario d'attaque (comment cela pourrait être exploité) / une correction concrète.
- Signaler les soupçons dont tu n'es pas certain comme « à confirmer » (ne pas les ignorer silencieusement).
- S'il n'y a pas de problème, indiquer « aucun problème » ainsi que les angles que tu as vérifiés.

## Choses à ne pas faire
- Ne pas générer de code d'attaque réel ni d'étapes d'exploitation (montrer uniquement les corrections).

# Règles de travail Docker / infrastructure

## Règles absolues (prévenir la destruction passe en premier)
- Ne pas exécuter de toi-même de commandes destructrices sur les environnements de production ou partagés
  (`docker system prune`, suppression de volumes, `down -v`, etc.).
- Épingler les images à des tags fixes. Ne pas dépendre de `latest`.
- Passer les secrets via les variables d'environnement / la gestion des secrets.
  Ne pas les graver dans le Dockerfile ou l'image.
- Garder les ports exposés et les privilèges (privileged, etc.) au minimum nécessaire.

## Conventions
- Garder les Dockerfiles petits avec des builds multi-étapes, en tenant compte du cache de couches.
- Tourner en utilisateur non-root.
- Après modifications, builder et démarrer en local pour vérifier avant de rendre compte.

## Définition de terminé
`docker build` passe, le conteneur démarre, et le health check / le fonctionnement de base
peut être confirmé.

# Règles sur les dépendances

## Règles absolues
- Avant d'ajouter une dépendance, vérifier si la bibliothèque standard ou une dépendance
  existante suffit.
- En ajoutant une nouvelle dépendance, ajouter une note d'une ligne sur son but, ses alternatives
  et son état de maintenance.
- Ne pas monter de versions majeures de toi-même (seulement sur instruction).
- Ne pas régénérer les fichiers de verrouillage (package-lock.json, etc.) de toi-même.
- Éviter les paquets d'origine douteuse ou avec extrêmement peu d'étoiles ou une mauvaise maintenance.

## Étapes
1. Indiquer la raison de l'ajout ou de la mise à jour.
2. Après l'ajout, confirmer que le build et les tests passent.
3. Confirmer que la licence n'entre pas en conflit avec ton cas d'usage.

## Définition de terminé
Le build et les tests passent après le changement de dépendance, et tu peux expliquer le diff dans le fichier de verrouillage.