lucaszb-orla/lucas-setup

Lucas Setup

Préparer les fondations d'un projet sans choisir silencieusement un produit, une stack ou une architecture. Appliquer les templates inclus et n'adapter que ce que le contexte réel justifie.

Flux

1. Inspecter le répertoire cible, les fichiers d'instruction, les manifestes et l'état de Git.
2. Déterminer si le projet est web, Apple ou multiplateforme d'après la demande et les fichiers existants.
3. Si le choix de plateforme ou de stack modifie matériellement le résultat et ne peut être découvert, poser une question courte avant de créer du code.
4. Appliquer les fichiers de base :
   • Dans un répertoire nouveau ou sans fichiers conflictuels, exécuter python3 <skill-dir>/scripts/apply_setup.py --target <répertoire> --platform <web|apple|both>.
   • Sur un projet contenant AGENTS.md, CLAUDE.md ou PROJECT_CONTEXT.md, ne pas écraser. Lire les deux, consolider les règles compatibles et signaler les conflits réels.
5. Remplir PROJECT_CONTEXT.md avec des faits observés. Ne pas laisser d'exemples qui ressemblent à des décisions.
6. Créer ou adapter le projet seulement si la demande inclut du scaffolding ou de l'implémentation.
7. Configurer le Conductor uniquement sur demande ou si le projet est préparé pour lui.
8. Valider les fichiers, les commandes, Git et l'absence de secrets.

Appliquer les assets

Utiliser scripts/apply_setup.py pour une copie déterministe et sans écrasement. Le script :

• crée le répertoire cible si nécessaire ;
• copie AGENTS.md, CLAUDE.md et PROJECT_CONTEXT.md ;
• copie uniquement les directives des plateformes choisies ;
• refuse tout fichier existant avec un contenu différent ;
• accepte --dry-run ;
• accepte --conductor pour une plateforme unique.

Pour un projet Apple :

python3 <skill-dir>/scripts/apply_setup.py \
  --target /chemin/du/projet \
  --platform apple \
  --conductor

Pour un projet web :

python3 <skill-dir>/scripts/apply_setup.py \
  --target /chemin/du/projet \
  --platform web \
  --conductor

Après la copie, éditer PROJECT_CONTEXT.md avec apply_patch.

Décisions de projet

• Ne pas choisir de framework, base de données, architecture, bundle ID, deployment target ou fournisseur sans preuve dans la demande ou le dépôt.
• Préférer la stack et le gestionnaire déjà adoptés.
• Dans un projet réellement vide, offrir une recommandation courte basée sur le produit, mais séparer la recommandation de la décision confirmée.
• Ne pas ajouter de dépendances ou de services juste pour compléter un template.
• Ne pas modifier les fichiers générés lorsqu'il existe une source déclarative.

Préférences obligatoires

• Ne pas utiliser de tiret long (em dash) dans l'interface, la documentation, les commentaires ou le contenu exporté.
• Ne pas ajouter de bordure décorative à l'onboarding.
• Lorsqu'il y a un élément artistique principal dans l'onboarding, le conserver comme seul point fort matériel.
• Préserver les modifications de l'utilisateur et garder un champ d'action chirurgical.
• Faire des commits petits et atomiques après avoir validé des incréments pertinents.
• Mettre à jour la mémoire du projet lorsqu'une décision ou un gotcha durable survient.

Conductor

Avant de créer une configuration, investiguer les commandes réelles de setup, d'exécution et de test.

• Utiliser .conductor/settings.toml pour la configuration partagée.
• Utiliser .conductor/settings.local.toml pour les préférences locales du dépôt.
• Utiliser CONDUCTOR_PORT sur les serveurs configurables.
• Marquer l'exécution comme non concurrente lorsque la base de données, le port ou le service local ne peut être isolé.
• Ne pas créer de worktree imbriqué dans un workspace du Conductor.
• Traiter les TOML dans assets/conductor/ comme des points de départ, jamais comme des faits du projet.

Git et GitHub

• Initialiser Git et créer un dépôt distant uniquement lorsque la demande autorise ces actions.
• Avant le premier commit, valider le diff et chercher des secrets.
• Utiliser la branche par défaut main, sauf convention existante.
• Ne pas renommer la branche active sans demande explicite.
• Ne pas publier le projet comme public lorsque la visibilité n'est pas claire.

Vérification

Confirmer :

• AGENTS.md, CLAUDE.md et PROJECT_CONTEXT.md existent et sont cohérents ;
• seules les directives de plateforme applicables ont été ajoutées ;
• le contexte ne contient pas d'exemples traités comme des décisions ;
• les configurations du Conductor utilisent des commandes réelles ;
• les tests ou commandes étroites pertinentes passent ;
• Git ne contient ni secrets, ni artefacts, ni modifications hors du champ d'action.

Indiquer à la fin ce qui a été créé, ce qui doit être rempli et toute validation non exécutée.