菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/KJ-devs/setupClaudeCode --skill init-project命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
Implémente une feature ou un changement de code. Agent principal de développement.
Team Lead intelligent : décompose une US, délègue aux bons agents, gère les boucles de feedback, et livre une feature stable. Usage : /forge ou /forge <issue-number>
Prends la prochaine US et exécute le workflow complet (branch → assign team → implement → stabilize → PR → done → clean context). Utilise ce skill pour dépiler les features une par une.
正在显示 SKILL.md
| name | init-project |
| description | 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. |
| user-invocable | true |
Tu initialises le projet. Le setup est entièrement automatique — tu analyses le projet et tu configures tout.
!cat project.md 2>/dev/null || echo "ERREUR: project.md manquant. Crée-le d'abord."
- [US-XX] Titre | Description | Priorité | Dépendances (optionnel)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.
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 ?
Pour chaque US, génère :
Critères d'acceptance — conditions vérifiables pour considérer l'US comme terminée :
### 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 :
### 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 :
### 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)
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)
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.
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.
Lis project.md section "Stack technique" et identifie :
| 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 |
Analyse les US pour détecter les domaines :
Crée des fichiers de règles spécifiques au projet dans .claude/rules/.
.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 :
Exemples de contenu selon la stack :
Pour Next.js + Prisma :
'use client' uniquement si nécessairePour Express + MongoDB :
Pour FastAPI + PostgreSQL :
Adapte TOUJOURS au projet réel. Ne copie pas ces exemples tels quels.
.claude/rules/clean-code.md)Génère des règles clean code adaptées au langage et framework :
Le fichier DOIT contenir :
.claude/rules/testing.md)Génère des conventions de test TDD/BDD adaptées au framework de test détecté.
Le fichier DOIT contenir :
Given [...], When [...], Then [...]waitForTimeout(), pas de sélecteurs CSS fragilesdescribe > Given > it('should [...] when [...]')Mets à jour .claude/rules/stability.md avec les commandes spécifiques au projet détectées :
# Adapter les commandes au package manager et aux outils détectés
# npm / yarn / pnpm
# vitest / jest / pytest
# eslint / biome / ruff
# tsc / pyright / mypy
Cherche des skills existants qui matchent la stack du projet.
bash scripts/search-skills.sh --stack
Évalue les résultats :
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 scripts/install-skill.sh <github-owner/repo> [skill-name]
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).
Pour chaque agent, crée .claude/skills/<agent-name>/SKILL.md avec le bon frontmatter selon le type d'agent :
*-architect)---
name: <agent-name>
description: <description-spécifique-au-projet>
user-invocable: true
model: sonnet
context: fork
agent: Plan
allowed-tools: Read, Glob, Grep, WebSearch, WebFetch
---
→ context: fork + agent: Plan = read-only, ne modifie aucun fichier
→ model: sonnet = qualité de raisonnement optimale pour la planification
*-reviewer)---
name: <agent-name>
description: <description>. Read-only — ne modifie aucun fichier.
user-invocable: true
model: sonnet
context: fork
agent: Plan
allowed-tools: Read, Glob, Grep
---
→ Mêmes paramètres que les architectes (read-only, sonnet) → DOIT inclure les règles anti-hallucination (voir ci-dessous)
*-dev)---
name: <agent-name>
description: <description-spécifique-au-projet>
user-invocable: true
---
→ Pas de context: fork (ils modifient des fichiers)
→ Pas de model: spécifié (utilise le modèle par défaut)
*-tester)---
name: <agent-name>
description: <description-spécifique-au-projet>
user-invocable: true
---
→ Pas de context: fork (ils lancent des commandes et modifient des fichiers)
*-stabilizer, *-formatter)---
name: <agent-name>
description: <description-spécifique-au-projet>
user-invocable: true
model: haiku
---
→ model: haiku = optimisation coût pour les tâches mécaniques (lint, format, type-check)
Le contenu de chaque agent DOIT inclure :
$ARGUMENTS pour la tâche)Pour les agents *-tester et e2e-tester : DOIT inclure explicitement :
describe > Given > it('should [...] when [...]')Pour les agents *-dev : DOIT inclure explicitement :
Tout agent de type review DOIT inclure cette section :
## Anti-hallucination : VÉRIFIER AVANT D'AFFIRMER
**Règle critique** : ne jamais affirmer qu'un pattern existe sans le vérifier.
### Protocole de vérification
Avant chaque suggestion :
1. **Claims sur les patterns** → utilise `Grep` ou `Glob` pour vérifier
- Pattern > 10 occurrences = **Établi** → suggestion de conformité
- Pattern 3-10 occurrences = **Émergent** → demander confirmation
- Pattern < 3 occurrences = **Non établi** → ne pas imposer
2. **Lire le fichier complet** avant de reviewer — jamais juste le diff
3. **Marqueurs d'incertitude** :
- ❓ À vérifier : [affirmation qui nécessite confirmation]
- 💡 Suggestion : [amélioration optionnelle]
- 🔴 Must fix : [bug/sécurité critique, vérifié]
### Classification de sévérité
- 🔴 Must Fix (Bloquant) — Vulnérabilités, perte de données, échecs silencieux
- 🟡 Should Fix (Important) — Violations SOLID/DRY, N+1, gestion d'erreurs manquante
- 🟢 Can Skip (Optionnel) — Style, nommage mineur, documentation
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é.
Réécris .claude/team.md avec les agents réels du projet :
# Équipe du projet <nom>
## 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)
- **<agent-1>** — <description>
- **<agent-2>** — <description>
...
## 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 | <dev-pertinent>, unit-tester, stabilizer |
Pour chaque US, analyse sa description et assigne les agents pertinents :
stabilizer en dernierreviewer si priorité haute ou domaine critique (auth, payment)Écris l'assignation dans :
project.md section "Équipe agentique par feature" (auto-générée)après:, partage:, enrichit:)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 |
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
Pour chaque US, crée une issue (ordre topologique) :
## Description
[Description de la US]
## Dépendances
<!-- "Aucune — peut démarrer immédiatement" si pas de dépendances -->
- **Bloquée par** : #<numero> ([US-YY] Titre) — type: après
- **Partage le scope avec** : #<numero> ([US-ZZ] Titre) — type: partage
## Équipe agentique
Agents : <agent-1>, <agent-2>, ..., stabilizer
## Priorité
[haute/moyenne/basse]
Affiche un rapport complet :
═══════════════════════════════════════════════
PROJET INITIALISÉ : <nom-projet>
═══════════════════════════════════════════════
Stack détectée :
Langage : <langage>
Framework : <framework>
DB : <db> + <orm>
Tests : <test-framework>
UI : <ui-lib>
Règles générées :
.claude/rules/architecture.md — Patterns <framework>
.claude/rules/clean-code.md — Conventions <langage> strict
.claude/rules/testing.md — Stratégie <test-framework>
Agents spécialisés créés :
<agent-1> — <description-courte>
<agent-2> — <description-courte>
...
Agents core :
forge — Team Lead orchestrateur
stabilizer — Quality gate
reviewer — Code review
Skills communautaires :
[installé] <skill-1> (★ XX)
[suggéré] <skill-2> (★ 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
═══════════════════════════════════════════════