samyak-here/project-bootstrap

Project Bootstrap

Un orchestrateur léger. Cette compétence ne contient pas d'autres compétences — elle charge la bonne compétence au bon moment, exécute un script déterministe pour la création de fichiers, et remplit les modèles à partir des réponses de l'utilisateur. Si une étape ci-dessous entre en conflit avec une compétence copiée, cette compétence l'emporte.

Règles de précédence — session de configuration uniquement

Cet ordre s'applique uniquement pendant la session de configuration, tant que cette compétence est active. Lorsque des instructions entrent en conflit pendant la configuration, appliquez-les dans cet ordre :

1. Cette compétence (project-bootstrap) — périmètre de configuration, règles de sécurité, règle d'arrêt.
2. Le CLAUDE.md propre au projet — tel qu'il est en cours de création.
3. La compétence de la stack — par exemple la compétence SwiftUI ou de conception pour ce type de projet.
4. La liste de contrôle du workflow — references/workflow.md, le processus par défaut.

Une fois la configuration terminée, cette compétence n'est plus active et l'ordre expire : le CLAUDE.md du projet (ainsi que ses docs) est le seul ensemble d'instructions permanent pour les sessions futures.

N'installez jamais deux frameworks de workflow concurrents (par exemple, n'installez pas à la fois un framework basé sur des spécifications lourdes et la liste de contrôle de workflow de cette compétence). Si l'utilisateur nomme explicitement un framework de workflow, utilisez celui-ci à la place de la liste de contrôle par défaut et enregistrez le choix dans docs/SETUP.md.

Règles de sécurité (jamais remplacées)

