---
description: Bootstrap a new Godot project from vision to deliverables and structure
---
# /init — Bootstrap projet Godot

> **Synonymes** : init, initialiser, bootstrap, nouveau projet, new project, commencer, start, démarrer, reprendre, resume, setup

Tu es un product owner + architecte. Ton rôle : transformer une idée en projet structuré prêt à implémenter.

## Entrée

Vérifier si le projet existe déjà :
- `project.godot` présent → projet existant, lire état
- Absent → nouveau projet

Si projet existant, lire :
- `GAME_PLAN.md`, `CHECKPOINT.md`, `progress.txt`
- `deliverables/*.md` pour comprendre où on en est
- `references/index.md` pour les patterns établis

---

## Phase 1 : EXPERIENCE (conversationnel)

Questions à poser :
1. C'est quoi le feeling visé ? (pas les features, le RESSENTI)
2. Qui est la cible ? Contexte d'usage ?
3. Un moment "wow" que tu veux créer ?

**Output mental** : pitch en 2-3 phrases

---

## Phase 2 : GAMEPLAY LOOP (conversationnel)

Questions à poser :
1. Décris la séquence de moments du splash screen au game over
2. Quels écrans sont nécessaires ? (liste)
3. Comment on passe d'un écran à l'autre ?

**Output** : tableau des écrans/moments

| Moment | Écran | Transition depuis | Transition vers |
|--------|-------|-------------------|-----------------|
| Boot | Splash | - | Menu |
| Menu | MainMenu | Splash, GameOver | Gameplay |
| ... | ... | ... | ... |

### 2b. Game Sequence (optionnel ici, obligatoire avant le build)

Si le user est prêt, proposer de formaliser le flow en YAML :
→ `/godot-sequence`

Sinon, noter dans GAME_PLAN.md : "Séquence à définir avant construction."

---

## Phase 3 : VERTICAL SLICE (conversationnel)

### 3a. Source de vérité

**Si un GDD/design doc existe** (fourni par le user, fichier dans le projet, ou contenu collé) :
- Le GDD est la source de vérité pour le découpage des livrables
- Ses phases et livrables sont repris **verbatim** — pas réinterprétés, pas atomisés
- Les deliverables = les bullet points du GDD, pas une traduction technique

**Si pas de GDD** → passer aux questions ci-dessous.

### 3b. Questions

1. Qu'est-ce qui prouve que l'expérience fonctionne ?
2. Quels moments sont essentiels pour le vertical slice ?
3. Qu'est-ce qu'on coupe pour la v0 ?

**Output** : scope vertical slice (max 3 mécaniques, max 5 écrans)

---

## Phase 4 : STRUCTURE (exécution)

Après validation des 3 phases, exécuter :

### 4a. Créer GAME_PLAN.md

Utiliser le format de `/godot-plan` :
- Vision (feeling, genre, référence, public, input)
- Mécaniques core (max 3)
- Gameplay loop (tableau des moments)
- Vertical slice scope

### 4b. Configurer les display defaults

Appliquer via `godot_project_settings` (action=set) :

| Clé | Valeur | Note |
|-----|--------|------|
| `display/window/size/viewport_width` | `1920` | Résolution interne |
| `display/window/size/viewport_height` | `1080` | Résolution interne |
| `display/window/size/window_width_override` | `1920` | Taille fenêtre |
| `display/window/size/window_height_override` | `1080` | Taille fenêtre |
| `display/window/stretch/mode` | `canvas_items` | Scaling |
| `display/window/stretch/aspect` | `expand` | Ratio libre |
| `display/window/size/resizable` | `true` | Fenêtre redimensionnable |

**Variante pixel art** — si le user mentionne "pixel art", "low-res", "rétro", "retro" :
- `viewport_width/height` = résolution pixel (320×180, 384×216, etc.)
- `window_width_override/height_override` = 1920×1080 (ou multiple entier du viewport)
- `stretch/mode` = `viewport` (pas canvas_items)
- `stretch/aspect` = `keep`
- Activer `rendering/textures/canvas_textures/default_texture_filter` = `0` (Nearest)

### 4c. Créer structure dossiers

Appeler mentalement `/godot-architecture` pour générer :
```
core/
entities/
mechanics/
data/
deliverables/
references/
```

Via MCP :
- `godot_write_script` pour les dossiers core (event_bus.gd, game_state.gd)
- `godot_project_settings` pour enregistrer les autoloads

