joris887/exosuit

---

build

Construisez un projet à partir d'une description en langage naturel. Orchestre automatiquement la configuration, la planification et l'implémentation.

Toute communication destinée à l'utilisateur DOIT être en français simple. Pas de jargon : pas de « TDD », « sprint », « PR », « squash merge », « CI/CD », « ORM », « middleware ». Si un terme technique est inévitable, expliquez-le entre parenthèses.

Arguments

$ARGUMENTS — une description en français simple de ce qu'il faut construire (ex : « une application de gestion de tâches avec des comptes utilisateurs et des dates d'échéance »).

Phase 0 : Vérification de la configuration

Lisez le profil actuel dans CLAUDE.md. S'il n'est pas « lean », notez le profil mais continuez — /build utilise toujours un style d'exécution lean en interne, quel que soit le profil du projet.

Phase 1 : Décomposition

Affichez : « Planification de ce qui doit être construit... »

Décomposez en interne la description en stories ordonnées en utilisant la logique /ideate :

1. Identifiez les entités et fonctionnalités principales décrites
2. Divisez en étapes d'implémentation dépendantes les unes des autres
3. Classez chaque étape comme fonctionnalité, infrastructure ou test
4. Estimez la taille de chaque étape (visez des étapes qui touchent ≤5 fichiers)

N'en révélez RIEN à l'utilisateur. Pas de types de stories, pas de SPIDR, pas d'étiquettes de priorité, pas de terminologie méthodologique. Gardez la décomposition interne.