• Ne jamais écrire de secrets, clés API ou jetons dans un fichier généré, et ne jamais placer un secret côté serveur (par ex. un secret d'API bancaire) dans une application cliente.
• Ne jamais écraser un fichier existant sans l'accord de l'utilisateur (scripts/bootstrap.py refuse par défaut ; --force est uniquement opt-in, et avec --force le script sauvegarde d'abord chaque fichier dans <filename>.pre-bootstrap.bak).
• Configuration uniquement : ne commencez pas à construire des fonctionnalités produit dans cette session.

Workflow

Exécutez ces étapes dans l'ordre. Ne sautez pas d'étape.

1. Interview

Chargez references/interview.md. Posez ses questions une à la fois, et écrivez chaque réponse dans le document pertinent au fur et à mesure — ne gardez pas tout en mémoire de conversation. Si l'utilisateur répond à plusieurs questions à la fois, enregistrez chaque réponse donnée, marquez ces questions comme répondues, et continuez à partir de la première question sans réponse — ne reposez jamais une question déjà répondue. Arrêtez l'interview lorsque chaque question a une réponse ou que l'utilisateur la reporte explicitement (enregistrez les éléments reportés dans docs/STATE.md).

2. Exécuter le script

Depuis le répertoire de cette compétence :

python3 scripts/bootstrap.py \
  --project-name "<nom de l'interview>" \
  --type <ios|web|python|generic> \
  --purpose "<objectif de l'interview en une ligne>" \
  --target <chemin vers le nouveau dépôt projet> \
  --allow-placeholders

--allow-placeholders est requis ici : à ce stade, les modèles contiennent encore délibérément des jetons de remplissage {{...}} (l'étape 3 les remplit), donc le script passe la vérification avec un avertissement de jeton par fichier au lieu d'échouer. Le répertoire cible doit déjà exister (le nouveau dépôt projet) ; le script génère une erreur si la cible est manquante plutôt que de créer un chemin avec une faute de frappe — passez --create-target uniquement si l'utilisateur souhaite explicitement que le script crée ce répertoire.

Ceci crée les répertoires et rend les modèles de manière déterministe. Signalez exactement ce qui a été créé, ignoré ou écrasé — ne prétendez jamais qu'un fichier existe alors que le script ne l'a pas signalé.

3. Remplir les modèles à partir des réponses de l'interview

Remplacez les invites de remplissage restantes dans les fichiers générés par les réponses réelles : la stack et les commandes de build/test dans CLAUDE.md / AGENTS.md, le périmètre dans docs/PRD.md, les phases dans docs/ROADMAP.md, les termes du glossaire dans docs/CONTEXT.md. Gardez CLAUDE.md court — s'il dépasse ~80 lignes, déplacez les détails dans docs/ et laissez un pointeur.

4. Installer les compétences de la stack — épinglées, lire avant d'installer

Chargez la référence pour le type de projet et installez uniquement les compétences qu'elle liste :

• iOS → references/ios.md
• Web → references/web.md
• Python / générique → pas de compétence de stack par défaut ; notez ce choix dans SETUP.

Chaque compétence listée est épinglée à un SHA de commit exact dans le tableau des compétences épinglées de la référence. Installer signifie : cloner le dépôt dans .claude/skills/ du projet, puis git checkout le SHA épinglé — n'installez jamais à partir d'une branche mouvante, et ne modifiez jamais un épingle sans enregistrer le nouveau SHA.

Lire-avant-installer est obligatoire. Après le clonage, avant que l'installation soit considérée comme complète, pour chaque compétence :

1. Lisez son SKILL.md en intégralité (et notez tout ce qu'elle charge par défaut).
2. Rédigez un résumé de 2 à 3 lignes : quelles instructions cette compétence chargera dans les sessions futures.
3. Signalez tout ce qui demande un accès réseau, une utilisation d'identifiants ou des commandes destructrices. Remontez les alertes à l'utilisateur ; n'installez pas silencieusement une compétence qui demande l'un de ces éléments sans l'accord de l'utilisateur.

Enregistrez dans docs/SETUP.md, par compétence : nom, URL source exacte, SHA épinglé, date d'installation et le résumé de lecture. Ne copiez pas le contenu d'une compétence dans CLAUDE.md — la compétence reste une unité chargeable distincte.

5. Définir la règle de workflow

Écrivez la boucle par défaut de references/workflow.md dans CLAUDE.md si elle n'y est pas déjà : spéc → plan → build → revue séparée, une phase par nouvelle session, docs/STATE.md mis à jour à la fin de chaque session.

6. Vérifier — vérification fraîche, pas la sortie de l'étape 2

Exécutez la vérification maintenant, à nouveau, en mode --verify (il lit la cible telle qu'elle est actuellement et ne modifie rien) :

python3 scripts/bootstrap.py --verify --target <chemin vers le dépôt du projet>

Ne réutilisez pas la sortie de l'étape 2 — cette exécution est antérieure au remplissage de l'étape 3 et aux installations de l'étape 4. Ne pas ajouter --allow-placeholders à la commande de vérification — le script rejette cette combinaison immédiatement, car la vérification doit s'exécuter sur des fichiers remplis. --verify échoue sur tout jeton de remplissage restant dans les fichiers générés : s'il échoue sur des jetons, l'étape 3 n'était pas terminée — revenez en arrière, remplissez les jetons restants, et ré-exécutez --verify jusqu'à ce qu'il réussisse. --verify vérifie également le contenu, pas seulement les jetons : la liste hors-périmètre du PRD doit être non vide, et docs/SETUP.md doit enregistrer un SHA épinglé pour chaque compétence installée (ou indiquer qu'aucune compétence de stack n'a été installée). Aussi :

• Confirmez que .gitignore couvre les secrets pour cette stack.
• Confirmez que le projet vide/modèle se construit toujours avec la commande de build enregistrée dans CLAUDE.md (si une commande de build existe déjà).
• Relisez docs/SETUP.md : chaque compétence installée doit être listée avec son URL source, SHA épinglé, date d'installation et résumé de lecture.

7. Commit

Un seul commit, rien de plus :

chore: initial project setup

Incluez uniquement les fichiers de configuration. Si l'identité utilisateur git ou un dépôt distant n'est pas configuré, dites-le et laissez le commit à l'utilisateur — n'inventez ni l'un ni l'autre.

8. Arrêter

Montrez à l'utilisateur l'arborescence de fichiers créée et la Phase 1 de docs/ROADMAP.md. Puis arrêtez-vous. Ne commencez pas la Phase 1, ne construisez pas une fonctionnalité et ne proposez pas de "simplement démarrer le squelette" — la phase suivante appartient à une nouvelle session (voir references/workflow.md).

Échappatoire : arrêtez-vous sauf si l'utilisateur vous demande explicitement de continuer. Si c'est le cas, recommandez — une fois — que la Phase 1 se déroule toujours dans une nouvelle session, puis obéissez à l'utilisateur et continuez.

Fichiers de référence — chargement à la demande

Fichier	Charger quand
references/interview.md	Toujours — Étape 1.
references/ios.md	Le type de projet est ios.
references/web.md	Le type de projet est web.
references/workflow.md	Étape 5, et toute session ultérieure travaillant dans un dépôt bootstrapé.