### 4d. Créer deliverables/

#### Règles de découpage

1. **Par verbe joueur, jamais par composant technique** — "Déplacement + Glitch-Step" (ce que le joueur FAIT) et non "01 Movement, 05 Dash, 06 Chains" (ce que le code EST)
2. **GDD = source de vérité** — si un GDD définit des livrables Phase 1, les reprendre 1:1. Ne pas atomiser, ne pas réinterpréter
3. **Chaque livrable embarque son juice** — les VFX, SFX, screenshake, particles liés à une mécanique font PARTIE de cette mécanique. Pas de deliverable "VFX Core" ou "SFX Core" séparé, sauf si le GDD le définit explicitement comme tel. Un dash sans son implosion visuelle et son crépitement sonore n'est pas un dash — c'est un déplacement technique
4. **Chaque livrable est testable avec son feeling** — si on ne peut pas jouer le livrable et RESSENTIR quelque chose, le découpage est mauvais
5. **Chaque livrable produit des modules réutilisables** — le code spécifique au jeu est du câblage, mais les composants produits (MovementComponent, SpawnSystem, ParrySystem, BulletTimeManager...) doivent être portables. Lister explicitement les modules dans chaque deliverable. Un module = script autonome avec config @export, sans dépendance hardcodée au jeu

#### Template

Un fichier .md par livrable identifié :

```markdown
# Livrable : {nom}

## Status
pending | in_progress | completed

## Description
{Ce que c'est — en termes de verbe joueur/feeling, pas de composant}

## Feeling cible
{Qu'est-ce que le joueur doit RESSENTIR quand ce livrable marche}

## Modules produits (réutilisables)
- **{ModuleName}** — {description courte, config @export, pas de dépendance jeu}

## Requirements
- [ ] Mécanique : {requirement}
- [ ] Juice : {VFX/SFX/feedback lié}

## Acceptance Criteria
- [ ] Critère 1
- [ ] Critère 2

## Dependencies
- {Autre livrable si applicable}

## Files
- {Fichiers à créer/modifier}
```

### 4e. Créer data/ (si valeurs numériques identifiées)

Si des valeurs numériques sont apparues pendant la conversation :
- Créer `data/` avec les fichiers appropriés
- Exemple : `data/player.yaml`, `data/enemies.yaml`, `data/levels.yaml`
- Format libre, 1 fichier par domaine

### 4f. Créer references/index.md

```markdown
# Références projet

Ce fichier est chargé dans CLAUDE.md. Toutes les conventions ici sont appliquées automatiquement.

## Spacing
(vide — se remplit en travaillant)

## Colors
(vide)

## Components
(vide)

## Conventions
(vide)
```

### 4g. Créer CHECKPOINT.md

```markdown
# Checkpoint — {Project Name}

> Last update: {date}

## Current State
- Phase: {INIT | BUILDING | POLISHING}
- Focus: {livrable en cours}

## Completed
- {liste}

## In Progress
- {liste}

## Next
- {liste}

## Blockers
- {liste ou "None"}

## References Added
- {liste des patterns ajoutés depuis dernier checkpoint}
```

### 4h. Mettre à jour CLAUDE.md projet

Ajouter :
- Lien vers `references/index.md`
- Liste des commandes disponibles
- Instruction "Claude utilise ces commandes automatiquement"

---

## Output final

```
✓ Projet {name} initialisé

Structure créée :
  display/        — 1920×1080, canvas_items, expand
  core/           — EventBus, GameState
  entities/       — (vide)
  mechanics/      — (vide)
  data/           — (vide)
  deliverables/   — {N} livrables définis
  references/     — index.md

Fichiers générés :
  GAME_PLAN.md    — Vision + mécaniques + gameplay loop
  CHECKPOINT.md   — État initial
  CLAUDE.md       — Mis à jour avec références

→ Prochain : /deliverable {premier_livrable}
→ Suggestion : /godot-sequence pour définir le flow précis avant de construire
```

## See also

| Skill | Quand l'utiliser |
|-------|-----------------|
| `/godot-plan` | Plan seul sans bootstrap complet |
| `/godot-sequence` | Étape suivante — formaliser le flow après le plan |
| `/godot-architecture` | Scaffolding technique après la séquence |
| `/checkpoint` | Sauvegarder l'état après le bootstrap |
