khalilbenaz/claude-skills-collection/project-kickstart

Project Kickstart

Produit un Project Brief d'une page, actionnable, adapté au type de projet (perso, side project, pro, tech, client).

Workflow en 8 étapes

1. Collecter le contexte minimal

Avant tout, poser ces 3 questions (en une seule fois) :

1. Quel est l'objectif principal en 1 phrase ?
2. Qui sont les parties prenantes clés (décideur, équipe, client) ?
3. Y a-t-il une date butoir ou contrainte critique ?

Ne pas structurer avant d'avoir ces réponses.

2. Formuler la Vision (Problem Statement)

Format : [Pour] <utilisateur> [qui] <problème>, <nom du projet> est un <type de solution> [qui] <bénéfice principal>.

Exemple concret :

Pour l'équipe support qui perd du temps sur les tickets redondants,
BacklogBot est un agent IA qui classe et répond automatiquement
aux tickets de niveau 1 — réduisant le temps de traitement de 60 %.

Critère de validation : si la phrase contient "nous", elle est trop floue. Reformuler.

3. Délimiter le Périmètre (Scope)

Toujours produire un tableau IN / OUT :

Règle : tout ce qui n'est pas explicitement IN est OUT par défaut.

4. Définir les Livrables

Liste numérotée, chaque livrable doit être vérifiable (pas "une bonne appli", mais "API déployée sur staging avec 95 % uptime mesuré").

Exemple :

1. Spécification fonctionnelle signée (J+5)
2. Prototype cliquable Figma validé par le client (J+15)
3. API v1 déployée en staging (J+30)
4. Documentation technique OpenAPI (J+35)
5. Recette utilisateur passée à 0 bug bloquant (J+45)

5. Roadmap avec Milestones

Utiliser des phases plutôt que des semaines flottantes :

Phase 0 — Cadrage      : J0  → J+5   (brief validé, stack choisie)
Phase 1 — Foundation   : J+5  → J+20  (setup infra, auth, CI/CD)
Phase 2 — Core MVP     : J+20 → J+40  (features critiques)
Phase 3 — Stabilisation: J+40 → J+50  (tests, perf, sécurité)
Phase 4 — Go-live      : J+50          (déploiement prod, monitoring)

Pour les projets tech : créer les milestones directement dans le repo si demandé :

gh milestone create "Phase 1 — Foundation" --due-date 2026-07-15
gh milestone create "MVP Go-live" --due-date 2026-08-30

6. Ressources et Stack

Matrice minimale :

Pour les projets solo : indiquer les outils et le temps hebdo disponible.

7. Risques et Mitigations

Format : 3 à 5 risques maximum, classés par probabilité × impact.

8. Critères de Succès (DoD Projet)

Définir des métriques mesurables, pas des intentions :

- Temps de réponse API P95 < 200 ms en prod
- Couverture de tests >= 80 %
- 0 vulnérabilité critique (OWASP Top 10) au go-live
- NPS client >= 7/10 à 30 jours post-lancement
- Coût infra mensuel <= budget validé ± 15 %

Output : Project Brief (template)

# Project Brief — [Nom du projet]
**Date :** YYYY-MM-DD | **Owner :** [nom] | **Version :** 1.0
 
## Vision
[1 phrase Problem Statement]
 
## Périmètre
**IN :** [liste]
**OUT :** [liste]
 
## Livrables & Dates
[liste numérotée avec dates]
 
## Roadmap
[phases avec jalons]
 
## Ressources
[matrice]
 
## Top 3 Risques
[tableau]
 
## Critères de succès
[liste mesurable]
 
## Prochaine action immédiate
> [1 seule action concrète à faire dans les 24h]

Anti-patterns / Pièges à éviter

• Big Bang scope : tout mettre en v1. Couper sans pitié — une feature non livrée vaut mieux qu'une feature boguée.
• Dates sans buffer : prévoir systématiquement 20 % de marge sur chaque phase.
• Livrables vagues : "application fonctionnelle" n'est pas un livrable. Toujours une condition de vérification observable.
• Risques sans owner : chaque risque doit avoir une personne responsable de la mitigation.
• Brief non signé : pour un projet client, pas de démarrage sans validation écrite du brief (email suffit).
• Stack choisie avant le périmètre : la technologie découle du besoin, jamais l'inverse.

Critères d'adaptation selon le contexte