Sverka Git Pered Deystviem

Git Worktree Reality Check

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Проверка состояния Git перед изменениями»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Не завершайте ответ одной строкой уведомления или обещанием будущей проверки. Если пользователь просит «проверь git state» и текущая папка доступна, до отправки первого ответа обязательно выполните через терминал read-only снимок Git и верните наблюдаемые факты в этом ответе. Только если target repo нельзя однозначно определить из текущего контекста или инструментов, задайте один ближайший вопрос, который меняет выбор repo.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Skill останавливает неверное git-действие до того, как оно изменит repo. Главная задача — доказать, что намерение пользователя совпадает с фактическим состоянием: нужный repo, текущая папка, активная ветка, upstream, staged/unstaged/untracked, stash, локальные commits, remote refs и PR state.

Это не общий учебник git. Это read-only reality check перед мутацией или перед выводом «можно коммитить / можно удалить / можно архивировать».

Естественные Входы

Запускайте skill на явные фразы:

• «что в рабочем дереве?»;
• «можно коммитить?»;
• «дерево грязное»;
• «проверь git state»;
• «что с ветками?»;
• «можно удалить ветку?»;
• «что значит ahead/behind?»;
• «почему fatal: not a git repository?»;
• «перед следующим commit»;
• «перед PR»;
• «можно архивировать сессию?».

Имплицитно запускайте skill, если пользователь просит git-мутацию, а target repo/cwd/branch/upstream не подтверждены:

• commit, git add, push, Pull Request;
• branch -d, remote branch cleanup;
• stash pop, merge, rebase;
• reset, restore, checkout;
• «почисти ветки», «запушь это», «сделай PR», «убери remote clutter».

Процесс

1. Reality-Intent Stop

Если следующее действие меняет git state, а repo/cwd/branch/upstream не доказаны, остановитесь и сначала выполните read-only проверку. Не выполняйте commit, git add, push, branch -d, reset, restore, stash pop, merge или rebase первым шагом.

Если видите расхождение между целью пользователя и фактом, ответьте в формате:

Стоп.
Факт: <что наблюдаемо>.
Расхождение: <цель> vs <текущее действие или предпосылка>.
Шаг: <одно действие к цели>.
Проверка: <ожидаемый результат>.

2. Определить Target Repo

Не предполагайте, что текущий терминал стоит в нужном repo. Сначала установите target repo:

• если пользователь дал путь — используйте его;
• если путь не дан, проверьте текущую папку;
• если текущая папка не repo, не запускайте короткие git-команды без -C;
• если возможны несколько repo, покажите кандидатов и не делайте мутаций.

Команды для target repo пишите как git -C <repo> ..., пока cwd не доказан.

3. Первый Read-Only Снимок

Минимальный набор:

pwd
git -C <repo> status --short --branch --untracked-files=all
git -C <repo> diff --stat
git -C <repo> diff --cached --stat
git -C <repo> stash list --max-count=5
git -C <repo> branch -vv

Если действие связано с PR, merge, push или удалением remote branch, дополнительно проверьте remote/PR state. git fetch --all --prune допустим только после локального снимка и только когда нужна актуальная remote-карта; скажите, что обновляете refs.

4. Классифицировать Состояние

Разделяйте:

• рабочее дерево: staged, unstaged, untracked, stash;
• веточное состояние: current branch, upstream, ahead/behind, [gone];
• уникальная работа: commits, которых нет в origin/main или remote branch;
• завершенные хвосты: ветки, уже merged в origin/main;
• remote clutter: merged remote branches и unmerged remote branches;
• PR/CI state: открыт, draft, merged, mergeable, skipped jobs by design.

Не называйте repo «чистым», если чистое только рабочее дерево, но активная ветка не та или есть pending branch decision. Формулируйте слой точно: «рабочее дерево чистое, но веточная карта требует решения».

5. Mutation Gate

После снимка можно предлагать изменяющие команды, но не выполнять их без понятного scope. Остановитесь и спросите или дайте один безопасный следующий шаг, если найдено:

• несколько возможных repo;
• unstaged/staged/untracked изменения;
• stash с неизвестным содержимым;
• branch ahead без remote/PR;
• upstream [gone];
• локальный commit, не reachable из origin/main;
• ветка на удаление не доказана как merged;
• remote branch без PR и с diff относительно origin/main;
• пользователь просит destructive cleanup шире проверенного scope.

6. Ответ Пользователю

Структурируйте ответ коротко:

• Repo: target repo и cwd, если важно;
• Worktree: staged/unstaged/untracked/stash;
• Branch: current branch, upstream, ahead/behind;
• Remote/PR: только если связано с задачей;
• Что целесообразно: один или несколько безопасных шагов;
• Что нецелесообразно: команды, которые сейчас рискованны.

Границы

Не используйте skill:

• на чисто учебный вопрос вроде «что такое rebase?»;
• когда пользователь просит только объяснить уже полный git-вывод, и в выводе достаточно данных;
• для задач без git/repo/PR/CI;
• вместо специализированного GitHub CI-debug workflow, если проблема уже точно в логах Actions.

Нельзя:

• выполнять git add ., commit, push, branch -D, reset --hard, restore, stash pop, rebase или remote delete до reality check;
• удалять branch только потому, что он старый;
• считать 200, green check или merged PR доказательством локальной установки или текущего состояния;
• смешивать «рабочее дерево чистое» с «repo полностью прибран»;
• давать команды без git -C <repo>, если cwd не доказан.

Опрос После Использования

Опрос задаётся один раз — после выдачи вердикта о состоянии репозитория, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании sverka-git-pered-deystviem было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/sverka-git-pered-deystviem/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.