# Sverka Git Pered Deystviem > «Что в рабочем дереве», «дерево грязное», «можно коммитить», «что с ветками», «можно удалить ветку», «fatal: not a git repository», «перед commit»: read-only снимок git. - Skill: `kir-kopylov/sverka-git-pered-deystviem` (Agent Skill, multi-file: 9 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/sverka-git-pered-deystviem` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/sverka-git-pered-deystviem/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: kir-kopylov (https://skillmd.com/u/kir-kopylov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kir-kopylov/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` первым шагом. Если видите расхождение между целью пользователя и фактом, ответьте в формате: ```text Стоп. Факт: <что наблюдаемо>. Расхождение: <цель> vs <текущее действие или предпосылка>. Шаг: <одно действие к цели>. Проверка: <ожидаемый результат>. ``` ### 2. Определить Target Repo Не предполагайте, что текущий терминал стоит в нужном repo. Сначала установите target repo: - если пользователь дал путь — используйте его; - если путь не дан, проверьте текущую папку; - если текущая папка не repo, не запускайте короткие git-команды без `-C`; - если возможны несколько repo, покажите кандидатов и не делайте мутаций. Команды для target repo пишите как `git -C ...`, пока cwd не доказан. ### 3. Первый Read-Only Снимок Минимальный набор: ```bash pwd git -C status --short --branch --untracked-files=all git -C diff --stat git -C diff --cached --stat git -C stash list --max-count=5 git -C 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 `, если cwd не доказан. ## Опрос После Использования Опрос задаётся один раз — после выдачи вердикта о состоянии репозитория, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте. ```text Опрос по skill: 1. Что в этом использовании sverka-git-pered-deystviem было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/sverka-git-pered-deystviem/usage-feedback.jsonl` — лучше через bundled script: ```bash 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//exception-log.jsonl`. Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.