# Init Project > Initialise un nouveau projet. Analyse la stack, génère des agents spécialisés, crée les règles clean code/archi, cherche des skills sur SkillsMP/GitHub, crée les issues GitHub. Lance ce skill au démarrage de chaque projet. - Skill: `diegosouzapw/init-project` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add diegosouzapw/init-project` - Raw SKILL.md: https://api.skillmd.com/api/skills/diegosouzapw/init-project/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: diegosouzapw (https://skillmd.com/u/diegosouzapw) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/diegosouzapw/init-project --- Tu initialises le projet. Le setup est **entièrement automatique** — tu analyses le projet et tu configures tout. ## Contexte du projet !`cat project.md` --- ## Phase 1 — Valider project.md - Vérifie que toutes les sections obligatoires sont remplies (pas de placeholders) - Sections obligatoires : Nom, Description, Stack technique, Structure, User Stories - Si des sections sont incomplètes → demande à l'utilisateur de les remplir - Vérifie le format des US : `- [US-XX] Titre | Description | Priorité | Dépendances (optionnel)` --- ## Phase 1.5 — Brainstorm : enrichir les US et structurer le projet **C'est la phase clé.** Tu ne te contentes pas de recopier les US — tu **réfléchis au projet** et tu l'améliores. ### 1.5.1 Analyser la cohérence du projet - Les US couvrent-elles tous les aspects de la description du projet ? - Manque-t-il des US évidentes ? (Ex: le projet mentionne "authentification" mais aucune US d'auth) - Y a-t-il des US trop grosses qui devraient être découpées ? - Y a-t-il des US trop vagues qui méritent d'être précisées ? **Si des US manquent ou sont mal découpées** → propose des ajouts/modifications à l'utilisateur : ``` Analyse du projet : US manquantes détectées : - Le projet mentionne "authentification" mais aucune US ne couvre le login/register - Pas d'US pour le setup initial (DB, config, CI) US trop grosses à découper : - US-03 "Dashboard complet" → suggère US-03a "Layout + navigation" + US-03b "Widgets stats" Voulez-vous que j'ajoute/modifie ces US ? ``` ### 1.5.2 Enrichir chaque US Pour chaque US, génère : **Critères d'acceptance** — conditions vérifiables pour considérer l'US comme terminée : ```markdown ### Critères d'acceptance - [ ] L'utilisateur peut se connecter avec email/password - [ ] Un token JWT est généré et stocké en cookie httpOnly - [ ] Les routes protégées redirigent vers /login si non authentifié - [ ] Les erreurs de login affichent un message clair ``` **Sous-tâches techniques** — décomposition en tâches concrètes : ```markdown ### Sous-tâches techniques 1. Créer le schéma User (Prisma/Mongoose/...) 2. Implémenter l'endpoint POST /api/auth/register 3. Implémenter l'endpoint POST /api/auth/login 4. Créer le middleware d'authentification 5. Créer les pages /login et /register 6. Écrire les tests d'auth (unit + e2e) ``` **Fichiers impactés** — estimation des fichiers à créer/modifier : ```markdown ### Fichiers impactés (estimation) - Créer : src/lib/auth.ts, src/app/api/auth/[...]/route.ts - Créer : src/app/(auth)/login/page.tsx, src/app/(auth)/register/page.tsx - Modifier : prisma/schema.prisma (ajouter modèle User) - Créer : src/middleware.ts (auth middleware) ``` ### 1.5.3 Détecter les dépendances automatiquement Analyse TOUTES les US entre elles pour détecter les dépendances **même si l'utilisateur ne les a pas spécifiées** : **Règles de détection automatique :** | Signal | Type de dépendance | |--------|--------------------| | US-B mentionne un modèle/table créé dans US-A | `après:US-A` | | US-B utilise un endpoint/service de US-A | `après:US-A` | | US-B a besoin de l'auth et US-A = auth | `après:US-A` | | US-A et US-B modifient les mêmes fichiers | `partage:US-A` | | US-B ajoute une fonctionnalité à ce que US-A construit | `enrichit:US-A` | | US-B = page qui affiche des données et US-A = API qui fournit ces données | `après:US-A` | **Exemple concret :** ``` US déclarées par l'utilisateur : - [US-01] Auth utilisateur | Login/register | haute - [US-02] Dashboard | Stats et graphiques | haute - [US-03] API publique | CRUD endpoints | moyenne - [US-04] Export CSV | Exporter les données | basse Dépendances détectées automatiquement : ✓ US-02 → après:US-01 (le dashboard a besoin de l'auth pour les routes protégées) ✓ US-02 → après:US-03 (le dashboard affiche des données de l'API) ✓ US-04 → enrichit:US-03 (l'export utilise les mêmes données que l'API) ✓ US-03 → après:US-01 (l'API a besoin de l'auth pour sécuriser les endpoints) ``` ### 1.5.4 Proposer un US-00 "Setup initial" si nécessaire Si le projet n'a pas encore de structure de base, propose une US-00 : ``` [US-00] Setup initial | Config projet, DB, CI, structure de base | haute - Init du projet (npm init, tsconfig, etc.) - Configurer la base de données (schema initial, connexion) - Configurer le linter et le formatter - Configurer les tests (framework, config) - Configurer la CI (GitHub Actions) - Créer la structure de dossiers ``` **Toutes les autres US dépendront de US-00** si le projet n'existe pas encore. ### 1.5.5 Valider avec l'utilisateur Présente le brainstorm complet et demande validation : ``` ═══════════════════════════════════════════════ BRAINSTORM — Analyse du projet ═══════════════════════════════════════════════ US enrichies : [US-01] Auth utilisateur (haute) → 4 critères d'acceptance → 6 sous-tâches techniques → Dépendances : aucune (racine) [US-02] Dashboard (haute) → 5 critères d'acceptance → 8 sous-tâches techniques → Dépendances détectées : après:US-01, après:US-03 US ajoutées (suggérées) : [US-00] Setup initial (haute) — recommandé si projet vierge Dépendances détectées automatiquement : US-01 ──→ US-02, US-03 US-03 ──→ US-02, US-04 Graphe d'exécution : US-00 → US-01 → US-03 → US-02 → US-04 Valider ce plan ? (oui / modifier) ═══════════════════════════════════════════════ ``` **YOU MUST** obtenir la validation de l'utilisateur avant de continuer. --- ## Phase 2 — Analyser le projet ### 2.1 Détecter la stack Lis `project.md` section "Stack technique" et identifie : - **Langage principal** : TypeScript, JavaScript, Python, Rust, Go, Java... - **Framework** : Next.js, Express, Fastify, NestJS, Django, FastAPI, Actix... - **Base de données** : PostgreSQL, MongoDB, MySQL, Redis, SQLite... - **ORM/ODM** : Prisma, Drizzle, Mongoose, TypeORM, SQLAlchemy... - **Tests** : Jest, Vitest, Playwright, Cypress, pytest... - **Linter** : ESLint, Biome, Prettier, Ruff... - **UI** : Tailwind, Shadcn, MUI, Chakra... - **Auth** : NextAuth, Auth0, Clerk, Supabase Auth... - **Autre** : Docker, Stripe, S3, Redis, GraphQL, tRPC... ### 2.2 Déterminer le type de projet | Pattern détecté | Type de projet | |-----------------|----------------| | Next.js + App Router | Full-stack SSR | | Express/Fastify + DB | API Backend | | React/Vue seul | SPA Frontend | | Next.js + API externe | BFF + Frontend | | CLI + pas de framework web | Outil CLI | | Monorepo (packages/) | Monorepo | ### 2.3 Identifier les domaines fonctionnels Analyse les US pour détecter les domaines : - Auth/Users, Dashboard/UI, API/Endpoints, Database/Models - Integrations (Stripe, S3, email...), Admin, etc. --- ## Phase 3 — Générer les règles clean code & architecture **Crée des fichiers de règles spécifiques au projet dans `.claude/rules/`.** ### 3.1 Architecture (`.claude/rules/architecture.md`) Génère des règles d'architecture **spécifiques à la stack détectée**. Sois opinionated, pas générique. Le fichier DOIT contenir : - **Structure** : organisation des dossiers et responsabilités de chaque couche - **Patterns obligatoires** : patterns du framework à utiliser systématiquement - **Séparation des responsabilités** : qui fait quoi dans quelle couche - **Gestion des données** : comment accéder à la DB, validation, DTOs - **Gestion d'erreurs** : stratégie d'error handling par couche **Exemples de contenu selon la stack :** Pour **Next.js + Prisma** : - App Router only, Server Components par défaut, `'use client'` uniquement si nécessaire - Route Handlers pour l'API, Server Actions pour les mutations - Validation zod sur tous les inputs - DB queries uniquement côté serveur - Error boundaries au niveau layout, Suspense pour loading states Pour **Express + MongoDB** : - Controllers → Services → Repositories → Models - Middleware chain pour cross-cutting concerns - Error handling middleware en dernier dans la chaîne - Mongoose lean() pour les lectures, indexes sur les FK Pour **FastAPI + PostgreSQL** : - Routers → Services → Repositories → Models (SQLAlchemy) - Pydantic models pour validation - Dependency injection pour les services - Alembic pour les migrations **Adapte TOUJOURS au projet réel.** Ne copie pas ces exemples tels quels. ### 3.2 Clean Code (`.claude/rules/clean-code.md`) Génère des règles clean code **adaptées au langage et framework** : Le fichier DOIT contenir : - **Nommage** : conventions précises par type de fichier/classe/fonction - **Anti-patterns interdits** : liste avec ❌ et alternative avec ✅ - **Patterns recommandés** : idiomes du framework - **Organisation des imports** : ordre et groupes - **Taille** : limites de taille pour fichiers/fonctions/classes - **Typage** : règles strictes de typage pour le langage ### 3.3 Testing (`.claude/rules/testing.md`) Génère des conventions de test **adaptées au framework de test** : Le fichier DOIT contenir : - **Structure** : où placer les tests, convention de nommage des fichiers - **Conventions** : patterns (AAA, describe/it), nommage des tests - **Couverture** : cas nominaux, limites, erreurs à couvrir - **Mocks** : quand mocker, quand ne pas mocker - **Commandes** : scripts npm/yarn pour lancer les tests ### 3.4 Mettre à jour le stabilizer Mets à jour `.claude/rules/stability.md` avec les commandes spécifiques au projet détectées : ```bash # Adapter les commandes au package manager et aux outils détectés # npm / yarn / pnpm # vitest / jest / pytest # eslint / biome / ruff # tsc / pyright / mypy ``` --- ## Phase 4 — Chercher des skills communautaires (SkillsMP / GitHub) **Cherche des skills existants qui matchent la stack du projet.** ```bash bash scripts/search-skills.sh --stack ``` **Évalue les résultats :** - ★ > 10 stars → pertinent, suggérer à l'utilisateur - Match exact avec un besoin → recommander fortement - Trop générique ou mauvaise qualité → ignorer **Présente les résultats à l'utilisateur :** ``` Skills communautaires trouvés pour votre stack : [RECOMMANDÉ] ★ 45 | nextjs-testing-skill Tests patterns pour Next.js App Router avec Vitest → bash scripts/install-skill.sh owner/repo [SUGGÉRÉ] ★ 23 | prisma-migration-skill Gestion des migrations Prisma avec rollback → bash scripts/install-skill.sh owner/repo Installer certains skills ? (listez les numéros ou "skip") ``` **Si l'utilisateur veut installer :** ```bash bash scripts/install-skill.sh [skill-name] ``` --- ## Phase 5 — Générer les agents spécialisés ### 5.1 Déterminer les rôles nécessaires Analyse la stack et les US pour créer les bons agents : | Stack / Besoin | Agent à générer | |----------------|-----------------| | Framework frontend (Next.js, React...) | `frontend-dev` | | Framework backend (Express, Fastify...) | `api-dev` | | Full-stack simple | `fullstack-dev` (un seul agent dev) | | Base de données + ORM | `db-architect` | | Auth (NextAuth, Auth0...) | `auth-dev` | | Intégrations (Stripe, S3...) | `integrations-dev` | | Tests unitaires | `unit-tester` | | Tests E2E (Playwright, Cypress) | `e2e-tester` | | UI complexe (Dashboard, forms) | `ui-dev` | | DevOps/CI | `devops` | **Règle** : ne génère PAS d'agents inutiles. Un projet simple = 2-3 agents spécialisés + core (forge, stabilizer, reviewer). ### 5.2 Créer les SKILL.md pour chaque agent Pour chaque agent, crée `.claude/skills//SKILL.md` avec : ```yaml --- name: description: user-invocable: true --- ``` Le contenu de chaque agent DOIT inclure : 1. **Contexte technique** : framework, langage, stack pertinente 2. **Expertise spécifique** : ce que cet agent sait faire en détail 3. **Conventions du projet** : importées des règles générées en Phase 3 4. **Patterns à suivre** : idiomes spécifiques au framework 5. **Anti-patterns à éviter** : erreurs courantes dans cette stack 6. **Mission** : ce qu'on attend de l'agent (`$ARGUMENTS` pour la tâche) **Chaque agent doit être un EXPERT de son domaine dans la stack du projet.** Il connaît les bonnes pratiques, les pièges, les patterns idiomatiques. Il n'est pas un développeur générique — il est spécialisé. ### 5.3 Mettre à jour team.md Réécris `.claude/team.md` avec les agents réels du projet : ```markdown # Équipe du projet ## Agents core (toujours présents) - **forge** — Team Lead orchestrateur - **stabilizer** — Quality gate (build, tests, lint, types) - **reviewer** — Revue de code qualité + sécurité ## Agents spécialisés (générés pour ce projet) - **** — - **** — ... ## Composition d'équipe par type de tâche | Type | Équipe | |------|--------| | Feature frontend | frontend-dev, unit-tester, stabilizer | | Feature API | api-dev, db-architect, unit-tester, stabilizer | | Feature full-stack | frontend-dev, api-dev, e2e-tester, reviewer, stabilizer | | Bug fix | , unit-tester, stabilizer | ``` --- ## Phase 6 — Auto-assigner les agents aux US Pour chaque US, analyse sa description et assigne les agents pertinents : 1. Identifie les domaines de l'US (frontend, API, DB, auth...) 2. Assigne les agents spécialisés correspondants 3. Ajoute toujours `stabilizer` en dernier 4. Ajoute `reviewer` si priorité haute ou domaine critique (auth, payment) Écris l'assignation dans : - Le body de chaque issue GitHub - `project.md` section "Équipe agentique par feature" (auto-générée) --- ## Phase 7 — Analyser les dépendances entre US 1. Parse les dépendances explicites (`après:`, `partage:`, `enrichit:`) 2. Détecte les dépendances **implicites** : - Même scope dans les agents assignés → risque de fichiers partagés - US dont la description mentionne une autre US - US de priorité basse qui étend une US de priorité haute 3. Vérifie qu'il n'y a pas de **cycles** 4. Détermine l'ordre d'exécution optimal : - Racines du graphe d'abord - Puis US dont toutes les dépendances sont satisfaites - Priorité (haute → moyenne → basse) à dépendances égales Types de relations : | Relation | Signification | Impact | |----------|---------------|--------| | `après:US-XX` | Dépendance stricte | US-XX doit être Done | | `partage:US-XX` | Mêmes fichiers/scope | Ne pas travailler en parallèle | | `enrichit:US-XX` | Étend une feature | US-XX doit être en cours ou Done | --- ## Phase 8 — Créer les labels et issues GitHub ### Labels ```bash gh label create "task" --description "US pas encore commencée" --color "0075ca" --force gh label create "in-progress" --description "US en cours" --color "e4e669" --force gh label create "done" --description "US terminée et stabilisée" --color "0e8a16" --force gh label create "bug" --description "Bug détecté" --color "d73a4a" --force gh label create "blocked" --description "US bloquée par une dépendance" --color "b60205" --force gh label create "haute" --description "Priorité haute" --color "d93f0b" --force gh label create "moyenne" --description "Priorité moyenne" --color "fbca04" --force gh label create "basse" --description "Priorité basse" --color "c5def5" --force ``` ### Issues Pour chaque US, crée une issue (ordre topologique) : ```markdown ## Description [Description de la US] ## Dépendances - **Bloquée par** : # ([US-YY] Titre) — type: après - **Partage le scope avec** : # ([US-ZZ] Titre) — type: partage ## Équipe agentique Agents : , , ..., stabilizer ## Priorité [haute/moyenne/basse] ``` --- ## Phase 9 — Résumé Affiche un rapport complet : ``` ═══════════════════════════════════════════════ PROJET INITIALISÉ : ═══════════════════════════════════════════════ Stack détectée : Langage : Framework : DB : + Tests : UI : Règles générées : .claude/rules/architecture.md — Patterns .claude/rules/clean-code.md — Conventions strict .claude/rules/testing.md — Stratégie Agents spécialisés créés : — — ... Agents core : forge — Team Lead orchestrateur stabilizer — Quality gate reviewer — Code review Skills communautaires : [installé] (★ XX) [suggéré] (★ XX) — non installé US créées : X Haute : X Moyenne : X Basse : X Graphe de dépendances : US-01 ──→ US-02 ──→ US-04 US-03 (indépendante) Ordre d'exécution recommandé : 1. US-01 (haute, racine) 2. ... ═══════════════════════════════════════════════ Prochaine étape : /forge ═══════════════════════════════════════════════ ```