pi-git

Tools for git and GitHub for pi

Every action that publishes content shows a review step before executing: approve, edit, or cancel. No accidental commits or PRs.

Why

When your agent needs to commit, create a PR, or read review comments, the natural path is a bash tool call. But that gets painful fast:

Long messages are hard to read. A commit message or PR body shoved into a bash command is unreadable — all on one line or with inline \n escapes. You end up squinting at the raw tool call in your terminal just to figure out what the agent is about to do.

Escaping is brittle. The agent will get shell escaping wrong. Quotes, backticks, dollar signs — something breaks, the command fails, and the agent burns a turn retrying.

Review costs extra. With pi-guard, you can intercept and cancel a bash tool call before it runs. But that sends the agent back to the drawing board for another full turn. With pi-git, you edit the message inline right there in the review step — approve, edit, or cancel in one step. No extra round trip to the model.

Complex GitHub operations get wrapped. When the agent wants to read PR review threads, it constructs a gh api graphql command with a multi-line query escaped for the shell. As a human, you have to parse that command to be sure it's safe before approving. pi-git encapsulates that in a focused git_pr_comments tool — no shell escaping to audit, no GraphQL to verify. You know by the tool name alone that it's a read-only operation.

The editor is right there. pi's built-in editor component powers the edit step. Press ctrl+g to open the text in neovim (or whatever $EDITOR you've wired up), make your changes, save, and you're back in the review flow. No context switching.

Install

{
  "packages": ["npm:@jdiamond/pi-git"]
}

How it works

Install the extension and your agent gets four new tools. When the agent decides to commit, amend, open a PR, or read comments, it calls one of these instead of reaching for bash:

• git_commit — stage files and commit, with a review step that lets you edit the message in an editor before it runs.

• git_amend — amend the last commit. Shows the current message and files, plus what's changing. Same review flow.

• git_create_pr — create a pull request with optional reviewers, draft flag, and target branch. Review the title and body before it goes out.

• git_pr_comments — read all comments on a PR: conversation comments, inline review threads (with resolved/outdated status), and review summaries — including Copilot feedback. Auto-detects the repo, or pass owner/name.

Every tool that creates or publishes content uses the same review step: you see exactly what will happen, then approve, edit, or cancel.