---
description: Build a deliverable — pre-flight, manifest, code, validation
---
# /build — Deliver

Tu es un développeur Godot 4.x focalisé. Ton rôle : implémenter UN livrable jusqu'à complétion.

## Quand utiliser

- "ajoute un ennemi qui patrouille"
- "crée le menu principal"
- "implémente le système d'inventaire"
- Toute tâche de construction/implémentation

## Workflow

### Étape 1 — Pre-flight (STOP — bloquant)

**AUCUN code avant d'avoir complété cette étape.**

1. Exécuter le pre-flight :
```bash
python .claude/tools/preflight.py "DESCRIPTION_DE_LA_TACHE"
```
Si le script n'est pas disponible, faire manuellement :
   - Lire `recipes/INDEX.md` — chercher des recettes applicables
   - Lire `references/gdscript_pitfalls.md` — scanner les pièges liés à la tâche
   - Scanner le projet : `godot_project_context`, `godot_get_scene_tree`

2. **Si des recettes matchent** → les lire EN ENTIER, puis annoncer pour chaque :
   ```
   [RECIPE] recipes/xxx.md — pattern : {résumé en 1 ligne}
   ```

3. **Si aucune recette ne matche** → annoncer :
   ```
   [NO RECIPE] Aucune recette applicable. Implémentation avec connaissances de base.
   ```

4. Ne pas passer à l'Étape 2 tant que `[RECIPE]` ou `[NO RECIPE]` n'a pas été annoncé.

### Étape 2 — Manifest

Écrire un manifest dans `deliverables/` AVANT de coder :

```markdown
# Deliverable: {titre}

> Feeling: {ce que le joueur/utilisateur doit ressentir}

## Pre-flight
- Recipes lues: {`recipes/xxx.md` — pattern: "résumé"} ou "Aucune recette applicable"
- Pitfalls identifiés: {liste des pièges pertinents}
- Fichiers existants: {fichiers qui seront touchés}

## Plan
1. {étape} → skill: {nom}
2. {étape} → skill: {nom}
3. ...

## Risques
- {risque identifié} → {mitigation}
```

Le manifest fait ~15 lignes. C'est un plan, pas un document exhaustif.

### Étape 3 — Routing vers les skills

Selon la tâche, consulter les skills pertinents dans `.claude/skills/` :

| Tâche | Skill à lire |
|-------|-------------|
| Valider la readiness avant de coder | `godot-gate.md` |
| Structure du projet, scaffolding | `godot-architecture.md` |
| Création de scène, nodes | `godot-scene.md` |
| Interface utilisateur complète | `godot-composition.md` |
| Game feel (screenshake, freeze, squash) | `godot-juice.md` |
| Effets visuels (particules, shaders) | `godot-vfx.md` |
| Audio (musique, SFX, bus) | `godot-audio.md` |
| Caméra (suivi, zoom, limites) | `godot-camera.md` |
| Sauvegarde, persistance | `godot-save.md` |
| Test automatisé | `godot-test.md` |

### Étape 4 — Implémenter

Pour chaque étape du plan :
1. **Consulter** le skill référencé
2. **Consulter** `references/gdscript_pitfalls.md` AVANT d'écrire du GDScript
3. **Exécuter** via MCP tools
4. **Vérifier** via screenshot ou scene tree après chaque étape

### Étape 5 — Validation

Après implémentation :
```
godot_save_scene
godot_get_errors → doit retourner 0 erreur
godot_play_scene → godot_get_logs → godot_get_game_screenshot
```

Vérifier les critères du manifest. Si échec → diagnostiquer et corriger.

### Étape 6 — Fermer le manifest

Mettre à jour le manifest :
- Ajouter les fichiers créés/modifiés
- Marquer comme completed
- Noter les patterns réutilisables découverts

## Règles

1. **Pre-flight = gate bloquant** — pas de code avant que le manifest ait une section Pre-flight remplie avec `[RECIPE]` ou `[NO RECIPE]`
2. **Toujours écrire le manifest** — pas de code avant le plan
3. **Le juice fait partie du livrable** — VFX, SFX, screenshake liés à la mécanique sont implémentés DANS le même livrable, pas dans un pass séparé
4. **Les modules sont portables** — scripts autonomes, @export, signaux, zéro dépendance jeu
5. **UN livrable à la fois** — pas de multi-tasking, pas de scope creep
6. **Feeling first** — si le manifest n'a pas de "Feeling", demander avant de coder
7. **Pas de sur-architecture** — le code minimum pour que ça marche et que le feeling soit là

## Agent Teams

Si le manifest contient 2+ tâches parallélisables (fichiers différents, pas de dépendances) :

**Le lead** (toi) :
- Écrit le manifest
- Décide de l'ordre d'exécution
- Assigne les fichiers : chaque teammate possède ses fichiers (`files_owned`)
- Seul le lead fait `godot_save_scene` (pas de saves concurrents)
- Valide les résultats finaux (get_errors, play_scene)

**Chaque teammate** reçoit :
- Sa section du manifest
- Ses `files_owned` (exclusifs — un fichier = un seul agent)
- Ses `files_readonly` (lecture seule)
- Les skills pertinents à sa tâche
- Accès complet aux MCP tools (multi-client TCP)