Créez un plan interne simple (non montré à l'utilisateur) :

steps:
  - summary: "Mettre en place les tables de base de données"
    type: infrastructure
    files: [...]
  - summary: "Construire les points d'accès API"
    type: feature
    files: [...]
  - summary: "Ajouter l'authentification utilisateur"
    type: feature
    files: [...]
  - summary: "Écrire les tests"
    type: testing
    files: [...]

Capture de découverte (rétroactive)

Capturez silencieusement le contexte de découverte pour les futures révisions de phase — l'utilisateur ne voit PAS ceci :

1. Déduisez l'archétype à partir de la description (classez-le parmi les 10 archétypes dans .claude/skills/discover/references/scale-guide.md)
2. Réglez l'échelle sur Quick Build
3. Générez automatiquement un docs/reference/DECISION_LOG.md minimal (copiez le modèle depuis .claude/skills/discover/assets/decision-log.md), en enregistrant toutes les décisions techniques avec une confiance : ASSUMED
4. Incluez les Stories de Transition de Phase (E0N-REVIEW : variante rapide de 3 stories — E0N-001, E0N-004, E0N-006) comme dernière étape interne
5. Enregistrez la classification dans vision/classification.md

Cela garantit que les utilisateurs de /build bénéficient du cycle de révision sans friction initiale.

Phase 2 : Exécution

Pour chaque étape dans l'ordre de dépendance :

1. Affichez la progression en français simple :

   • « Mise en place de la base de données... » / « Construction de l'API... » / « Ajout de la connexion utilisateur... » / « Écriture des tests pour vérifier que tout fonctionne... »
   • Utilisez un langage que l'utilisateur comprendra. Jamais : « Exécution de la story E01-003 (type : feature, taille : STANDARD) »

2. Exécutez en utilisant le comportement Lean du cycle de story :

   • Planifiez (léger — pas de score de confiance)
   • Construisez avec TDD lorsque c'est non trivial (exécutez les tests, n'expliquez pas la méthodologie TDD)
   • Vérifiez que les tests réussissent
   • Commitez avec le format conventionnel (n'expliquez pas les conventions de commit)

3. Prenez toutes les décisions techniques en silence :

   • Choix de framework/bibliothèque : choisissez la meilleure solution, documentez-la dans un résumé final
   • Architecture : suivez les modèles standard pour la stack détectée
   • Structure de fichiers : suivez les conventions du projet existant ou les valeurs par défaut de la stack détectée
   • Arrêtez-vous uniquement pour une ambiguïté produit réelle : « La conception pourrait aller dans deux directions : [A] ou [B]. Laquelle préférez-vous ? »
   • Ne vous arrêtez jamais pour : choix de base de données, style d'API, nommage des fichiers, framework de test, structure de dossiers

4. Gérez les échecs avec élégance :

   • Si une étape échoue après 2 tentatives, ignorez-la avec une note : « Je n'ai pas réussi à faire fonctionner [X] automatiquement. Voici ce qui doit être fait manuellement : [description] »
   • Continuez avec les étapes restantes — ne bloquez pas toute la construction

Phase 3 : Achèvement

3A. Lancement et vérification (si applicable)

Vérifiez les commandes de CLAUDE.md pour une commande dev:. Si elle est configurée :

1. Affichez : « Démarrage de votre projet... »
2. Exécutez la commande de développement en arrière-plan avec Bash en utilisant run_in_background: true
3. Attendez quelques secondes. Lisez la sortie — cherchez des URLs, des ports, des chemins de fichiers ou des messages d'état.
4. Affichez ce que la commande produit. Si elle produit une URL, mettez-la en évidence. S'il s'agit d'une CLI, affichez l'aide. Si elle démarre un serveur, affichez l'adresse.
5. Demandez : « Jetez un coup d'œil et dites-moi ce que vous en pensez ! »
6. Attendez des commentaires. Positifs → passez au rapport d'achèvement. Problèmes → corrigez et relancez.

Si aucune commande dev n'est configurée (bibliothèques, paquets, pipelines, etc.) → ignorez cette étape. Les tests ont déjà vérifié la construction.

Ne présumez pas de localhost ou d'une URL spécifique. Lisez la sortie réelle de la commande. Différents projets produisent des résultats différents.

3B. Rapport d'achèvement

Affichez un rapport d'achèvement en français simple :

## C'est fini !

### Ce qui a été construit
- [Fonctionnalité 1] : [description en français simple de ce qu'elle fait]
- [Fonctionnalité 2] : [description]
- ...

### Fichiers créés/modifiés
- `src/models/user.ts` — Modèle de données utilisateur
- `src/api/auth.ts` — Points d'accès pour la connexion et l'inscription
- ...

### Tests
- [N] tests écrits, tous réussis

### Décisions techniques prises
- **Base de données :** PostgreSQL (fiable, gratuit, fonctionne bien avec [framework])
- **Authentification :** [approche choisie] — [raison d'une ligne]
- ...

### Essayez-le
[Si la commande dev a été exécutée : "Votre projet est en cours d'exécution — voir ci-dessus"]
[Si la commande dev existe mais n'a pas été lancée : "Exécutez `[commande dev]` pour démarrer"]
[Si pas de commande dev : omettez cette section]

### Prochaines étapes
- [Suggestion 1, ex : « Ajoutez un système de paiement avec /build 'Intégration de paiement Stripe' »]
- [Suggestion 2]

Règles

• Français simple uniquement — chaque message destiné à l'utilisateur doit être compréhensible par une personne qui n'a jamais codé
• Décisions techniques silencieuses — choisissez de bonnes valeurs par défaut, documentez-les dans le rapport d'achèvement, ne demandez jamais
• Arrêtez-vous uniquement pour les questions produit — « Les utilisateurs doivent-ils pouvoir supprimer leur compte ? » est valide. « REST ou GraphQL ? » ne l'est pas.
• Les hooks de sécurité sont toujours exécutés — détection de secrets, protection git et exécution des tests se déroulent de manière invisible
• Exécution Lean — pas d'envoi d'agent qualité, pas de specs de sprint, pas de rétrospectives, pas de génération de documentation au-delà de ce qui est nécessaire pour travailler
• Échecs élégants — les étapes échouées sont notées, pas fatales. La construction continue.
• Une seule session — la première version de /build se termine en une seule session. Les constructions multi-sessions sont un travail futur.