--- name: git description: Read this before you commit, push, open a pull request, fetch, pull, merge, rebase or reset in Vibe Work, when checks or a review on a pull request need fixing, before you say a change is done, or when a git command answered "Not run". It says which git steps are yours and which are the user's buttons. --- In Vibe Work the user sends work out with buttons in the Changes tab: **Commit**, **Push**, **Create PR** and, for a session copy, **Bring into main**. Your part is the work on the branch. 1. **Yours, as usual:** read-only git (`git status`, `git diff`, `git log`, `git show`, `git blame`), `git add`, and local commits, merges, cherry-picks, reverts, am and pulls in this folder or your own copy. These use Vibe's normal access-mode card. Check the branch and working tree before changing them; do not rewrite pushed commits. 2. **The user's step: sending to a remote.** When the work is ready, commit it and name the folder, for example: "Committed on vibe/fix-login. Push `git test` from [Changes](git%20test/)." For the session repository: "Committed on vibe/fix-login. Push from [Changes](./)." The folder link opens the Changes tab on that repository. A `git push` from you answers exactly: `Not run: sending commits to a remote is the user's step in Vibe Work. Your commits stay on this branch. Tell the user the work is committed, name its folder, and that selecting that folder and pressing Push in the Changes tab sends it.` That answer is expected. Your commits are safe; continue with the next step. In `run_typescript`, Vibe 2.26.1 shows these refusals as "Tool execution was skipped by Runtime policy": same meaning; do not retry another way. A refused push or PR is never replaced by another write to the remote; a ref in a remote folder is not a PR. 3. **Asks the user first, in every mode** (a Vibe Work dialog): common branch rewrites outside your own copy branch, such as `git rebase`, `git reset` to another commit, `git update-ref`, `git branch -f|-d|-D|-m`, `git checkout -B`, `git switch -C`, or a fetch/pull refspec or worktree option that writes another branch; and, even in your own copy, `git stash drop`/`clear` (every copy shares the stashes) and `git worktree remove`/`move`. A preceding folder or branch switch keeps a later rewrite held. Ordinary local operations and config use Vibe's access-mode card. When the user declines a guard dialog, the answer starts with `Not run: the user declined`; carry on without that step, or ask what they want. 4. **GitHub goes through the connector.** Every `gh` command answers `Not run:` without a dialog: the GitHub CLI is not used by the agent in Vibe Work. Read GitHub data with the GitHub connector; for pushing or a pull request, tell the user to use Push or Create PR in the Changes tab. 5. **Your commands have no Git or forge sign-in.** Credential helpers and Git prompts are disabled; token and SSH-agent variables are removed. This applies to Vibe's tools, process tools, secret commands and integrated terminals. Private fetches may fail: let the user use their Git tool. The core's Push and Create PR buttons use the user's sign-in. `git credential ...`, `gh auth token` and `gh auth status --show-token` answer exactly: `Not run: the agent cannot use the user's stored Git or GitHub sign-in. Continue without reading credentials; the user can push or create a PR in the Changes tab.` 6. **Messages from the PR card.** "These checks failed on pull request #N" and "Review comments on pull request #N" come from the user's buttons. Fix the cause on this branch, run the checks, and commit. The user pushes. 7. **"Bring the latest main into this branch".** In your copy run `git merge main` (or the base it names), resolve the conflicts keeping both sides' intent, run the tests, commit the merge, and stay on your branch. 8. **Never rewrite pushed commits** (`commit --amend`, `rebase`, `reset` to before them and commit again): Push never force-pushes, so the user would be stuck. Fix a pushed commit with a new commit. 9. **Failing checks: read the failure before you change anything.** "Send failing checks" quotes the failing lines; for more, read the run through the GitHub connector. Fix what the log names. If it fails in a step or file your change does not touch, tell the user instead of guessing. Never pull, reset or switch branches to make a check pass. 10. **Done means checked.** In a new copy, first install dependencies (the setup hint names the command). Then run the project's check (named in its `AGENTS.md`; give it a long timeout) and quote its result. Failed or could not run: say so; never "tests pass" without the output. Agent Bash commands use `pipefail`: a failed check stays failed through `| tail`. To cut a search short use `grep -m 10`, not `| head`. 11. **Generated files** (a header says GENERATED or "do not edit"): change the source and run its generator; never edit them by hand. 12. Pushing files, creating or merging pull requests, branches, issues, comments or repositories through a connector (GitHub tools) is the same step as `git push`: it is the user's button; such calls answer `Not run:`. Reading through the connector works. 13. A long commit message goes into a file: `git commit -F `; the user then sees a short command to confirm. The command guards check literal command starts after assignments and a few transparent wrappers. They do not inspect scripts, aliases, quotes or computed commands. This is a reminder against accidental actions, not a sandbox: follow the buttons' flow.