Migrer la disposition

Aperçu

Lupstream agent-skills conserve les fichiers de travail à la racine du projet. L'équipe les conserve dans .claude-work/ (voir la table des chemins dans les surcharges de l'équipe). Cette compétence déplace un projet en cours vers la disposition de l'équipe en un seul commit. Chaque fichier conserve son historique Git. Les cases à cocher des tâches suivent les fichiers, donc le travail continue là où il s'est arrêté.

L'argument est le <id> pour les fichiers de planification et de tâches, par exemple /agent-skills-jksim:migrate-layout fl-debug.

Quand l'utiliser

Un projet a SPEC.md, tasks/plan.md, tasks/todo.md ou CONSTRAINTS.md à sa racine.
Un projet a à la fois des fichiers de travail racine et .claude-work/.

Ne pas l'utiliser pour un nouveau projet. L'étape de spécification écrit dans .claude-work/ dès le départ.

Processus

1. Vérifier l'état de départ

Arrêter et informer l'utilisateur lorsque l'une de ces conditions est vraie :

Le dossier n'est pas un dépôt git.
git status --porcelain --untracked-files=no montre des modifications sur des fichiers suivis. Demander à l'utilisateur de les commiter ou de les stash d'abord. Les fichiers non suivis peuvent rester : l'étape 8 stage avec git add -u, qui ne les ajoute jamais.
git check-ignore -q .claude-work/spec/SPEC.md réussit. Vérifier un chemin de fichier : un motif tel que .claude-work/ ne correspond pas au dossier avant qu'il n'existe. Les projets consommateurs commitent .claude-work/.

2. Trouver les anciens fichiers

Regarder uniquement ces chemins, relatifs à la racine du projet :

Ancien chemin	Chemin d'équipe
`SPEC.md`, `docs/SPEC.md`	`.claude-work/spec/SPEC.md`
`SPEC-<module>.md`	`.claude-work/spec/SPEC-<module>.md`
`CAPABILITY-MAP.md`	`.claude-work/spec/CAPABILITY-MAP.md`
`tasks/plan.md`	`.claude-work/tasks/plan-<id>.md`
`tasks/todo.md`	`.claude-work/tasks/todo-<id>.md`
`CONSTRAINTS.md`	`.claude-work/docs/CONSTRAINTS.md`
`docs/ideas/<name>.md`	`.claude-work/docs/ideas/<name>.md`
`docs/intent/<topic>.md`	`.claude-work/docs/intent/<topic>.md`
`docs/decisions/`	Reste. Demander (voir étape 4)

Ne pas toucher à spec/. RSpec et autres dispositions de test l'utilisent.

Utiliser uniquement les fichiers suivis par git (git ls-files). git mv échoue sur les autres fichiers. Nommer tout fichier non suivi ou ignoré et demander à l'utilisateur.

Lorsqu'aucun ancien fichier n'existe, informer l'utilisateur qu'il n'y a rien à migrer. Arrêter.

3. Obtenir le `<id>`

Utiliser l'argument. Sans argument, suggérer un id court en kebab-case à partir du nom du projet et demander à l'utilisateur. Ignorer cette étape lorsqu'il n'y a pas de tasks/plan.md ou tasks/todo.md.

4. Afficher le plan et attendre l'approbation

Afficher un tableau : ancien chemin, nouveau chemin. Ensuite, lister chaque conflit et demander à l'utilisateur :

La cible existe : un fichier se trouve déjà au chemin d'équipe. Ne pas déplacer ce fichier. Demander quoi faire.
Deux spécifications : à la fois SPEC.md et docs/SPEC.md existent. Demander laquelle est la spécification.
Autres fichiers dans tasks/ : ne déplacer que plan.md et todo.md. Nommer les autres fichiers.
docs/decisions/ existe : la valeur par défaut est de le conserver, car un projet garde son propre dossier ADR. Le déplacer vers .claude-work/docs/adr/ uniquement si l'utilisateur le demande.

Ne rien déplacer tant que l'utilisateur n'a pas approuvé le tableau.

5. Déplacer avec `git mv`

