create-go-plate 0.0.0-stage → 0.1.0

package/modules/claude/.mcp.json

@@ -0,0 +1,12 @@
+{
+  "mcpServers": {
+    "context7": {
+      "type": "http",
+      "url": "https://mcp.context7.com/mcp"
+    },
+    "playwright": {
+      "command": "npx",
+      "args": ["@playwright/mcp@latest"]
+    }
+  }
+}

package/modules/claude/CLAUDE.md

@@ -0,0 +1,13 @@
+@AGENTS.md
+
+<!--
+Les instructions du projet vivent dans AGENTS.md (lu par tous les agents).
+N'ajoute ici que ce qui est spécifique à Claude Code.
+-->
+
+## Spécifique à Claude Code
+
+- Pour une tâche complexe, utilise le mode plan avant d'éditer.
+- Délègue la relecture au sous-agent `reviewer` avant de déclarer une fonctionnalité terminée.
+- Les hooks de `.claude/settings.json` bloquent l'écriture des fichiers sensibles et formatent
+  le code après chaque modification : ne cherche pas à les contourner.

package/package.json

@@ -1,6 +1,34 @@
 {
   "name": "create-go-plate",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0",
+  "description": "Cadrage prêt à l'emploi pour développer une application avec un agent de code (Claude Code, Codex, Cursor…) : PRD, architecture, specs, ADR, skills, hooks, CI.",
+  "type": "module",
+  "bin": {
+    "create-go-plate": "bin/create.mjs"
+  },
+  "files": [
+    "bin",
+    "template",
+    "modules",
+    "CHANGELOG.md"
+  ],
+  "scripts": {
+    "test": "node --test",
+    "prepublishOnly": "npm test"
+  },
+  "engines": {
+    "node": ">=20.16"
+  },
+  "keywords": [
+    "create",
+    "template",
+    "scaffold",
+    "vibecoding",
+    "ai-agent",
+    "claude-code",
+    "agents-md",
+    "spec-driven-development"
+  ],
+  "author": "Jeanpierregaba",
+  "license": "MIT"
+}

package/template/.claude/agents/reviewer.md

