Skip to main content
See exactly where PRFlow stops and you decide. PRFlow can prepare and review a change, but people keep authority over the repository. The boundaries below are deliberate. They are what makes an autonomous run something you can adopt without giving up control of what lands.

​
Before a Run

  • The spec workflow saves the issue draft to a file and shows you its path — printing the full draft in chat only when you ask — and waits for your explicit approval of those exact bytes before it creates anything.
  • A local run can ask you for clarification, and it asks your client for tool permission as it goes. See Local Permissions.
  • Maintainers decide which configuration, prompt extensions and permission scopes are committed to the repository. A run can only use what you committed.
  • A cloud run starts only for an authorized collaborator or an allowed bot. An outside fork contributor cannot start one. See Security and Trust.

​
During a Run

Grant narrowly

Review each permission request at the narrowest scope that still lets the work proceed. Keep broad shell, filesystem and credential access out of the run unless the workflow genuinely needs it.

Read Blocked before retrying

A Blocked workpad entry names a cause. Read it and resolve it. Retriggering the run without resolving the cause reproduces the same stop.

Treat gaps as decisions

A scope change, a deferred acceptance criterion or a verification that did not run is a decision that needs evidence. It is not an inconvenience to route around.

Watch the writes

PRFlow writes issue comments, branches, commits, pull requests, reviews and follow-up issues, when the active identity has permission. All of it stays visible in Git and GitHub.

​
Pull-Request State

An implementation run opens a draft pull request before its review and documentation work finishes. When the run completes, the default is to publish it as ready for review. Maintainers can configure PRFlow to leave it as a draft instead.
“Ready for review” means the configured workflow completed. It does not mean a person approved the change, that branch protection passed or that the deployment risk is acceptable.

​
The Merge Boundary

PRFlow never merges a pull request. Before you do, work through these:
1

Review the change

Read the code, the tests and the documentation the run produced, the same way you would read a colleague’s pull request.
2

Read the workpad

Check the acceptance-criteria evidence and the PRFlow Reflections section, which is where blockers, deferrals and dropped work are recorded. See Workpads and Resume.
3

Evaluate the review findings

Read the verdict and any remaining caveats. An approval-family verdict is evidence, not proof. See The Review System.
4

Wait for your own checks

Required repository checks and required approvals apply exactly as they always did. See How PRFlow Verifies a Change.
5

Merge or request changes

Use your team’s normal process. This step has no PRFlow equivalent.
This boundary is the point of the design. PRFlow automates the preparation and the evidence gathering, and leaves the irreversible decision with the people who own the repository.