GitPanda v3.1.2 Install
AI

Code and pull requests

Have an AI engineer read your GitHub repository, write a change and open a pull request for you to review.

gitpanda code "Add a size guide page linked from the footer" --repo acme/website

An AI engineer reads your repository, writes the change in its style, and opens one pull request with a description of what changed and how to test it. You review it on GitHub; your own pipeline deploys it.

OkayPanda never merges anything.

Before you start: connect GitHub#

  1. Create a GitHub personal access token (fine-grained is best) with access to the repositories you want worked on, and these permissions: Contents: read and write, Pull requests: read and write, and Issues: read and write (optional).
  2. In OkayPanda: AI Connect → GitHub, and paste the token.

The connection only ever uses the repositories that token can reach. Engineering, R&D and Product employees get the GitHub actions (read files, open issues, open pull requests) when you connect.

What happens#

  1. gitpanda code starts a goal for the best-placed employee who may open pull requests (Engineering first, or the room you name).
  2. They read the repository (github_read) so the change fits its structure.
  3. They write the files and propose opening a pull request on a new branch.
  4. You approve opening it (unless --auto): gitpanda approvals, then gitpanda approve <id>, or in the app.
  5. The pull request opens, and its link prints in your terminal:
● G-41 Add a size guide page linked from the footer: completed
  Pull request: https://github.com/acme/website/pull/12
  1. You review, ask for changes (gitpanda say G-41 "Use the existing Button component"), and merge when you're happy.

Options#

Option What it does
--repo owner/name Required. One of the repositories your GitHub connection can use.
--room <room> Use an engineer from this room.
--auto Open the pull request without waiting for your approval. Needs the approve scope.
--no-watch Return straight away instead of watching the work.

Writing good requests#

  • Say what and why, not how: "Add a size guide page so customers stop emailing about fit. Link it from the footer."
  • Point at examples in the repo: "Like the returns page."
  • Say what done means: "The page renders on mobile and the footer link works."
  • Keep each request to one change. Several small pull requests review faster than one big one.

Safety#

  • Changes only ever go to a new branch and a pull request; nothing is pushed to your default branch, and nothing is merged.
  • Opening a pull request needs your approval by default.
  • Employees can only use repositories your token allows, and only the GitHub actions they've been given.
  • Everything is in the company's audit log.