Why I built it
I am a product person, not an engineer. I have led builds for decades without becoming very technical. AI has changed everything. Product managers can now build and contribute directly, not just write the spec and wait. The problem is that most of us do not know where to start, how to learn, or how to get safely from a feature spec to code on GitHub.
Product-to-PR is the process I wanted when I started: it guides me step by step to learn agentic coding, and it grows with me as I learn.
Guide me mode explains everything, with approvals between each step. Build with me mode explains less. Take the lead mode gets out of your way. You graduate as you go, and the safety checks stay the same at every level. I built it with the same agents it now runs, and for others starting from the same place I was.
What it does
You point it at a repository (a local folder or a GitHub URL) and type a one-line feature request. From there it works through ten steps, explains each one, and stops for your approval before anything that matters.
-
Preflight. Before it touches anything, it checks that the repository, Git, and the coding agents it needs are ready, explains what it found, and asks for one confirmation of the risks. If something is missing, it tells you how to fix it and checks again.
-
Inspect. It reads the codebase: structure, entry points, tests, the files most likely to change, and any instructions the repository already carries for AI agents.
-
Restate. It restates your request in plain language, grounded in what it found: what the feature does, who it helps, why it matters. You confirm or correct it before anything else happens.
-
Discover. It asks focused product questions: who the user is, what should happen, what choices are configurable, what the outputs are, and what is out of scope. Small, reversible decisions are grouped so you can accept them all, review them one by one, or decline them. Decisions that change scope, users, data, safety, or outcomes always get their own question.
-
Specify. It writes the specification: feature summary, acceptance criteria you can observe, implementation steps, dependencies, risks, and a test plan. Every decision is labeled by where it came from: something you confirmed, evidence in the code, a recommended default, or an assumption still to confirm. You approve, modify, or reject. Approved specs are saved so you can stop and resume later from the same point.
-
Branch. It creates a separate branch for the work, after you approve, so nothing touches your main code.
-
Implement. It hands the approved spec to Codex, Claude Code, or a written prompt you can give to any other agent. The agent that writes the code cannot run the checks or publish anything.
-
Verify. It runs the repository’s own tests and checks, only the ones the repository has declared safe, and tells you how much confidence the evidence gives: high, medium, or low. It never guesses that an unknown script is safe to run.
-
Review. It shows you the full diff, the list of changed files, and how the result measures up against each acceptance criterion, before offering to commit.
-
Publish. Commit, push, and pull request are three separate approvals. It proposes a commit message from the actual change, pushes only the approved branch, and writes a PR description that links the request, the decisions, the criteria, the implementation, the risks, and the test evidence. A reviewer can follow the whole trail. It asks whether you or another maintainer will review, and it always stops before merge.
Every stop is a real stop. You can end at any checkpoint with a saved file and a clear record of where you are.
Who it is for
- Product managers and founders working with a coding agent on a real codebase
- People learning agentic coding who want to start with every step explained, then graduate to less guidance as their confidence grows
- Small teams that want a paper trail from request to PR
- Anyone who wants an agent to do the work without giving it the keys
Status
Working. All ten steps run today, including evaluation rubrics, recovery and retries, and a second model reviewing the first one’s work. Open source, TypeScript, runs on your machine with Node. Works on a local repo or a GitHub URL using your existing gh login.
Good fit, and not yet a fit
Good fit: a GitHub or local repository, a feature idea, and the willingness to review each proposed change.
Not yet a fit: a repository you do not trust, a production emergency, or anyone expecting the tool to merge changes without review.
What is next
The roadmap is ordered by user outcomes, not dates.
- Launch and adoption. Tutorials, exercises, and worked examples for people with limited technical experience; a safe practice repository so a first run touches nothing real; blog posts drawn from real use; and feedback channels once the repository is public.
- Team workflows and integrations (exploring). Templates for organization-specific briefs and acceptance criteria; imports from issue trackers and product documents; pull-request, CI, and code-review integrations; shared approval records between product and engineering. These move only when the single-user workflow has proved reliable outside this repository.
The full roadmap is in the repository under docs/. Questions and ideas go in Discussions, and six labeled starter issues are open for first-time contributors.
Get it
Try it in your browser: GitHub Codespaces. Best if your project is on GitHub and you do not want to install development tools locally. GitHub creates a browser workspace with Node and the GitHub tools and installs Product-to-PR's dependencies. You still install and sign in to your AI coding tool, such as Codex, inside it.
Use it on your computer. Best if your code already lives in a local folder or you want to work in your existing setup. You need Node 20 or newer, Git, the GitHub CLI signed in, and the Codex CLI signed in. Then:
git clone https://github.com/vworld26/product-to-pr
npm install
npm run dev -- . "Add a way to export a project plan as Markdown"
