From requirements to a merge-ready PR with coding agents

A coding agent can make a convincing-looking change long before anyone knows whether it solves the right problem. The useful workflow starts with a requirement you can test and ends with a reviewed PR whose current head has passed the repository's checks. It does not end when the agent says “done”.

Agent Bridge keeps the conversation and provider workstream available. The coding agent still uses its native tools; repository instructions and installed engineering Skills guide its decisions. Farstax manages the workspace around that work, not a separate code-review or PR engine.

The example below is a suggested conversation, not a claim that a particular PR was opened or tested.

1. Check which instructions the agent can use

Ask your agent to inspect the repository and its own environment before delegating:

In owner/repo, find any AGENTS.md instructions and check which Agent Bridge engineering Skills are actually installed and available to your CLI. Tell me what you found before changing files.

Agent Bridge bundles Skills including requirements-to-acceptance, red-green-refactor-tdd, release-readiness-review and delivery-directives. Bundled does not necessarily mean installed or discoverable by every provider. The OSS Skills manager can verify and repair local installations; the active provider must still use the instructions. A customer's repository may not have an AGENTS.md at all.

2. Discuss the requirement before implementation

Suppose a job-status endpoint sometimes claims success after a job fails. “Add a retry” is a tempting instruction but may conceal the actual defect.

Our job-status endpoint occasionally reports success after failure. Investigate the existing behaviour with me. Define the correct user-visible outcome, non-goals, affected state and authority boundaries, plausible failure modes, and how we will prove the change. Create a focused issue once the acceptance criteria are agreed. Don't code yet.

The requirements-to-acceptance Skill keeps this discussion proportionate. An acceptance criterion might be: “The endpoint reports success only after a durable successful outcome; repeated reads do not execute the job again.” It is specific enough for a failing regression test and a reviewer to challenge.

3. Let the provider implement a bounded change

Once the issue is agreed:

Implement that issue in owner/repo. Follow the repository's instructions and the available engineering Skills. Use a focused regression test and make the smallest correct repair. You may take routine engineering decisions, but don't merge, deploy, or alter credentials. Open a draft PR when the diff is ready for review.

For a behaviour change, the red–green–refactor Skill requires an observed failing test (RED), a minimal passing change (GREEN), and refactoring only if useful. If the cause is unknown, systematic debugging comes first. The agent should also check equivalent callers and paths for the same defect class, not just the example that first exposed it.

The provider runs its normal CLI, tools and any appropriate native subagents. Agent Bridge owns durable turns, routing, cancellation, delivery and continuation—not a parallel engineering Worker.

4. Review the draft PR against the issue

Ask for a draft PR with a meaningful diff, the linked issue, relevant test evidence and material risks. Git worktree isolation is useful for substantial or overlapping work, not compulsory for every edit.

Review it. Independently start from the issue and the current draft PR head. Challenge the user-visible result, the actual implementation, permissions, failure paths and test evidence. Return PASS or specific findings.

The release-readiness review Skill prefers a fresh, context-isolated reviewer rather than the implementer endorsing their own plan. A real finding goes back to the implementing agent for a focused repair and a fresh review of the changed head. Green local tests do not substitute for that review.

5. Move from draft to a qualified, merge-ready PR

This transition matters. In Agent Bridge OSS and Farstax Platform, GitHub CI is configured to skip its principal PR verification job while the PR is a draft. A draft with no red checks is not a passed candidate.

After the independent review has passed and its findings are resolved, mark the PR ready for review. Let the required GitHub checks run against the exact final head. Verify the check results and mergeability against current main, then report any outstanding approvals or branch protections. Stop before merging.

Wait for the real checks to finish. For these two repositories, qualification also covers more than focused tests, and the exact job definitions live in their respective CI workflows. Another repository may have a different policy; inspect it rather than assuming a universal test command.

If the candidate changes again, confirm the evidence that depends on its old head is refreshed. The finished handover should link to the actual issue and PR and identify the review verdict, RED/GREEN evidence, required checks, mergeability and any remaining blocker. Do not invent outputs to complete a demonstration.

6. Decide separately whether to merge or deploy

A merge-ready PR is the finish line for this example. In repositories where delivery directives are installed, ship it means the agreed implementation-through-merge process and review it means the independent review contract. release it and deploy it are distinct guarded actions. These are instructions, not new GitHub or host privileges; effective credentials and repository rules still apply.

You can keep the entire discussion in Telegram. The commands guide covers provider switching, side questions, interruption and retaining a separate workstream for each project. To start from a new Farstax workspace, see the getting-started guide.