<required> CRITIQUE Ajoutez les étapes suivantes à votre liste de tâches avec TodoWrite :

1. Trouvez le répertoire des worktrees.

• Vérifiez les répertoires existants avec l'outil Bash : ls -d .worktrees 2>/dev/null
• S'il n'existe pas, demandez-moi la permission de créer un répertoire .worktrees
• Si la permission est accordée, créez .worktrees.

2. Vérifiez .gitignore avant de créer un worktree avec l'outil Bash :

# Vérifiez si le modèle de répertoire est dans .gitignore
grep -q "^\.worktrees/$" .gitignore || grep -q "^worktrees/$" .gitignore

• S'il n'est pas trouvé, ajoutez la ligne appropriée à .gitignore immédiatement.

3. Créez le worktree

• Proposez un bon nom de branche en fonction de la demande.
• Créez le worktree avec l'outil Bash : git worktree add ".worktrees/$BRANCH_NAME" -b "$BRANCH_NAME"
• Accédez au chemin nouvellement créé avec l'outil Bash : cd $path

4. Détection automatique et lancement de la configuration du projet.

# Node.js
if [ -f package.json ]; then npm install; fi

# Rust
if [ -f Cargo.toml ]; then cargo build; fi

# Python
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
if [ -f pyproject.toml ]; then poetry install; fi

# Go
if [ -f go.mod ]; then go mod download; fi

• S'il n'y a pas de configuration de projet évidente, vous DEVEZ me le demander.

5. Lancez les tests pour vous assurer que le worktree est propre.

# Exemples - utilisez la commande appropriée au projet
npm test
cargo test
pytest
go test ./...

Si les tests échouent : Signalez les défaillances, demandez s'il faut continuer ou enquêter.

Si les tests réussissent : Signalez que c'est prêt.

6. Signalez l'emplacement

Nouveau répertoire de travail : <chemin-complet>
Tests réussis (<N> tests, 0 défaillances)
Toutes les commandes et tous les outils feront désormais référence à : <chemin-complet>

7. Comprenez que vous êtes désormais dans un nouveau répertoire de travail. Vos instructions avec l'outil Bash à partir de maintenant doivent faire référence au répertoire worktree, PAS à votre répertoire d'origine. C'est ABSOLUMENT CRITIQUE.

</required>

Maintenir le répertoire de travail dans le worktree

CRITIQUE : Une fois que vous créez et entrez dans un worktree, vous devez y rester pendant toute la session.

Règles :

1. Ne jamais utiliser cd .. depuis un worktree - Cela finira par vous faire sortir des limites du worktree
2. Toujours utiliser des chemins absolus pour les commandes - Utilisez npm run lint depuis le worktree, pas cd .. && npm run lint
3. Si vous devez exécuter des commandes au niveau racine, utilisez le chemin complet du worktree : <bad-example> cd .. && npm run lint </bad-example> <good-example> npm run lint # (depuis la racine du worktree) </good-example>

<good-example> cd /home/$USER/code/project/.worktrees/branch-name && npm run lint </good-example>

4. Vérifiez votre emplacement fréquemment :

pwd  # Devrait afficher .worktrees/branch-name dans le chemin
git branch  # Devrait montrer * sur votre branche de fonctionnalité, pas main

5. Si vous quittez accidentellement le worktree :

• Reconnaissez-le immédiatement (vérifiez si vous êtes sur la branche main)
• Naviguez vers : cd /chemin/complet/vers/.worktrees/votre-branche
• Vérifiez : git branch devrait afficher votre branche, pas main

Signaux d'alerte :

• Exécuter git status et voir "On branch main" alors que vous devriez être sur une branche de fonctionnalité
• Exécuter pwd et ne PAS voir .worktrees/ dans le chemin
• Toute commande cd .. depuis un worktree

Référence rapide

Erreurs courantes

Oublier la vérification de .gitignore

• Problème : Le contenu du worktree est suivi, pollue git status
• Solution : Toujours vérifier avec grep avant de créer un worktree local au projet

Supposer l'emplacement du répertoire

• Problème : Crée une incohérence, viole les conventions du projet
• Solution : Respectez la priorité : existant > CLAUDE.md > demander

Oublier l'installation du projet

• Problème : Les tests et lint échouent, cassent le projet
• Solution : Installez toujours le projet quand vous créez un worktree

Continuer avec des tests qui échouent

• Problème : On ne peut pas distinguer les nouveaux bogues des problèmes préexistants
• Solution : Signalez les défaillances, obtenez la permission explicite de continuer

Hardcoder les commandes de configuration

• Problème : Casse sur les projets utilisant des outils différents
• Solution : Détection automatique à partir des fichiers du projet (package.json, etc.)

Exemple de flux de travail

Vous : J'utilise la compétence Using Git Worktrees pour configurer un espace de travail isolé.

[Vérifiez .worktrees/ - existe]
[Vérifiez .gitignore - contient .worktrees/]
[Créez worktree : git worktree add .worktrees/auth -b feature/auth]
[Exécutez npm install]
[Exécutez npm test - 47 réussis]

Worktree prêt à myproject/.worktrees/auth
Tests réussis (47 tests, 0 défaillances)
Prêt à implémenter la fonctionnalité d'authentification

Signaux d'alerte

Ne jamais :

• Créer un worktree sans vérification .gitignore (local au projet)
• Ignorer la vérification de test de base
• Continuer avec des tests qui échouent sans demander
• Supposer l'emplacement du répertoire quand c'est ambigu
• Ignorer la vérification CLAUDE.md

Toujours :

• Respecter la priorité des répertoires : existant > CLAUDE.md > demander
• Vérifier .gitignore pour le projet local
• Détection automatique et lancement de la configuration du projet
• Vérifier que la ligne de base des tests est propre