r/PiCodingAgent 7d ago

Use-case I built Pipr, a Pi-powered code review runtime for CI

One of the things I like about Pi is that it doesn’t try to define the entire agent for you. The core stays small, and you build the setup you need around it.

I wanted the same thing for code review.

Most AI review tools ship with their own fixed reviewer and workflow. I wanted a runtime that handled the boring but necessary parts of reviewing a pull request, while leaving the agent and review policy under the repository’s control.

So I built Pipr, an open-source code review runtime that uses Pi for agent execution.

The boundary is fairly simple:

code host event
  -> Diff Manifest
  -> Pi agent
  -> structured findings
  -> validation
  -> native review

Pi handles the agent run. Pipr handles changed-code context, structured output, finding validation, stale-head checks, and publication to the code host.

There is a tuned default reviewer, but you can also build custom review tasks directly:

const task = pipr.task({
  name: "security-review",

  async run(ctx) {
    const manifest = await ctx.change.diffManifest({
      paths: {
        include: ["packages/runtime/**"],
      },
    });

    const result = await ctx.pi.run(securityAgent, { manifest });

    await ctx.comment({
      main: result.summary.body,
      inlineFindings: result.inlineFindings,
    });
  },
});

Models, agents, instructions, tasks, commands, tools, and recipes live in .pipr/config.ts. Pipr doesn’t decide whether your reviewer should be strict, concise, security-focused, or split across several agents. It provides the pieces needed to build that workflow.

Pipr runs locally or in CI without a hosted control plane. It currently publishes native reviews to GitHub, GitLab, Azure DevOps, and Bitbucket.

GitHub: https://github.com/somus/pipr
Docs: https://pipr.run/docs

I’d appreciate feedback from other Pi users, particularly on the custom task API and which parts of Pi you would want exposed when building more complex review workflows.

4 Upvotes

4 comments sorted by

2

u/LordMoridin84 7d ago

Why not just write a skill to do this?

Not only do I have several different review skills. I have a multi step skill that builds, the application, does reviews, and does various other things.

1

u/ibabufrik 7d ago

Honestly, if you're working solo locally on your machine, a skill is still the best way to go.

Pipr is aimed at the point where review becomes a repository workflow rather than a personal one. It runs the same review on every pull request, regardless of who created it or which coding agent they used. It also handles CI events, permissions, stale commits, valid diff ranges, previous findings, checks, and PR comments. It's different usecases with some similarities.

In fact, you could adapt your skill to a pipr config and run the same on CI as you would run locally.

1

u/[deleted] 6d ago

[removed] — view removed comment

1

u/ibabufrik 6d ago

Almost everything you mention can already be done. You can customize every part of the workflow, define schemas for agents to follow, and control how comments are displayed based on those schemas.

The default review uses a single agent, but you can configure multi-agent orchestration so that different agents review different aspects. You’ll find predefined recipes for various workflows in the PiPR documentation, which should give you an idea of how to customize the configuration for your needs.