Pull requests and direct changes in ACP
Choose the right delivery route and understand when ACP opens a draft, ready, or standalone PR.
A Feature owns one pull request
New Plan → Feature gives the planned tickets one shared branch. With GitHub publication configured, ACP opens a draft pull request after the first ticket is pushed, then adds later ticket commits to that same pull request. A completed ticket does not open a second PR. Only after every ticket is done and the integration and oversight gates are satisfied can the Feature PR move from draft to ready.
The Product roadmap is made of child Features, so each child Feature follows the same one-PR model. Automatic merging is a separate opt-in policy; a ready PR does not imply that ACP will merge it for you.
A standalone ticket owns its own PR
A ticket made outside a Feature, including a ticket created through MCP, has its own branch and worktree. If the project has usable GitHub identity and authorization, ACP can open a non-draft pull request when the ticket reaches done. Several independent tickets can therefore produce several pull requests. They do not use the Feature's whole-PR overseer or ACP's Feature auto-merge path.
Some flows change the project directly
Mission Talk, Build, and Change use the build-mode route and can land on the project main branch without a Feature PR. If PR publication is disabled or GitHub setup is incomplete, a ticket can also remain local. The result shown by ACP is the source of truth for that run; neither a ticket title nor an agent response proves that a remote pull request exists.
Before asking an agent to work on important code, decide which review boundary you want. Choose a Feature for a grouped, draft-to-ready pull request. Choose standalone tickets when independent changes should each have their own PR. Inspect any direct change before deploying it.