Ces derniers temps, beaucoup de « vibe coding », surtout quand le quota est sur le point d’être réinitialisé : à ce moment-là, on balance une tonne de tâches à un Agent. Certaines tâches affichent déjà comme « terminées », donc on ne s’en occupe pas. Mais le lendemain, pendant les tests, on découvre que tout n’est pas terminé. Je retourne vérifier : en fait, on avait créé un worktree, modifié ailleurs que sur `main`, et rien n’a été fusionné.
J’ai ensuite demandé à l’Agent de faire une vérification plus ciblée : il y en avait encore pas mal de ce genre de worktrees. Il les a nettoyés.
Enfin, je lui ai demandé d’ajouter une règle dans Agents.md : on n’interdit pas de créer un worktree, mais il ne faut en aucun cas en laisser un « par oubli ».
--- 参考审查 worktree 提示词 ---
Peux-tu me dire quels worktrees n’ont pas encore été synchronisés avec `main` ? Une fois synchronisés, supprime-les directement. Pour ceux qui ne sont pas synchronisés, liste-les : branche, résumé des modifications (incluant les derniers commits), et la session correspondante.
--- 参考清理 worktree 提示词 ---
Aide-moi à examiner le contenu de ces worktrees : identifie clairement ceux qui méritent d’être fusionnés — fusionne-les pour moi et nettoie les worktrees. Pour ce qui n’est pas sûr, demande-moi confirmation, mais donne-moi des recommandations claires.
--- 参考 AGENTS.md 规则 ---
- worktree ne doit pas être laissé en suspens : pour les tâches faites dans un worktree, une fois terminées, il faut supprimer ce worktree ainsi que sa branche. Avant suppression, choisir l’une des deux options : fusion dans `main` ; ou, si non fusion, d’abord pousser/committer les changements non encore validés sur cette branche, ajouter un tag `archive/<worktree 名>` pour archivage, puis exécuter `git worktree remove` + `git branch -D`.
- Les sessions des subagents orchestrés sont responsables de la finalisation des worktrees qu’ils ont dérivés. Les worktrees qui doivent absolument être conservés (décision utilisateur à venir, conflits à résoudre) doivent être explicitement nommés avec leur chemin et la raison dans la réponse finale ; ils ne peuvent pas être laissés silencieusement.
J’ai ensuite demandé à l’Agent de faire une vérification plus ciblée : il y en avait encore pas mal de ce genre de worktrees. Il les a nettoyés.
Enfin, je lui ai demandé d’ajouter une règle dans Agents.md : on n’interdit pas de créer un worktree, mais il ne faut en aucun cas en laisser un « par oubli ».
--- 参考审查 worktree 提示词 ---
Peux-tu me dire quels worktrees n’ont pas encore été synchronisés avec `main` ? Une fois synchronisés, supprime-les directement. Pour ceux qui ne sont pas synchronisés, liste-les : branche, résumé des modifications (incluant les derniers commits), et la session correspondante.
--- 参考清理 worktree 提示词 ---
Aide-moi à examiner le contenu de ces worktrees : identifie clairement ceux qui méritent d’être fusionnés — fusionne-les pour moi et nettoie les worktrees. Pour ce qui n’est pas sûr, demande-moi confirmation, mais donne-moi des recommandations claires.
--- 参考 AGENTS.md 规则 ---
- worktree ne doit pas être laissé en suspens : pour les tâches faites dans un worktree, une fois terminées, il faut supprimer ce worktree ainsi que sa branche. Avant suppression, choisir l’une des deux options : fusion dans `main` ; ou, si non fusion, d’abord pousser/committer les changements non encore validés sur cette branche, ajouter un tag `archive/<worktree 名>` pour archivage, puis exécuter `git worktree remove` + `git branch -D`.
- Les sessions des subagents orchestrés sont responsables de la finalisation des worktrees qu’ils ont dérivés. Les worktrees qui doivent absolument être conservés (décision utilisateur à venir, conflits à résoudre) doivent être explicitement nommés avec leur chemin et la raison dans la réponse finale ; ils ne peuvent pas être laissés silencieusement.