pi-git

Tools for git and GitHub for pi

Every action that publishes content shows a review step before executing: accept, 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 — accept, 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 a set of tools for common git and GitHub operations.

Read-only tools

These tools let you give an agent controlled access to git without granting the bash tool. Use them to build subagents that can inspect code, review history, and read PR feedback — but can't modify anything.

• git_diff — show changes (unstaged, staged, or between commits/branches).
• git_log — commit history with filters for author, path, date range, and output format.
• git_show — full diff and metadata for a specific commit.
• git_status — working tree status: staged, unstaged, and untracked files.
• 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.

Write tools

Every tool that creates or publishes content shows a review step before executing: accept, edit, or cancel.

• git_commit — stage files and commit. Review the message before it runs.

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

• 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_add_pr_comment — add a top-level conversation comment to a pull request. Review the body before it's posted.

• git_reply_to_pr_thread — reply to an inline review thread. The review step lets you accept the reply body, with an "Accept & resolve" option that posts the reply and resolves the thread in one go. Thread IDs come from git_pr_comments.

All tools accept an optional workingDir parameter. It defaults to pi's current working directory; relative paths are resolved from that directory. Use it when the agent is operating from one repository but needs to commit, create a PR, or inspect reviews in another.