Awesome-omni-skill 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 :

### 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)

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 :

après:US-A

après:US-A

après:US-A

partage:US-A

enrichit:US-A

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

• 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

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

# 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 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 scripts/install-skill.sh <github-owner/repo> [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 :

frontend-dev

api-dev

fullstack-dev

db-architect

auth-dev

integrations-dev

unit-tester

e2e-tester

ui-dev

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/<agent-name>/SKILL.md

---
name: <agent-name>
description: <description-spécifique-au-projet>
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

# É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 |

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 :

après:US-XX

partage:US-XX

enrichit:US-XX

Phase 8 — Créer les labels et issues GitHub

Labels

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) :

## 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]

Phase 9 — Résumé

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
═══════════════════════════════════════════════