pi-coder

Interactive code workbench and diff review UI for Pi, with annotations, GitHub pull-request reviews, and agent handoffs.

Packages

Package details

extension

Install pi-coder from npm and Pi will load the resources declared by the package manifest.

$ pi install npm:pi-coder
Package
pi-coder
Version
0.4.6
Published
Aug 20, 2026
Downloads
not available
Author
dantetekanem
License
MIT
Types
extension
Size
6.6 MB
Dependencies
2 dependencies · 4 peers
Pi manifest JSON
{
  "extensions": [
    "./src/index.ts"
  ],
  "image": "https://raw.githubusercontent.com/dantetekanem/pi-coder/main/docs/assets/code.gif"
}

Security note

Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.

README

pi-coder

pi-coder adds two full-screen coding tools to Pi:

  • /diff and its /review alias review local changes, commits, branches, ranges, and configured remote pull requests.
  • /code browses and edits a workspace without leaving Pi.

It also keeps a compact repository summary in Pi's footer so you can see the current file count, additions, and deletions between reviews.

Install

pi install npm:pi-coder

To install the latest source directly from GitHub instead:

pi install https://github.com/dantetekanem/pi-coder

Restart Pi or run /reload.

Review changes

Run /diff or /review inside a repository:

/diff
/review

/review is an alias for /diff; both commands accept the same targets.

Review changes with pi-coder

Useful targets:

/diff                         # uncommitted changes
/diff main...HEAD             # a Git range
/diff remote <branch-or-url>  # a remote branch or configured pull request
/diff --resume                # a parked review

The review UI supports line, file, and review-wide feedback. Feedback can be marked as:

  • DISCUSS — send the question back to the agent.
  • COMMENT — keep review feedback for a local or remote review.
  • MODIFY — propose or apply an exact code change.

GitHub pull requests work by default through the authenticated gh CLI. Confirmed reviews receive a grammar-safety pass before submission, and saved drafts are revalidated when the reviewed revision changes.

Remote providers

After gh auth login, a GitHub URL works without configuration:

/diff remote https://github.com/owner/repository/pull/123

Add other providers in ~/.pi/agent/pi-code-diff-settings.json. Local settings extend the built-in GitHub provider; a local providers.github entry explicitly overrides it. Provider operations are executable-plus-argument arrays, never shell commands. Template values such as {repo}, {number}, {branch}, and {payloadPath} are passed as individual arguments.

{
  "version": 1,
  "providers": {
    "secondary": {
      "label": "Secondary code host",
      "executable": "forge",
      "urls": {
        "patterns": [
          { "host": "code.example", "path": "/{repo}/change/{number}" }
        ],
        "canonical": "https://code.example/{repo}/change/{number}",
        "clone": "https://code.example/{repo}.git"
      },
      "operations": {
        "pullRequest": { "args": ["change", "show", "{repo}", "{number}"] },
        "reviews": { "args": ["change", "reviews", "{repo}", "{number}"] },
        "branchLookup": { "args": ["change", "list", "{repo}", "--head", "{branch}"] },
        "identity": { "args": ["identity", "--json"] },
        "submitReview": { "args": ["change", "review", "{repo}", "{number}", "--input", "{payloadPath}"] }
      },
      "refs": {
        "head": "refs/changes/{number}/head"
      },
      "fields": {
        "number": "id",
        "title": "subject",
        "body": "description",
        "additions": "metrics.added",
        "deletions": "metrics.removed",
        "changedFiles": "metrics.files",
        "author": ["actor.handle", "user.handle"],
        "state": "phase",
        "reviewState": "decision",
        "headRefName": "source.name",
        "headRefOid": "source.oid",
        "baseRefName": "target.name",
        "identityLogin": "login",
        "submissionId": "id",
        "submissionState": "state"
      },
      "capabilities": {
        "atomicReview": true,
        "baseRevisionRequired": false,
        "fileComments": false,
        "requestChangesBodyRequired": false,
        "validateSubmitResponse": true,
        "validateTargetBeforeSubmit": true
      }
    }
  },
  "repositories": {
    "owner/repository": {
      "cwd": "/absolute/path/to/checkout",
      "subdir": "packages/app",
      "pathspecs": ["packages/app", "shared/ui"],
      "importAliases": { "@shared": "shared/ui" }
    }
  }
}

pullRequest must return JSON addressable through the configured fields. reviews, branchLookup, reply operations, and repository profiles are optional. submitReview receives the generated review payload through {payloadPath}. Set baseRevisionRequired only when the provider returns and pins baseRefOid.

Common review controls:

Key Action
Arrow keys Navigate files and diff lines
c / d Add a comment / discussion
Enter or m Edit the selected line
v Toggle unified and side-by-side views
s Finish the review
Esc Go back or close safely

Browse and edit code

Run:

/code

Browse and edit code with pi-coder

/code fills the small gap between the coding agent and you. It is for the last 1% of the work, when you want to open the file yourself, read the code around it, make a small change, or point to exact lines and ask a question. Instead of leaving Pi or asking the agent to paste fragments into the conversation, you can work with the code directly and continue where you left off.

/code is not a replacement for Vim, Neovim, VS Code, or the editor you already use. If one of those is already part of your workflow, keep using it. But learning Vim or Neovim just to inspect one function makes no sense, and opening something as heavy as VS Code can be more than the moment needs. /code is the minimum viable coding tool: a small project explorer, readable source, search, and enough editing for focused changes. The agent can take you to the exact file and lines, guide you through related parts of the code, and bring a selected piece back into the conversation when you want to discuss it. It protects unsaved work, will not overwrite a file changed somewhere else, and stays away from staging, commits, and pushes. The goal is not less human involvement. It is keeping the human loop powerful without slowing the work down.

Run /code syntax to choose and remember any syntax theme bundled with Shiki. The selection applies the next time /code opens.

Common Workbench controls:

Key Action
Arrow keys or j / k Navigate files and source lines
Enter Open a file or enter INSERT mode
Tab / Shift+Tab Move between Explorer and Source
/ Find a file or search the current buffer
n / N Move through buffer matches
Ctrl+S Save
Esc Leave INSERT, return to Explorer, or close safely

See docs/workbench.md for the full Workbench behavior and standalone runner.

Agent tools

Agents can use the same interfaces through:

  • open_code — open the Workbench at an optional file, range, or guided code story.
  • open_code_diff — open /diff with an optional target and prepopulated comments.
  • submit_pr_review — submit a confirmed configured-provider review.

Development

pnpm install
pnpm typecheck
pnpm test

Build the standalone Workbench with pnpm workbench:build.

Acknowledgments

Inspired by Mario Zechner's pi-diff-review, with thanks to Rob Zolkos for his contributing work on the review workflow.

License

MIT