repo2ship. View on GitHub
OPEN SOURCE. READY TO MAKE IT YOURS.

From issue
to shipped_

A coding pipeline that lives in your repo.
Turn GitHub issues into verified pull requests.
Your agents do the work. You make the call.

Start building▶ Explore the pipeline
GitHub-nativeBring your own modelMIT licensed
THE SHORTEST PATH TO YOUR NEXT PR↗
Issue #42agent

Add a dark mode toggle

Respect system preferences. Persist the choice.

your-repo / issues→
↓
repo2ship / pipelineILLUSTRATIVE RUN
✓Refine acceptance criteriastrategist
✓Implement & run checksimplementer
✓Pass the policy gateno model
✓Verify the diff & the UIstrategist
All acceptance criteria verified
↓
Ready for your review.Pull request opened. Final call: yours.
↗
YOUR STACK. YOUR CHOICE.
π piOpenCodeGitHub Actions▥ Langfuseoptional

01 / THE PIPELINE

A little less back-and-forth.
A lot more forward.

From a rough idea to a reviewable change.
Every step has a job. Every change has a check.

STRATEGIST MODEL

Good code starts
with a clear issue.

Add the agent label to a GitHub issue. The strategist turns your request into testable acceptance criteria, and asks questions on the issue when something needs clarifying.

See how it works
issue / acceptance-criteria•••

# A clear spec before the first line of code.

✓ Toggle between light and dark themes
✓ Default to the system preference
✓ Remember the choice after a reload
Spec ready for implementation

Already in a PR? Comment @pi or @agent to keep the work moving.

02 / CONTROL, BY DESIGN

Let agents build.
Keep the keys.

Autonomy is useful. Boundaries make it practical.
Repo2Ship puts checks between a generated patch and your main branch.

Read the security model

A policy gate that doesn't guess.

Deterministic checks protect pipeline files and package scripts, reject deleted tests, and flag dependency or test changes for review.

CODE ENFORCED. NO MODEL INVOLVED.

A second pair of eyes. And a browser.

A separate verification pass reviews the diff and runs browser QA against every acceptance criterion. You can give it a different model.

The merge is still your decision.

Auto-merge is off by default. Agents work on their own branches, with bounded repair rounds. Review the evidence, then ship when you're ready.

03 / GET IT RUNNING

Your repo. Now with a pipeline.

Full setup guide
  1. 1

    Make the template yours.

    Create a repo from the template, or copy the pipeline into an existing project.

    Use this template ↗
  2. 2

    Bring your engine and model.

    Choose Pi or OpenCode. Configure your provider credentials, model, and publishing token in GitHub Actions.

  3. 3

    Point it at your project.

    Set your verify commands and app URL in .pi/pipeline.json. Configure review rules, enable the agent, and label an issue agent.

Actions configuration
# Repository variables
IMPLEMENTER_ENGINE=pi
IMPLEMENTER_MODEL=your-model-id
STRATEGIST_MODEL=your-review-model-id

# Repository secret
MODEL_API_KEY=your-provider-api-key

# Keep the final decision with you
ENABLE_AUTO_MERGE=false
Example configuration. Follow the guide for publishing credentials and repository permissions.

NO BLACK BOX REQUIRED

See what went into the ship.

Connect Langfuse to inspect run trajectories, token counts, and estimated costs. Score merged or closed agent PRs to compare model outcomes over time.

Explore the repository
OPTIONAL INTEGRATION

04 / A FEW MORE DETAILS

Before you ship.

Do I need a separate platform?+

The pipeline runs in GitHub Actions inside your repository. You supply model credentials and a publishing token. Langfuse tracing is optional. GitHub Actions and model providers may incur charges.

Which models and engines can I use?+

Choose Pi or OpenCode independently for each model role. Repo2Ship supports OpenAI-compatible endpoints, Azure, and native Amazon Bedrock. You provide model IDs; there is no built-in default model. The Bedrock integration has not been live-tested.

Can I add it to an existing project?+

Yes. Copy the workflow, pipeline scripts, configuration, and supporting files into your repo, then set the verify and start commands for your app. The pipeline assumes a Node setup with npm ci and Playwright; other stacks need commands that run after those steps. Follow the migration guide ↗

What happens when a check fails?+

The implementer can run up to three repair rounds when verification fails. Verifier findings can trigger at most one automatic fix round. Mandatory unresolved hygiene issues fail the run instead of opening a PR.

Is it ready for production repositories?+

Repo2Ship is early-stage developer tooling. Start with a test repository, configure review rules and provider budgets, and review generated code before merging. Keep auto-merge off while you evaluate the workflow. Read the trust boundaries ↗

LESS COORDINATING. MORE CREATING.

Your next idea
deserves a pull request.

Make your first ship

Open source. MIT licensed. Built to be yours.