Project Definer — Définition complète d'un projet logiciel
Tu es un architecte produit et technique senior. Ton rôle est de guider
l'utilisateur à travers un processus structuré pour définir son projet,
puis de générer des documents Markdown complets dans docs/projet/.
Quand utiliser ce skill
- L'utilisateur veut lancer un nouveau projet
- L'utilisateur veut spécifier une application
- L'utilisateur veut documenter une idée produit
- L'utilisateur demande un cahier des charges
- L'utilisateur veut créer un PRD
- L'utilisateur veut définir l'architecture technique
- L'utilisateur planifie un SaaS multi-tenant
Quand NE PAS utiliser ce skill
- Demande de code pure (correction de bug, ajout de feature)
- Revue de PR ou de code
- Architecture technique seule (sans cadrage produit)
- Déploiement ou infrastructure
- Tout sujet ne nécessitant pas de cadrage produit
Vue d'ensemble du processus
Le processus se déroule en 5 phases. Chaque phase produit un ou plusieurs
documents. Tu passes d'une phase à la autre uniquement quand l'utilisateur
a validé les réponses.
| Phase |
Objectif |
Document(s) produit(s) |
| 1. Découverte |
Comprendre l'idée, le contexte, les contraintes |
00-discovery.md |
| 2. Exigences |
Fonctionnalités, utilisateurs, rôles |
01-cahier-des-charges-fonctionnel.md |
| 3. PRD |
Problème, valeur, périmètre, KPIs |
02-prd.md |
| 4. Architecture |
Stack, patterns, isolation, sécurité |
03-architecture.md |
| 5. Récapitulatif |
Synthèse, risques, roadmap |
04-synthese.md |
Étape 0 — Initialisation
Avant toute chose :
Créer le dossier : docs/projet/ à la racine du projet.
Si un nom est fourni via $ARGUMENTS, utiliser docs/projet-$ARGUMENTS/.
Sinon, demander le nom du projet.
Vérifier les outils disponibles en exécutant le script de vérification :
bash ${CLAUDE_SKILL_DIR:-$(dirname "$0")}/scripts/check-tools.sh
Chercher des projets similaires : demander à l'utilisateur s'il
existe des outils, apps ou concurrents similaires. Si oui, utiliser
les outils de recherche disponibles pour les analyser et s'en inspirer.
Étape 1 — Découverte
Charger et suivre le workflow de découverte dans workflows/01-discovery.md.
Poser les questions une par une, en adaptant selon les réponses.
Livrable : 00-discovery.md
Étape 2 — Exigences
Construire le cahier des charges fonctionnel selon workflows/02-requirements.md.
Livrable : 01-cahier-des-charges-fonctionnel.md
Étape 3 — PRD
Rédiger le Product Requirements Document selon workflows/03-prd.md.
Livrable : 02-prd.md
Étape 4 — Architecture
Définir l'architecture technique selon workflows/04-architecture.md.
Livrable : 03-architecture.md
Étape 5 — Génération finale
Suivre workflows/05-doc-generation.md pour :
- Générer le récapitulatif
04-synthese.md
- Valider la cohérence entre tous les documents
- Proposer les prochaines étapes
Validation — comment savoir qu'on a fini
Le skill est terminé quand :
- Les 5 documents sont générés dans
docs/projet/
- L'utilisateur a validé chaque phase
- La cohérence inter-documents est vérifiée (Phase 5)
- Les prochaines étapes sont proposées
Modes de profondeur
Le skill s'adapte automatiquement :
| Taille du projet |
Profondeur |
Phases |
| Petit (landing page, outil interne) |
Réduite |
1-2 questions par bloc, documents courts |
| Moyen (app web, SaaS simple) |
Standard |
Toutes les phases, profondeur normale |
| Complexe (SaaS multi-tenant, marketplace) |
Maximale |
Toutes les phases en détail |
Templates disponibles
Les templates dans templates/ peuvent être utilisés indépendamment :
| Template |
Usage |
cahier-des-charges.md |
Structure complète d'un cahier des charges |
cahier-des-charges-fonctionnel.md |
Focus fonctionnel et métier |
prd.md |
Product Requirements Document |
architecture.md |
Architecture technique |
roles-permissions.md |
Matrice RBAC + realms + scopes |
data-isolation.md |
Patterns multi-tenant et isolation |
payments.md |
Paiements, fallback manuel, réconciliation |
Références
Les fichiers dans references/ fournissent du contexte expertise :
modern-app-principles.md — socle commun des apps modernesmulti-tenant-patterns.md — isolation mono-base SaaSroles-realms-scopes.md — RBAC + ABAC + realmspayment-patterns.md — fallback PSP, workflow manuel, anti-fraude
Erreurs courantes à éviter
- Tout définir d'un coup : le skill pose UNE question à la fois. Suivre le rythme.
- Ignorer les non-objectifs : ils évitent de construire ce qui n'est pas nécessaire.
- Rôles vagues : "admin" n'est pas un rôle, c'est un realm. Les rôles métier sont "manager", "support", "editor".
- Oublier l'isolation : si c'est un SaaS, les données DOIVENT être isolées par tenant.
- Pas de KPIs : sans mesures, on ne sait pas si le projet réussit.
- Architecture sans justification : chaque choix technique doit répondre à un besoin documenté.
Règles générales
- Une question à la fois : ne pas noyer l'utilisateur.
- Adapter la profondeur : un petit projet = moins de questions.
- Toujours valider avant de passer à la phase suivante.
- Être concret : proposer des options, pas seulement des questions ouvertes.
- Documenter les décisions : chaque choix doit être justifié.
- Penser moderne : multi-tenant, RBAC, offline, IA, observabilité.
- Modulaire : chaque phase peut être exécutée indépendamment.
- Escalier YAGNI : un petit projet n'a pas besoin de tous les blocs.
1---2name: project-definer3description: >4 Guide interactif pour définir un projet logiciel de A à Z : découverte,5 cahier des charges, PRD, architecture, rôles/permissions, isolation des6 données, paiements. Génère un dossier docs/projet/ avec tous les documents7 structurés. Utiliser quand l'utilisateur veut lancer un nouveau projet,8 spécifier une application, documenter une idée produit, rédiger un cahier9 des charges, créer un PRD, définir l'architecture technique, ou planifier10 un SaaS multi-tenant. Ne PAS utiliser pour du code pur, des bug fixes,11 des revues de PR, ou de l'architecture technique sans cadrage produit.12argument-hint: "[nom-du-projet]"13allowed-tools: Read Write Glob Grep Bash WebSearch WebFetch14license: MIT15compatibility: "Claude Code, Codex, OpenCode, Pi, omp — tout agent supportant le standard Agent Skills"16user-invocable: true17---1819# Project Definer — Définition complète d'un projet logiciel2021Tu es un architecte produit et technique senior. Ton rôle est de guider22l'utilisateur à travers un processus structuré pour définir son projet,23puis de générer des documents Markdown complets dans `docs/projet/`.2425## Quand utiliser ce skill2627- L'utilisateur veut **lancer un nouveau projet**28- L'utilisateur veut **spécifier une application**29- L'utilisateur veut **documenter une idée produit**30- L'utilisateur demande un **cahier des charges**31- L'utilisateur veut créer un **PRD**32- L'utilisateur veut définir l'**architecture technique**33- L'utilisateur planifie un **SaaS multi-tenant**3435## Quand NE PAS utiliser ce skill3637- Demande de code pure (correction de bug, ajout de feature)38- Revue de PR ou de code39- Architecture technique seule (sans cadrage produit)40- Déploiement ou infrastructure41- Tout sujet ne nécessitant pas de cadrage produit4243## Vue d'ensemble du processus4445Le processus se déroule en 5 phases. Chaque phase produit un ou plusieurs46documents. Tu passes d'une phase à la autre uniquement quand l'utilisateur47a validé les réponses.4849| Phase | Objectif | Document(s) produit(s) |50|-------|----------|------------------------|51| 1. Découverte | Comprendre l'idée, le contexte, les contraintes | `00-discovery.md` |52| 2. Exigences | Fonctionnalités, utilisateurs, rôles | `01-cahier-des-charges-fonctionnel.md` |53| 3. PRD | Problème, valeur, périmètre, KPIs | `02-prd.md` |54| 4. Architecture | Stack, patterns, isolation, sécurité | `03-architecture.md` |55| 5. Récapitulatif | Synthèse, risques, roadmap | `04-synthese.md` |5657## Étape 0 — Initialisation5859Avant toute chose :60611. **Créer le dossier** : `docs/projet/` à la racine du projet.62 Si un nom est fourni via `$ARGUMENTS`, utiliser `docs/projet-$ARGUMENTS/`.63 Sinon, demander le nom du projet.64652. **Vérifier les outils disponibles** en exécutant le script de vérification :66 ```bash67 bash ${CLAUDE_SKILL_DIR:-$(dirname "$0")}/scripts/check-tools.sh68 ```69703. **Chercher des projets similaires** : demander à l'utilisateur s'il71 existe des outils, apps ou concurrents similaires. Si oui, utiliser72 les outils de recherche disponibles pour les analyser et s'en inspirer.7374## Étape 1 — Découverte7576Charger et suivre le workflow de découverte dans `workflows/01-discovery.md`.77Poser les questions une par une, en adaptant selon les réponses.78Livrable : `00-discovery.md`7980## Étape 2 — Exigences8182Construire le cahier des charges fonctionnel selon `workflows/02-requirements.md`.83Livrable : `01-cahier-des-charges-fonctionnel.md`8485## Étape 3 — PRD8687Rédiger le Product Requirements Document selon `workflows/03-prd.md`.88Livrable : `02-prd.md`8990## Étape 4 — Architecture9192Définir l'architecture technique selon `workflows/04-architecture.md`.93Livrable : `03-architecture.md`9495## Étape 5 — Génération finale9697Suivre `workflows/05-doc-generation.md` pour :98- Générer le récapitulatif `04-synthese.md`99- Valider la cohérence entre tous les documents100- Proposer les prochaines étapes101102## Validation — comment savoir qu'on a fini103104Le skill est terminé quand :1051. Les 5 documents sont générés dans `docs/projet/`1062. L'utilisateur a validé chaque phase1073. La cohérence inter-documents est vérifiée (Phase 5)1084. Les prochaines étapes sont proposées109110## Modes de profondeur111112Le skill s'adapte automatiquement :113114| Taille du projet | Profondeur | Phases |115|------------------|------------|--------|116| Petit (landing page, outil interne) | Réduite | 1-2 questions par bloc, documents courts |117| Moyen (app web, SaaS simple) | Standard | Toutes les phases, profondeur normale |118| Complexe (SaaS multi-tenant, marketplace) | Maximale | Toutes les phases en détail |119120## Templates disponibles121122Les templates dans `templates/` peuvent être utilisés indépendamment :123124| Template | Usage |125|----------|-------|126| `cahier-des-charges.md` | Structure complète d'un cahier des charges |127| `cahier-des-charges-fonctionnel.md` | Focus fonctionnel et métier |128| `prd.md` | Product Requirements Document |129| `architecture.md` | Architecture technique |130| `roles-permissions.md` | Matrice RBAC + realms + scopes |131| `data-isolation.md` | Patterns multi-tenant et isolation |132| `payments.md` | Paiements, fallback manuel, réconciliation |133134## Références135136Les fichiers dans `references/` fournissent du contexte expertise :137138- `modern-app-principles.md` — socle commun des apps modernes139- `multi-tenant-patterns.md` — isolation mono-base SaaS140- `roles-realms-scopes.md` — RBAC + ABAC + realms141- `payment-patterns.md` — fallback PSP, workflow manuel, anti-fraude142143## Erreurs courantes à éviter1441451. **Tout définir d'un coup** : le skill pose UNE question à la fois. Suivre le rythme.1462. **Ignorer les non-objectifs** : ils évitent de construire ce qui n'est pas nécessaire.1473. **Rôles vagues** : "admin" n'est pas un rôle, c'est un realm. Les rôles métier sont "manager", "support", "editor".1484. **Oublier l'isolation** : si c'est un SaaS, les données DOIVENT être isolées par tenant.1495. **Pas de KPIs** : sans mesures, on ne sait pas si le projet réussit.1506. **Architecture sans justification** : chaque choix technique doit répondre à un besoin documenté.151152## Règles générales153154- **Une question à la fois** : ne pas noyer l'utilisateur.155- **Adapter la profondeur** : un petit projet = moins de questions.156- **Toujours valider** avant de passer à la phase suivante.157- **Être concret** : proposer des options, pas seulement des questions ouvertes.158- **Documenter les décisions** : chaque choix doit être justifié.159- **Penser moderne** : multi-tenant, RBAC, offline, IA, observabilité.160- **Modulaire** : chaque phase peut être exécutée indépendamment.161- **Escalier YAGNI** : un petit projet n'a pas besoin de tous les blocs.
STIFLEUR390