Вы отправляете агента переделать авторизацию. Он идёт в текущую ветку - ту самую, где у вас лежит наполовину доделанная правка вёрстки. Через полчаса вы уже не понимаете, где ваши изменения, а где его, и что из этого стоит коммитить.
Решение известно и старше большинства агентов: у одного репозитория может быть несколько рабочих деревьев. Отдельная папка, отдельная ветка, общая база объектов. Никакого второго клона.
Скил using-git-worktrees из набора Superpowers интересен не этим - механизм Git давно существует и документирован. Интересно то, что вокруг него выстроен протокол: как понять, что изоляция уже есть, кому уступить дорогу, что проверить перед созданием и чем доказать, что рабочее место чистое. Разница между "агент знает команду" и "агент безопасно работает с репозиторием" лежит именно в этих мелочах.
Что вообще делает git worktree
Начнём с механизма, потому что без него протокол не читается.
Репозиторий может иметь одно главное рабочее дерево и сколько угодно связанных. Официальная документация так их и называет: main worktree - то, что создали git init или git clone, и linked worktree - всё остальное. Связанные деревья делят с репозиторием базу объектов и ссылки, но у каждого свои рабочие файлы, свой HEAD и свой индекс.
В простейшей форме команда создаёт ветку сама:
Ветка получит имя последнего сегмента пути - hotfix. Чтобы взять существующую ветку, её указывают вторым аргументом. Для одноразовых экспериментов есть -d: дерево с отделённым HEAD, без всякой ветки.
Одно ограничение стоит знать заранее: одна ветка не может быть выписана в двух деревьях одновременно. Команда откажется, и правильно сделает - иначе два дерева правили бы один и тот же указатель.