---
description: Focus work on completing a specific project deliverable
---
# /deliverable <nom> — Focus sur un livrable

> **Synonymes** : deliverable, livrable, feature, fonctionnalité, tâche, task, focus, implémenter, implement, construire, build

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

## Entrée

1. Lire `deliverables/{nom}.md`
2. Vérifier les dépendances (autres livrables requis)
3. Lire `references/index.md` pour appliquer les patterns

Si le livrable n'existe pas → proposer de le créer avec le template :

```markdown
# Livrable : {nom}

## Status
pending

## Description
{À remplir}

## Requirements
- [ ] {À définir}

## Acceptance Criteria
- [ ] {À définir}

## Dependencies
- None

## Files
- {À déterminer}
```

---

## Process

### 1. Afficher le brief

```
## Livrable : {nom}

Status: {status}
Dependencies: {liste ou "None"}

Requirements:
- [ ] {req1}
- [ ] {req2}

Acceptance Criteria:
- [ ] {crit1}
- [ ] {crit2}
```

### 1b. Pre-flight recettes (STOP — bloquant)

Avant de coder quoi que ce soit :

1. Exécuter `python .claude/tools/preflight.py "DESCRIPTION_DU_LIVRABLE"` ou manuellement checker `recipes/INDEX.md`
2. **Si des recettes matchent** → les lire EN ENTIER, annoncer :
   ```
   [RECIPE] recipes/xxx.md — pattern : {résumé en 1 ligne}
   ```
3. **Si aucune recette** → annoncer :
   ```
   [NO RECIPE] Aucune recette applicable.
   ```
4. Ne pas passer à l'étape suivante sans annonce `[RECIPE]` ou `[NO RECIPE]`.

### 2. Vérifier les dépendances

Si des dépendances ne sont pas `completed` :
```
⚠ Dépendances non résolues :
- {livrable_dep} — status: {status}

Options :
1. Travailler d'abord sur {livrable_dep}
2. Ignorer et continuer (risqué)
```

### 3. Proposer le plan d'implémentation

Lister les étapes avec les skills à utiliser. **Chaque étape inclut la mécanique ET son juice** — pas de pass séparé.

Exemple gameplay :

| Étape | Skill | Description |
|-------|-------|-------------|
| 1 | `/godot-scene` | Scène + nodes + collisions |
| 2 | (code) | Mécanique core + VFX/SFX liés |
| 3 | `/godot-juice` | Screenshake, hitstop, polish feedback |
| 4 | `/godot-test` | Validation feeling via play + logs |

Exemple UI :

| Étape | Skill | Description |
|-------|-------|-------------|
| 1 | `/godot-composition` | Layout et structure |
| 2 | `/godot-scene` | Créer les composants |
| 3 | `/godot-behavior` | États, transitions, feedback |
| 4 | `/godot-theme` | Appliquer le style |

### 4. Implémenter step by step

Pour chaque étape :
1. **Exécuter** via MCP tools
2. **Vérifier** via screenshot ou scene tree
3. **Proposer référence** si pattern réutilisable détecté

### 5. Valider les acceptance criteria

Cocher chaque critère avec preuve :
```
✓ Critère 1 — vérifié via screenshot
✓ Critère 2 — vérifié via inspect_node
✗ Critère 3 — en échec, raison: {x}
```

### 6. Mettre à jour le livrable

Modifier `deliverables/{nom}.md` :
- `Status: completed`
- `Files:` liste des fichiers créés/modifiés
- Requirements cochés

### 7. Proposer checkpoint

```
Livrable {nom} terminé.

Fichiers modifiés :
- {liste}

Patterns détectés :
- {spacing_value} → ajouter aux références ?
- {color_value} → ajouter aux références ?

→ Lancer /checkpoint pour snapshot ?
→ Prochain livrable suggéré : {next}
```

---

## Règles strictes

1. **UN livrable à la fois** — pas de multi-tasking
2. **Pas de scope creep** — si nouveau besoin découvert, créer un nouveau livrable
3. **Références proposées, pas forcées** — l'utilisateur décide
4. **Preuves visuelles** — chaque acceptance criteria validé avec screenshot ou inspect
5. **État persisté** — toujours mettre à jour le fichier .md avant de terminer
6. **Le juice fait partie du livrable** — VFX, SFX, screenshake, particles liés à la mécanique sont implémentés DANS le même livrable, pas dans un pass séparé. Un dash sans implosion visuelle et crépitement sonore n'est pas terminé. Si le deliverable a une section "Feeling cible", le feeling doit être vérifiable à la fin
7. **Les modules sont portables** — si le deliverable liste des "Modules produits", chaque module doit être un script autonome avec config @export, communicant par signaux, sans dépendance hardcodée au jeu. Vérifier avant de marquer completed : le module pourrait-il être copié dans un autre projet et fonctionner ?

---

## Gestion des blocages

Si bloqué pendant l'implémentation :

```
⚠ Blocage détecté

Problème : {description}
Tentatives : {ce qui a été essayé}

Options :
1. /godot-debug pour diagnostic
2. Créer un nouveau livrable pour résoudre le problème
3. Marquer comme bloqué et passer au suivant
```

Mettre à jour le livrable avec :
```markdown
## Blockers
- {description du blocage}
```

## See also

| Skill | Quand l'utiliser |
|-------|-----------------|
| `/checkpoint` | Sauvegarder l'état après avoir complété un livrable |
| `/references` | Consulter/ajouter des patterns pendant l'implémentation |
| `/godot-scene` | Si le livrable implique de construire une scène |
