For open-source maintainers
Issues in. Reviewed pull requests out.
Every new GitHub issue becomes a card. Agents dedupe it against what's already filed, work out what's missing, and turn the good ones into tested, reviewed pull requests — then report back on the issue. You stay the maintainer; you just stop being the bottleneck.
A kanban board with four lanes — Ideating, Planning, Building and Shipping — carrying tasks from a fresh idea through to a pull request waiting for review.
Triage to merge
The triage you never have time for, done before you look
Duplicates are caught and linked. Vague reports are refined into acceptance criteria. Feature requests are ordered behind what they depend on. By the time an issue reaches you, it's either a clear decision or a pull request.
You decide what the project accepts. Everything else is the factory's job.
- Roadmap
- Deduping
- Refiningyour call
- Planning
- Implementing
- Testing
- Reviewing code
- Mergingyour call
Signals from the outside world
GitHub issues and Discord questions become tasks
One process dedupes and clarifies new GitHub issues; another spots the questions your Discord asks every week and proposes the docs fix. Fixes come back as pull requests that close the issue.
Processes
- Check against open issues
- →Ask the reporter what's missing
- →Suggest tasks
- Find questions asked 3+ times
- →Propose a docs fix
- →Suggest tasks
Suggested tasks
Suggestions arrive once signals come in.
Sent tasks land here.
Engineer from anywhere
Triage between everything else
Open source happens in the gaps of a day job. Grooming proposes the duplicates to close and the priorities to change; you approve them from your phone in the time it takes to read them.
From a beach chair
Raise “Share a note with a public link” to P1?
Three customers asked for it this week, and it unblocks the team plan.
Close “work offline??” as a duplicate of “Offline mode for notes”?
Same idea, filed four months apart. The older one has the better description and 6 votes.
Have a poke around
A Roadmap of feature requests, kept tidy
Invented data, real mechanics. Grooming proposes closing a duplicate, raising what users keep asking for and linking what depends on what — every change waits for your yes.
Raise “Share a note with a public link” to P1?
Three customers asked for it this week, and it unblocks the team plan.
Close “work offline??” as a duplicate of “Offline mode for notes”?
Same idea, filed four months apart. The older one has the better description and 6 votes.
Built for a public repo
Keep the project moving without burning out
Issues become work
A new issue on a connected repo becomes a card automatically, and ampm comments back with progress and the pull request.
Duplicates folded, not closed rudely
Repeat reports are linked to the original with an explanation, so reporters feel heard and the backlog stays clean.
Contributor PRs, adopted
An outside pull request that stalls can be adopted: agents rebase it, address review comments and carry it over the line.
Your contributing guide, enforced
Agents follow your CONTRIBUTING and AGENTS files — style, tests, commit format — on every change.
Questions
Does ampm comment on issues?
Yes. It reports progress back on the issue and links the pull request, so reporters see where their issue stands.
What about duplicate issues?
Duplicates are detected and linked to the original with an explanation, keeping the backlog clean without closing reports rudely.
Which coding agents does ampm work with?
Claude Code and Codex. ampm runs them on the subscription you already pay for — no API keys and no second bill for tokens — and when one account hits its usage limit, work moves to a backup account without losing anything.
Does ampm merge code on its own?
Nothing merges unless you want it to. Plans, questions and merges wait in your inbox with the plan, diff, pull request and full transcript attached, and you decide which decisions to keep and which to hand off.
Where does the code run, and is my repo safe?
Every task runs in an isolated sandbox on its own worktree, on workers you choose — your laptop, a server you own, or a cloud machine — and can only push to a branch. The output is always a pull request into your repo.
How is this different from chatting with a coding agent?
A chat forgets everything when you close the tab and needs you watching it. ampm keeps every task in a database with its plan and history, runs a real process — plan, implement, test, review, merge — and only asks you when a decision is actually yours.
Can one workspace cover several repos?
Yes. Add the repos agents should change, and add more as read-only context — a design system, an API they call, product docs — so their work matches what's around it. One change can span several repos as one piece of work.
How do I get access?
Join the wait list with Google or GitHub. We're letting people in a few at a time, in the order they joined, and we'll email you when it's your turn.
Early access
Stop being the bottleneck
We're letting people in a few at a time. Join the wait list with Google or GitHub and we'll email you when it's your turn. Run it on our cloud or on infrastructure you control — your repos, your subscriptions, workers on machines you choose.