Take one ticket from branch to merged pull request with an agent

An agent writes the code, tests, and pull request description from a ticket while you keep merge authority.

For anyone who ships code, on any size team · 8 steps · 7 min

How it works today.

You open the ticket, skim the acceptance criteria, then hunt through the repository to find which files the change will touch. You write the implementation, remember to add or update tests, run the suite locally, then craft a pull request description that explains the why and the what. If the ticket was vague you ping the author for clarification, then repeat the cycle.

The actual typing—imports, boilerplate, test scaffolding, PR template fields—is the majority of the elapsed time, but none of it requires your judgment. You are the bottleneck twice: once to understand intent, once to confirm the diff matches it. Everything in between is mechanical.

Before you start.

All of it has to be true, or step one fails in a way that is annoying to debug.

A vertical coding agent with repository access (Cursor, Codeium, GitHub Copilot Workspace, or similar) and permission to read your issue tracker.
Write access to create branches and open pull requests in your repository, granted to the agent or to you acting on its output.
A ticket or issue written with enough detail that you could hand it to a new teammate—acceptance criteria, context, or a reference implementation.
Your repository's contributing guidelines, test commands, and PR template exported as a text file the agent can read.
A local or remote runtime where the agent can execute tests and see output, if your agent does not include a sandbox.

The steps.

01
Point the agent at the ticket and your contributing file
Open the agent interface and paste the ticket URL or body, plus the path to your contributing guidelines. If your agent cannot fetch URLs directly, copy the ticket text in full. Confirm the agent can see the repository structure—most vertical agents clone or index it automatically, but check the file tree appears.
Paste this
```
Read this ticket: [ticket URL or full text]. Follow the contributing guidelines in CONTRIBUTING.md. Propose which files need changes to satisfy the acceptance criteria, and explain your reasoning before writing code.
```
Review the agent's file list and implementation plan
The agent will list files it intends to modify and outline the change. Read this plan against the ticket to catch scope creep or missed edge cases. If the agent suggests touching files outside the ticket's scope, ask why. Approve the plan or give corrective instructions before it writes code.
03
Let the agent write the implementation and tests
Instruct the agent to write the code and corresponding tests in one pass. Most vertical agents will open files, make edits, and stage them. Watch for whether it writes tests at all—if it skips them, stop and explicitly require test coverage that matches your project's norms.
Paste this
```
Write the implementation across the files you identified. Include unit tests that cover the happy path and at least one error case. Follow the existing test patterns in the test directory.
```
Run the test suite and share output with the agent
Execute your project's test command in the terminal or sandbox. If tests fail, copy the failure output and paste it back to the agent with no interpretation. Let the agent read the stack trace and fix its own code. Repeat until the suite passes. If the agent cannot run tests itself, you run them and ferry the results.
05
Ask the agent to draft the pull request description
Once tests pass, prompt the agent to write a PR description that references the ticket, summarizes the change, and notes any decisions a reviewer should understand. If your repository uses a PR template, give the agent that template and ask it to fill each section. Review the description for accuracy—the agent may hallucinate context.
Paste this
```
Write a pull request description for this change. Reference ticket [ticket ID]. Explain what changed and why, following the template in .github/pull_request_template.md. List any breaking changes or migration steps.
```
Create the branch and pull request with the agent's content
If the agent can push branches and open PRs directly, authorize it to do so. If not, copy the branch name and description it generated, then manually create the branch and PR in GitHub, GitLab, or your platform. Paste the agent-written description into the PR body. The pull request is now open and awaiting your review.
Review the diff as you would any teammate's work
Open the pull request and read every changed line. Check that the implementation matches the ticket, that tests actually assert the right behavior, and that no unrelated changes crept in. Leave comments on lines that need revision. If changes are required, you can ask the agent to address your review comments or make the edits yourself.
Merge only after you approve the substance and risk
When the diff is correct and tests confirm behavior, you merge the pull request. The agent never clicks merge. You own the decision to land this code on the main branch, the same as you would after reviewing a human contributor. If your team requires a second reviewer, request that review as usual.

What you keep.

Automating the typing does not move the accountability. These stay with a person.

Approving the implementation plan before the agent writes code, so you catch scope or architecture mistakes early.
Reading the full diff in the pull request and deciding whether it is correct, safe, and complete enough to merge.
Merging the pull request to the main branch—the agent opens the PR but you control what ships.
Judging whether the ticket itself was clear enough, and asking the author for clarification if the agent's questions surface ambiguity.

Once it works.

The first run is the demo. These are where the time actually comes back.

Fire it from an event

Configure a webhook so the agent starts a draft PR automatically when a ticket moves to 'Ready for Development' in your tracker.

Run it on a loop

After merging, feed the closed PR back to the agent as an example for future tickets in the same area of the codebase.

Hand off to another agent

If your agent can post comments, let it reply to review feedback by pushing fixup commits, then notify you when it believes the concerns are addressed.

Scale it wider

Run the same agent flow in parallel across multiple tickets that touch independent modules, then review all the resulting PRs in a single batch.