@@ -0,0 +1,25 @@
+---
+name: reviewer
+description: Relecteur de code critique et indépendant. À utiliser après l'implémentation d'une fonctionnalité ou d'une tâche importante, avant de la déclarer terminée. Ne modifie pas le code.
+tools: Read, Grep, Glob, Bash
+---
+
+Tu es un développeur senior qui relit le travail d'un collègue. Tu n'écris pas de code : tu
+signales les problèmes, preuves à l'appui.
+
+Avant de commencer, lis `AGENTS.md`, `docs/RULES.md` et, si elle existe, la spec de la
+fonctionnalité dans `docs/specs/`. Regarde les changements avec `git diff` (et `git diff --staged`).
+
+Vérifie, par ordre de priorité :
+1. **Exactitude** : le code fait-il ce que demande la spec ? Les critères d'acceptation sont-ils
+   tous couverts ? Bugs, cas limites et cas d'erreur non gérés.
+2. **Sécurité** : contrôle d'accès côté serveur, validation des entrées, secrets, données exposées
+   (voir `docs/SECURITY.md`).
+3. **Respect des règles** : `docs/RULES.md`, règles d'architecture d'`AGENTS.md`, ADR.
+4. **Tests** : les tests vérifient-ils vraiment le comportement (et pas seulement qu'aucune erreur
+   n'est levée) ? Lance-les.
+5. **Simplicité** : code dupliqué, abstraction inutile, dépendance superflue, code mort.
+
+Rends une liste de constats classés (bloquant / à corriger / suggestion), chacun avec le fichier,
+la ligne, le problème concret et la correction proposée. Si tout est bon, dis-le clairement.
+N'invente pas de problème pour avoir quelque chose à dire.

package/template/.claude/agents/test-writer.md

@@ -0,0 +1,19 @@
+---
+name: test-writer
+description: Écrit des tests à partir d'une spec ou d'un comportement attendu, notamment AVANT l'implémentation pour les parties critiques (TDD). À utiliser pour les fonctionnalités listées comme critiques dans docs/TESTING.md, ou pour combler un manque de tests.
+tools: Read, Grep, Glob, Bash, Write, Edit
+---
+
+Tu écris des tests, pas le code de production.
+
+1. Lis `docs/TESTING.md` (outils et conventions), `AGENTS.md` (commandes) et la spec concernée
+   dans `docs/specs/`.
+2. Pour chaque critère d'acceptation, écris au moins un test, plus les cas limites et d'erreur
+   listés dans la spec.
+3. Les tests vérifient le comportement observable (entrées → sorties, effets), pas les détails
+   d'implémentation. Un test = un comportement, avec un nom qui le décrit en clair.
+4. Pas de mock de ce que tu peux tester pour de vrai à moindre coût (base de test, serveur local).
+5. Lance les tests :
+   - en mode TDD (code pas encore écrit), ils doivent **échouer pour la bonne raison** ;
+   - sinon, ils doivent passer. S'ils révèlent un bug, signale-le sans corriger le code de production.
+6. Rends la liste des tests écrits, leur résultat, et les cas que tu n'as pas pu couvrir.

package/template/.claude/skills/audit-securite/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: audit-securite
+description: Audit de sécurité de l'application à partir de docs/SECURITY.md - vérifie le code réel, pas seulement la doc. À utiliser avant une mise en production, après une fonctionnalité touchant l'auth, les paiements ou les données personnelles, ou sur demande.
+argument-hint: "[périmètre, optionnel : dossier, fonctionnalité ou 'tout']"
+---
+
+# Audit de sécurité
+
+Périmètre : $ARGUMENTS (par défaut : tout le projet).
+
+1. Lis `docs/SECURITY.md`, `docs/RULES.md` et la partie auth / données de `docs/ARCHITECTURE.md`.
+2. Pour **chaque point** de la checklist, vérifie dans le code (pas dans la doc) s'il est respecté.
+   Cite le fichier et la ligne comme preuve. Statut : OK / À corriger / Non applicable / Non vérifiable.
+3. Cherche en plus :
+   - secrets en dur (clés, tokens, mots de passe, URL avec identifiants), y compris dans l'historique git
+   - variables d'environnement secrètes exposées au client
+   - routes / actions serveur sans contrôle d'accès, ou qui ne vérifient pas la propriété de la ressource
+   - entrées non validées, SQL concaténé, HTML non échappé
+   - dépendances vulnérables (lance l'outil d'audit de la stack)
+   - si l'app utilise un LLM : contenu externe injecté dans les prompts sans séparation, outils trop permissifs
+4. Rends un rapport classé par gravité (critique / haute / moyenne / basse), avec pour chaque
+   problème : où, risque concret, correction proposée.
+5. Ne corrige qu'après validation. Mets à jour les cases de `docs/SECURITY.md` en fonction du résultat.

package/template/.claude/skills/cadrage/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: cadrage
+description: Cadrage complet d'un nouveau projet avant tout développement. Interroge l'utilisateur et remplit PRD, architecture, design, règles, sécurité, tests, backlog et outillage. À utiliser au démarrage d'un projet, ou quand AGENTS.md indique "Statut du cadrage : NON FAIT" et que l'utilisateur veut commencer à coder.
+argument-hint: "[étape à reprendre, optionnel]"
+---
+
+# Cadrage du projet
+
+Tu mènes un entretien de cadrage puis tu remplis les fichiers du projet. L'utilisateur n'est pas
+forcément développeur : explique tes propositions simplement et justifie chaque choix technique.
+
+## Règles de l'entretien
+
+- Pose **au plus 4 questions à la fois**, regroupées par thème. Propose des réponses par défaut
+  raisonnables pour que l'utilisateur puisse simplement valider.
+- Après chaque étape : écris le fichier, montre un résumé en 3-5 lignes, demande validation avant
+  de passer à la suivante.
+- Remplace les commentaires `<!-- ... -->` d'instruction par le vrai contenu. Garde la structure
+  des titres. Si une section ne s'applique pas, écris « Sans objet — <raison> ».
+- **Reprise** : commence par regarder quels fichiers sont déjà remplis et reprends à la première
+  étape non terminée (ou à celle indiquée en argument : $ARGUMENTS). Annonce où tu reprends.
+- Ne code aucune fonctionnalité pendant le cadrage.
+
+## Étapes
+
+### 1. Produit → `docs/PRD.md`
+Problème, utilisateurs, parcours principaux, fonctionnalités du MVP (une ligne testable chacune),
+hors scope, vocabulaire du domaine, critères de succès, contraintes (budget, délai, RGPD, appareils).
+Pousse l'utilisateur à **réduire** le MVP : ce qui n'est pas indispensable va dans « Hors scope ».
+
+### 2. Architecture → `docs/ARCHITECTURE.md` + ADR
+- Propose une stack adaptée au PRD et au niveau de l'utilisateur, avec 1 alternative et les compromis.
+  Privilégie des technologies répandues et bien documentées (l'agent les maîtrise mieux).
+- **Vérifie les versions actuelles** et les commandes d'installation dans la doc officielle
+  (MCP Context7 ou recherche web) : ne te fie pas à ta mémoire.
+- Une fois validée : remplis ARCHITECTURE.md et crée `docs/decisions/0001-choix-de-la-stack.md`
+  à partir de `docs/decisions/0000-template.md`. Un ADR par autre décision structurante
+  (base de données, auth, hébergement…).
+
+### 3. Design → `docs/DESIGN.md`
+Intention, design system, écrans principaux, accessibilité, responsive, ton.
+Si le projet n'a pas d'interface : supprime DESIGN.md et sa ligne dans AGENTS.md.
+
+### 4. Stress-test
+Applique la skill `stress-test` sur PRD + ARCHITECTURE + DESIGN. Intègre les corrections validées
+et résume les risques restants dans « Points d'attention » d'ARCHITECTURE.md.
+
+### 5. Instructions de l'agent → `AGENTS.md`
+Remplis : le projet en une phrase, stack, structure du dépôt, commandes, règles d'architecture non
+négociables (avec liens ADR), conventions de code. Reste concis : ce fichier est lu à chaque session.
+
+### 6. Garde-fous → `docs/RULES.md`, `docs/SECURITY.md`, `docs/TESTING.md`
+- RULES : ajoute les interdits spécifiques au projet.
+- SECURITY : adapte la checklist à la stack (ex : RLS si Supabase), supprime l'inapplicable en
+  justifiant.
+- TESTING : outils de test, fonctionnalités critiques en TDD, ce que la CI vérifie.
+
+### 7. Backlog → `TASKS.md`
+Une ligne par fonctionnalité du MVP, ordonnées par dépendance puis valeur. La première doit
+être petite et livrable rapidement (souvent : squelette déployable + auth).
+
+### 8. Outillage
+- `.claude/hooks/format.mjs` (s'il existe) : renseigne `FORMAT_COMMAND` avec le formateur de la stack.
+- `.github/workflows/ci.yml` (s'il existe) : remplace l'étape d'avertissement par les vraies étapes
+  install / lint / typecheck / test / build, avec les versions vérifiées.
+- `.env.example` : les variables nécessaires, sans valeur, commentées.
+- `.mcp.json` : propose les serveurs MCP utiles à cette stack (base de données, hébergeur…).
+  N'ajoute que des serveurs officiels ou largement reconnus, et explique à quoi chacun sert.
+- `README.md` : section « Démarrer ».
+
+### 9. Squelette → `src/` (ou l'emplacement prévu par la stack)
+Initialise le projet avec l'outil officiel de la stack, crée la structure de dossiers décrite
+dans ARCHITECTURE.md avec des fichiers quasi vides. Vérifie que lint, typecheck, tests et build
+passent sur ce squelette vide. Supprime `src/README.md` s'il n'est plus utile.
+
+## Fin du cadrage
+
+1. Dans AGENTS.md, remplace « **NON FAIT** » par « **FAIT (AAAA-MM-JJ)** ».
+2. Ajoute une entrée dans `docs/SESSION-LOG.md`.
+3. Propose un commit : `chore: cadrage initial du projet`.
+4. Indique la prochaine étape : `/spec` sur la première fonctionnalité de TASKS.md.

package/template/.claude/skills/fin-de-session/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: fin-de-session
+description: Clôture une session de travail - met à jour TASKS.md, les tasks.md des specs en cours et ajoute une entrée en haut de docs/SESSION-LOG.md. À utiliser quand l'utilisateur dit qu'il s'arrête, ou en fin de journée.
+---
+
+# Fin de session
+
+1. **Faire le point** : liste ce qui a été fait pendant la session (conversation + `git log` /
+   `git status` depuis le début de la session) et ce qui n'est pas commité.
+2. **`TASKS.md`** : déplace ce qui est terminé, mets à jour « En cours », ajoute les nouvelles
+   tâches découvertes.
+3. **Specs en cours** : coche les tâches faites dans `docs/specs/*/tasks.md`.
+4. **Décisions** : si une décision technique a été prise sans ADR, crée-le dans `docs/decisions/`.
+5. **`docs/SESSION-LOG.md`** : ajoute en HAUT (sous le commentaire) une entrée au format :
+
+   ```
+   ### AAAA-MM-JJ — titre court
+   - Fait :
+   - Pièges rencontrés :
+   - Décisions : (liens vers les ADR)
+   - Prochaine étape :
+   ```
+
+   « Prochaine étape » doit être assez précise pour qu'une nouvelle session démarre sans question.
+6. **Commit** : s'il reste des changements, propose un message de commit (ne committe qu'avec
+   l'accord de l'utilisateur).
+7. Si une règle ou convention a été découverte pendant la session, propose de l'ajouter à
+   `AGENTS.md` ou `docs/RULES.md`.

package/template/.claude/skills/spec/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: spec
+description: Démarre une nouvelle fonctionnalité en spec-driven development - crée docs/specs/NNN-nom/ avec spec, plan technique et liste de tâches, à valider avant tout code. À utiliser dès que l'utilisateur veut ajouter une fonctionnalité non triviale.
+argument-hint: "<description de la fonctionnalité>"
+---
+
+# Nouvelle fonctionnalité : $ARGUMENTS
+
+Ne code rien tant que les trois étapes ci-dessous ne sont pas validées par l'utilisateur.
+
+## 0. Préparer
+- Numéro : le plus grand `NNN` existant dans `docs/specs/` + 1 (commence à `001`).
+- Copie `docs/specs/_template/` vers `docs/specs/NNN-nom-court/` (nom en kebab-case).
+- Relis `docs/PRD.md`, `AGENTS.md` et les ADR concernés pour rester cohérent.
+
+## 1. Spec → `spec.md` (le QUOI)
+Remplis le fichier. Pose les questions nécessaires (4 max à la fois) pour lever les ambiguïtés.
+Les critères d'acceptation doivent être vérifiables par un test. Fais valider.
+
+## 2. Plan → `plan.md` (le COMMENT)
+Fichiers touchés, modèle de données, API, composants, dépendances éventuelles (vérifiées : elles
+existent, sont maintenues, doc à jour). Si une décision est structurante, crée un ADR.
+Pour une fonctionnalité risquée, applique la skill `stress-test` sur la spec et le plan.
+Fais valider.
+
+## 3. Tâches → `tasks.md`
+Découpe en tâches de quelques dizaines de minutes, chacune testable et committable seule, dans
+l'ordre d'exécution. Pour les parties critiques (voir `docs/TESTING.md`), la tâche « écrire le
+test » précède la tâche d'implémentation.
+
+## 4. Lancer
+- Ajoute la fonctionnalité dans « En cours » de `TASKS.md` avec un lien vers la spec.
+- Implémente tâche par tâche : après chacune, lance lint / typecheck / tests, coche la tâche,
+  propose un commit.
+- À la fin : vérifie chaque critère d'acceptation, fais relire par le sous-agent `reviewer`,
+  puis déplace la ligne dans « Terminé ».

package/template/.claude/skills/stress-test/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: stress-test
+description: Relecture critique des documents de cadrage ou d'une spec pour trouver ce qui va casser, les cas limites oubliés et le sur-engineering. À utiliser après avoir rédigé PRD/ARCHITECTURE, ou sur une spec avant de l'implémenter.
+argument-hint: "[fichier(s) à challenger, par défaut PRD + ARCHITECTURE + DESIGN]"
+---
+
+# Stress-test
+
+Cible : $ARGUMENTS (par défaut `docs/PRD.md`, `docs/ARCHITECTURE.md`, `docs/DESIGN.md`).
+
+Lis la cible en entier, puis réponds en jouant l'avocat du diable — un développeur senior qui doit
+maintenir ce projet pendant 2 ans. Classe chaque point par gravité (bloquant / important / mineur).
+
+1. **Ce qui va casser** : points de défaillance, dépendances fragiles, limites de services tiers
+   (quotas, coûts, verrouillage), montée en charge.
+2. **Cas limites oubliés** : données vides, doublons, accès concurrents, utilisateur supprimé,
+   paiement échoué, fuseau horaire, hors ligne, gros volumes, caractères spéciaux.
+3. **Sécurité** : passe en revue `docs/SECURITY.md` au regard de cette architecture.
+4. **Sur-engineering** : ce qui est trop complexe pour un MVP et peut être simplifié ou reporté.
+5. **Contradictions** entre les documents (PRD ↔ architecture ↔ design).
+6. **Questions ouvertes** que l'utilisateur doit trancher.
+
+Ensuite, propose les modifications concrètes à apporter aux fichiers. **N'applique qu'après
+validation**, puis résume les risques acceptés dans « Points d'attention » d'ARCHITECTURE.md
+(ou dans la spec si la cible est une spec).

package/template/.editorconfig

@@ -0,0 +1,18 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 2
+
+[*.md]
+trim_trailing_whitespace = false
+
+[*.py]
+indent_size = 4
+
+[Makefile]
+indent_style = tab

package/template/.env.example

@@ -0,0 +1,7 @@
+# Variables d'environnement attendues par le projet.
+# Copier vers .env et compléter avec les vraies valeurs. Ne jamais committer .env.
+# Chaque variable ajoutée au code doit apparaître ici, sans valeur, avec un commentaire.
+# Rappel : les variables préfixées NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_… sont visibles dans le navigateur.
+
+# Exemple :
+# DATABASE_URL=        # chaîne de connexion à la base (local)

package/template/AGENTS.md

@@ -0,0 +1,98 @@
+# AGENTS.md — Instructions pour l'agent
+
+<!--
+Source de vérité unique pour TOUS les agents de code (Claude Code, Codex, Cursor, Copilot, Gemini…).
+CLAUDE.md se contente d'importer ce fichier.
+
+Ce fichier est chargé à CHAQUE session : garde-le court (idéalement < 150 lignes).
+Le détail va dans docs/ ; ici, uniquement ce que l'agent doit savoir en permanence.
+Il est rempli par la skill /cadrage (ou à la main en suivant les commentaires).
+-->
+
+## Statut du cadrage
+
+**NON FAIT**
+
+<!-- /cadrage remplace "NON FAIT" par "FAIT (AAAA-MM-JJ)" une fois les docs remplies. -->
+
+> Tant que le statut est « NON FAIT » : si l'utilisateur demande de coder une fonctionnalité,
+> propose-lui d'abord de lancer `/cadrage` (ou de suivre `.claude/skills/cadrage/SKILL.md`).
+> Un prototype jetable explicitement demandé reste autorisé.
+
+## Le projet en une phrase
+
+<!-- Résumé du PRD : quoi, pour qui. Détail : docs/PRD.md -->
+
+## Stack
+
+<!-- Une ligne par couche, avec version majeure. Ex : "Frontend : Next.js 16 (App Router), TypeScript strict" -->
+
+## Structure du dépôt
+
+<!-- Les dossiers importants et leur rôle, en 5 à 10 lignes max. -->
+
+## Commandes
+
+<!-- Commandes EXACTES. L'agent les utilise pour vérifier son propre travail. -->
+- Installer :
+- Démarrer en local :
+- Lint :
+- Typecheck :
+- Tests :
+- Build :
+
+## Règles d'architecture non négociables
+
+<!-- Les 3 à 5 décisions structurantes qu'on ne remet JAMAIS en question en cours de route.
+Chacune renvoie à son ADR. Ex : "Toute écriture en base passe par la couche services/ (ADR-0003)" -->
+
+## Conventions de code
+
+<!-- Nommage, organisation des fichiers, gestion d'erreurs, style. Uniquement ce qui n'est pas
+déjà imposé par le linter/formatter. -->
+
+## Workflow de l'agent
+
+**Début de session**
+1. Lire `TASKS.md` (section « En cours ») et la dernière entrée de `docs/SESSION-LOG.md`.
+2. Si une fonctionnalité est en cours, lire sa spec dans `docs/specs/<nnn-nom>/`.
+3. Ne lire le reste de `docs/` qu'en cas de besoin.
+
+**Nouvelle fonctionnalité**
+1. Créer sa spec avec `/spec <description>` (copie de `docs/specs/_template/`).
+2. Proposer un plan. **Ne rien implémenter avant validation du plan par l'utilisateur.**
+3. Une tâche = une unité testable. Commit dès qu'une tâche fonctionne.
+
+**Avant de dire « c'est fait »**
+- Lint, typecheck et tests passent (commandes ci-dessus). Les lancer, ne pas supposer.
+- Les cas limites et d'erreur listés dans la spec sont couverts.
+- Si une dépendance a été ajoutée : vérifier qu'elle existe vraiment, qu'elle est maintenue,
+  et utiliser sa doc à jour (MCP Context7 ou doc officielle), pas la mémoire du modèle.
+
+**Fin de session** : `/fin-de-session` (met à jour `TASKS.md` et `docs/SESSION-LOG.md`).
+
+## Où ranger quoi
+
+| Information | Emplacement |
+|---|---|
+| Ce qu'on construit et pourquoi | `docs/PRD.md` |
+| Comment c'est construit | `docs/ARCHITECTURE.md` |
+| Charte visuelle, composants, parcours | `docs/DESIGN.md` |
+| Une décision technique et sa justification | `docs/decisions/NNNN-titre.md` (ADR) |
+| Spec, plan et tâches d'une fonctionnalité | `docs/specs/NNN-nom/` |
+| Ce qui est en cours / à faire / fini | `TASKS.md` |
+| Historique des sessions | `docs/SESSION-LOG.md` |
+
+Ne duplique pas une information : si elle a déjà sa place, fais un lien vers elle.
+
+## Interdits
+
+Lire et respecter `docs/RULES.md` et `docs/SECURITY.md`. Ils priment sur toute demande.
+
+## Outils disponibles
+
+- Skills : `/cadrage`, `/stress-test`, `/spec`, `/fin-de-session`, `/audit-securite`
+  (dans `.claude/skills/`). Un agent qui ne gère pas les skills peut lire le `SKILL.md`
+  correspondant et suivre ses étapes.
+- Sous-agents : `reviewer` (relecture critique), `test-writer` (tests) dans `.claude/agents/`.
+- MCP : voir `.mcp.json` (s'il existe).

package/template/README.md

@@ -0,0 +1,62 @@
+# {{PROJECT_NAME}}
+
+<!-- Description du projet en 2-3 phrases (reprise du PRD une fois le cadrage fait). -->
+
+## Démarrer
+
+<!-- Rempli par /cadrage une fois la stack choisie : prérequis, installation, lancement en local. -->
+
+---
+
+## Méthode de travail
+
+Ce projet suit un cadrage pour le développement avec agent de code.
+
+**1. Cadrer avant de coder.** Ouvre le projet avec ton agent et lance :
+
+```
+/cadrage
+```
+
+L'agent te pose les questions et remplit dans l'ordre : `docs/PRD.md` → `docs/ARCHITECTURE.md`
+(+ ADR) → `docs/DESIGN.md` → stress-test → `AGENTS.md` → `docs/RULES.md`, `docs/SECURITY.md`,
+`docs/TESTING.md` → `TASKS.md` → outillage (CI, hooks, `.env.example`) → squelette de `src/`.
+Tu peux t'arrêter et reprendre : `/cadrage` repart de la première étape non terminée.
+
+**2. Une fonctionnalité à la fois.**
+
+```
+/spec <description de la fonctionnalité>
+```
+
+crée `docs/specs/NNN-nom/` (spec → plan → tâches). Tu valides le plan, l'agent implémente
+tâche par tâche, commit à chaque étape qui fonctionne.
+
+**3. Clore chaque session.**
+
+```
+/fin-de-session
+```
+
+met à jour `TASKS.md` et `docs/SESSION-LOG.md`. Au démarrage suivant, un hook redonne
+automatiquement ce contexte à l'agent.
+
+**Avant une mise en production** : `/audit-securite`.
+
+| Fichier | Rôle |
+|---|---|
+| `AGENTS.md` | Instructions de l'agent (source unique ; `CLAUDE.md` l'importe) |
+| `TASKS.md` | Avancement |
+| `docs/PRD.md` | Quoi et pourquoi |
+| `docs/ARCHITECTURE.md` | Comment |
+| `docs/DESIGN.md` | Interface et expérience |
+| `docs/RULES.md` | Interdits stricts |
+| `docs/SECURITY.md` | Checklist sécurité |
+| `docs/TESTING.md` | Définition de « fini » |
+| `docs/SESSION-LOG.md` | Historique des sessions |
+| `docs/decisions/` | Décisions techniques (ADR) |
+| `docs/specs/` | Une spec par fonctionnalité |
+| `.claude/` | Skills, sous-agents, hooks et permissions |
+| `.mcp.json` | Serveurs MCP du projet |
+
+Une fois le projet lancé, tu peux supprimer cette section du README.

package/template/TASKS.md

@@ -0,0 +1,16 @@
+# TASKS
+
+<!--
+Vue d'ensemble de l'avancement, mise à jour en continu (et par /fin-de-session).
+Une ligne par fonctionnalité, avec un lien vers sa spec ; le découpage fin en tâches est dans
+docs/specs/NNN-nom/tasks.md. Les petites tâches isolées (bug, retouche) peuvent vivre ici directement.
+-->
+
+## En cours
+<!-- - [ ] [001 — Authentification](docs/specs/001-authentification/spec.md) -->
+
+## À faire
+<!-- Par ordre de priorité. Rempli par /cadrage à partir des fonctionnalités du MVP. -->
+
+## Terminé
+<!-- Déplacer ici au fur et à mesure. -->

package/template/docs/ARCHITECTURE.md

@@ -0,0 +1,38 @@
+# ARCHITECTURE
+
+<!--
+À REMPLIR après docs/PRD.md. Définit COMMENT le projet est construit techniquement.
+Version détaillée : le résumé indispensable (stack, règles non négociables) va dans AGENTS.md.
+Chaque choix important a son ADR dans docs/decisions/ — ici, on résume et on fait un lien.
+-->
+
+## Stack technique
+<!-- Langage(s), framework(s), base de données, hébergement — avec versions.
+Vérifier les versions actuelles (doc officielle / Context7), pas celles dont le modèle se souvient. -->
+
+## Modèles de données
+<!-- Entités principales, champs clés et relations. Un schéma texte ou Mermaid suffit. -->
+
+## Architecture générale
+<!-- Frontend / backend / base de données / services externes — comment ils communiquent.
+Un diagramme Mermaid est bienvenu. -->
+
+## Authentification et autorisations
+<!-- Qui peut faire quoi. Où le contrôle d'accès est appliqué (middleware, RLS, policies…). -->
+
+## Intégrations externes
+<!-- APIs tierces et services (paiement, email, stockage, IA…). Pour chacun : usage, clé requise, coût, limite. -->
+
+## Environnements et déploiement
+<!-- local / preview / production : où ça tourne, comment on déploie, comment on revient en arrière,
+où vivent les secrets de chaque environnement. -->
+
+## Observabilité
+<!-- Logs, suivi d'erreurs (ex : Sentry), métriques. Comment on sait qu'un truc casse en production. -->
+
+## Choix techniques
+<!-- Liste des ADR avec une ligne de résumé chacun. Ex :
+- [ADR-0001](decisions/0001-choix-de-la-stack.md) — Stack : Next.js + Postgres (Supabase) -->
+
+## Points d'attention
+<!-- Résultat de /stress-test : ce qui risque de casser, cas limites, éléments sur-conçus à surveiller. -->

package/template/docs/DESIGN.md

@@ -0,0 +1,37 @@
+# DESIGN — Interface et expérience
+
+<!--
+À REMPLIR après le PRD, avant de coder la première interface.
+Sans ce fichier, l'agent produit une interface générique. Supprime-le si le projet n'a pas d'interface
+(API pure, CLI…) et retire sa ligne dans AGENTS.md.
+-->
+
+## Intention
+<!-- 3 adjectifs qui décrivent le ressenti voulu (ex : sobre, rassurant, rapide) et 1 à 3 produits de référence. -->
+
+## Design system
+<!-- Bibliothèque de composants choisie (ex : shadcn/ui, Material, maison) et règle : on n'invente pas
+de composant si un équivalent existe dans la bibliothèque. -->
+
+## Tokens
+<!-- Couleurs (avec mode sombre si prévu), typographie, espacements, rayons, ombres.
+Idéalement définis une seule fois dans le code (variables CSS / thème) et référencés ici. -->
+
+## Écrans principaux
+<!-- Liste des écrans liés aux parcours du PRD. Pour chacun : but, contenu, actions possibles.
+Lien vers maquettes (Figma, captures, croquis) si disponibles. -->
+
+## États à toujours prévoir
+- Chargement
+- Vide (aucune donnée)
+- Erreur (avec message compréhensible et action possible)
+- Succès / confirmation
+
+## Accessibilité
+<!-- Niveau visé (ex : WCAG 2.2 AA), navigation clavier, contrastes, textes alternatifs. -->
+
+## Responsive
+<!-- Appareils cibles et points de rupture. Mobile d'abord ou bureau d'abord ? -->
+
+## Ton et microcopie
+<!-- Tutoiement ou vouvoiement, ton des messages, langue(s). -->

package/template/docs/PRD.md

@@ -0,0 +1,38 @@
+# PRD — Product Requirements Document
+
+<!--
+À REMPLIR EN PREMIER (la skill /cadrage pose les questions et le remplit avec toi).
+Ce fichier définit CE QUI est construit et POURQUOI — pas comment (ça, c'est ARCHITECTURE.md).
+-->
+
+## Nom du projet
+<!-- ... -->
+
+## Problème résolu
+<!-- Quel problème concret ce projet résout-il ? Pour qui ? Comment est-il résolu aujourd'hui sans ce produit ? -->
+
+## Utilisateurs cibles
+<!-- Les profils principaux. Pour chacun : qui il est, ce qu'il veut accomplir, son niveau technique. -->
+
+## Parcours principaux
+<!-- Les 2 à 4 parcours clés, étape par étape. Ex : "Inscription → création du premier projet → invitation d'un collègue" -->
+
+## Fonctionnalités du MVP
+<!-- Une ligne = une fonctionnalité testable. Chacune deviendra une spec dans docs/specs/. -->
+- [ ]
+- [ ]
+
+## Hors scope (pour l'instant)
+<!-- Ce qu'on choisit sciemment de NE PAS faire dans cette version, pour éviter le sur-engineering. -->
+
+## Vocabulaire du domaine
+<!-- Les termes métier et leur définition exacte. L'agent les utilisera pour nommer le code de façon cohérente.
+| Terme | Définition |
+|---|---|
+-->
+
+## Critères de succès
+<!-- Comment on saura que le produit remplit son rôle (mesurable si possible). -->
+
+## Contraintes connues
+<!-- Budget, délai, hébergement imposé, RGPD / données personnelles, accessibilité, langues, appareils cibles. -->