Exécuter git mv <ancien> <nouveau> pour chaque fichier. Créer d'abord les dossiers cibles (mkdir -p). Ne jamais copier et supprimer : git mv conserve l'historique. Si tasks/ est maintenant vide, exécuter rmdir tasks.

6. Corriger les références vivantes

Rechercher également les noms de fichiers nus, car un fichier déplacé peut nommer son partenaire sans dossier : git grep -n -E '(^|[^-/A-Za-z0-9_])(plan|todo)\.md'. Exemple : "détail dans todo.md" dans le plan devient "détail dans todo-.md".

Une référence vivante indique au lecteur ou à l'agent où se trouve le fichier maintenant. La modifier :

CLAUDE.md : "SPEC.md : spécification approuvée" devient ".claude-work/spec/SPEC.md : spécification approuvée".
README.md : [SPEC.md](SPEC.md) devient [SPEC.md](.claude-work/spec/SPEC.md).
Un lien relatif dans un fichier déplacé : ../SPEC.md dans l'ancien tasks/plan.md devient ../spec/SPEC.md dans .claude-work/tasks/plan-<id>.md.
La ligne de pointeur de contraintes dans CLAUDE.md.
Autres liens relatifs dans chaque fichier déplacé. Un fichier déplacé est à une nouvelle profondeur, donc un lien vers un fichier qui n'a pas bougé se brise aussi. Exemple : [x](src/a.kt) dans le SPEC-foo.md racine devient [x](../../src/a.kt) dans .claude-work/spec/SPEC-foo.md.

Un enregistrement indique ce qui s'est passé à un moment passé. Le laisser tel quel :

Une entrée de tâche terminée : "Fichiers : README.md, SPEC.md".
Un journal des modifications, une note de révision ou un message de commit.

Lorsqu'on n'est pas sûr, laisser le texte et le lister à l'étape 7.

7. Afficher le résultat

Afficher git status, le diff des références modifiées, et une liste des références aux anciens chemins qui n'ont pas été modifiées, avec la raison pour chacune.

8. Commiter une fois

git mv a déjà stagé les déplacements. Stager les références modifiées avec git add -u. Ne pas utiliser git add -A : cela pourrait ajouter des fichiers non liés. Commiter avec le message Déplacer les fichiers de travail vers .claude-work. Ne pas pousser.

Si un hook rejette le commit, arrêter et le signaler. Ne pas utiliser --no-verify.

9. Signaler l'étape suivante

Informer l'utilisateur des fichiers qui ont été déplacés et de ceux qui sont restés. Si .claude-work/docs/VOCABULARY.md n'existe pas, dire que la prochaine étape de spécification le créera (règle 2). Ne pas le créer maintenant.

Rationalisations courantes

Rationalisation	Réalité
"Copier est plus simple que `git mv`."	Une copie perd l'historique du fichier. Les réviseurs et `git log --follow` en ont besoin.
"Je vais mettre à jour chaque mention de `SPEC.md`."	Les enregistrements décrivent le passé. Les modifier réécrit l'histoire.
"L'arbre n'est qu'un peu sale."	Le travail non commité se retrouve dans le commit de migration. Demander d'abord à l'utilisateur.
"Le plan est évident, donc je vais sauter l'approbation."	L'utilisateur décide du `<id>` et de chaque conflit. Attendre.

Drapeaux rouges

git log --follow ne montre aucun historique avant le commit de migration.
Une entrée de tâche terminée ou un journal des modifications nomme un chemin d'équipe qui n'existait pas à ce moment-là.
spec/ ou docs/decisions/ déplacé sans l'approbation de l'utilisateur.
Plus d'un commit, ou un push.

Vérification

Chaque ancien fichier est à son chemin d'équipe. Aucun ancien fichier n'est laissé à la racine, sauf ceux que l'utilisateur a choisi de conserver.
git log --follow <nouveau chemin> montre l'ancien historique.
Les références vivantes pointent vers les chemins d'équipe. Les enregistrements sont inchangés.
Les cases à cocher des tâches sont inchangées.
Un commit, Déplacer les fichiers de travail vers .claude-work. git status est propre. Rien n'est poussé.

jksim/agent-skills-jksim

Qu'est-ce que agent-skills-jksim ?

Demander à votre IA préférée

Documentation