/github

name: github
description: "Load before any git or GitHub work in a chat: committing model changes, pushing a branch, opening a pull request, updating a pull request, or commenting on one. Covers the sandbox git checkout, the signalpilot/ branch rule, and the open_pull_request, update_pull_request, and comment_on_pull_request tools."
type: skill

GitHub: publish chat work as a pull request

The chat agent publishes work through git and pull requests. A person reviews and merges on GitHub. The agent never merges.

Where git runs

The sandbox VM holds the project at `/workspace`. `/workspace` is a git repository. The remote `origin` is SignalPilot's git server, not GitHub. Credentials are already configured. You do not need a token.

Run every git command with `sandbox_exec`. Set `cwd` to `/workspace`. Edit files with `sandbox_write_file`. Do not edit files in your own working directory. It is a frozen copy for reading only.

The system prompt names the base branch. Your commits go on top of that branch.

Branch rule

The server accepts a push only to a branch that starts with `signalpilot/`. Use the form `signalpilot/<short-name>`. Use a short lowercase name with hyphens that describes the change. Example: `signalpilot/fix-revenue-grain`.

Use one branch name for one piece of work. Push to the same name each time you add commits.

The server refuses these pushes and prints the reason:

• A push to any branch that does not start with `signalpilot/`.
• A force push. Add a new commit instead.
• A branch deletion.
• A branch that another chat created. Use a new name.
• A new branch name that already exists on GitHub. Use a new name.
• Any push when the project is not linked to GitHub. Tell the user and give

the diff in your answer instead.

Steps to publish

1. Change the files in `/workspace` in the sandbox VM. 2. For model changes, run `dbt_execute` with `build` on the changed models. Fix errors until the build passes. 3. Check the diff: `git status` and `git diff`. 4. Stage and commit: `git add -A && git commit -m "<clear message>"`. 5. Push: `git push origin HEAD:signalpilot/<short-name>`. 6. Call `open_pull_request` with a title and a body. In the body, list the files or models you changed, what changed in each, and the build result. 7. Put the pull request URL from the tool result in your final answer.

Pull request tools

• `open_pull_request(title, body, draft, branch)`: opens the pull request

for the branch you pushed. Leave `branch` empty to use your most recent push. Set `draft` true for work that is not ready for review. If the branch already has an open pull request, the tool returns it.

• `update_pull_request(title, body, pr_number)`: changes the title or the

body. Use it after you push more commits, so the description stays true.

• `comment_on_pull_request(body, pr_number)`: adds a comment. Use it to

report a new build result, to answer a review comment, or to explain one part of the change in detail.

Every tool returns `pr_url`. Give the user that link. Every tool acts only on branches and pull requests that this chat created.

Good pull request messaging

• Title: one line, imperative, under 70 characters.
• Body: what changed, why, how you verified it, and what the reviewer

should check.

• When the user asks for detailed explanations, put one topic per comment

with `comment_on_pull_request`.

Do not

• Do not run `git push --force`.
• Do not push to `main` or to any branch outside `signalpilot/`.
• Do not try to merge. There is no tool for it.
• Do not put tokens or credentials in commits, comments, or answers.