Pull Requests
The inner loop produces code, and the pull request is where a human reviews it and decides. It is the end of the loop, not a step in the middle. Once code exists, three Software Factory screens carry it forward: Pull Requests (review and decide), Deployments (track how it goes out), and the Local Environment (open the agent's working copy). This page is about the first one.
How a pull request comes to exist
The board never opens a pull request on its own. One appears in one of two ways, and ACE links it to the card either way:
- On a connected repository, the agent opens the PR during its run.
- On a from-scratch card, once the work is done, Save & ship creates a fresh repository, pushes the sandbox, and the PR follows.
ACE harvests the pull request rather than owning it. The truth stays live on GitHub or GitLab, and ACE keeps the link between the card and the PR. That is why the card's own Pull Requests section is a jump list, and the real review happens on the Pull Requests screen.
The list
The Pull Requests screen lists pull requests pulled live from every repository connected to the project, GitHub or GitLab, whether the connection uses OAuth or a personal access token. The list is fetched fresh each time you open it. There is no separate sync step.
You can filter by repository, provider, state (Open / Merged / Closed), author, branch, date, and whether a PR is linked to a card. The default view is open pull requests, most recently updated first. Each row opens a review page.
Reviewing: the analysis gate
Opening a pull request gives you three views of it: Files (the diff, file by file), Analysis (ACE's AI code-review report), and History (the audit log of every decision). The page opens on Analysis.
The analysis report is the centerpiece. It is ACE's read on the change, and its state governs what you can do next:
- No analysis yet: a prompt to run one before approving or merging.
- In progress: the view updates on its own when it finishes.
- Complete: the full write-up, with a button to re-run it.
Approve and Merge are both blocked until an analysis has completed at least once. The gate is enforced in the platform, not just hinted at in the interface.
Your three decisions
- Approve: enabled only while the pull request is open and its analysis has completed. It records the approval both in ACE and on the provider.
- Reject: enabled while the pull request is open, with no analysis required. You give a reason, and can optionally post that reason as a comment on the provider.
- Merge: appears only if you hold merge authority, and is clickable only when all of these are true: analysis is complete, there are no conflicts, the provider reports the PR as mergeable, it is still open, and the repository allows at least one merge strategy. You pick a strategy (merge, squash, or rebase, whatever the repo allows) and confirm.
If a pull request has conflicts, Merge is replaced by Solve conflicts, which opens the PR on the provider. ACE does not merge through conflicts.
Rules, per repository
Each connected repository has two independent rules:
- Post to communication channels: mirror the PR's discussion into a connected Slack or Teams channel.
- Analyze automatically: run a code analysis whenever a PR opens or changes on a matching target branch (a comma-separated list, wildcards allowed, empty means every branch).
Turn a pull request into work
A pull request does not have to start from a card. From its review page you can Create Card (opens a card pre-filled from the PR and links the two) or Discuss in chat (a conversation seeded with the PR's context). This is one of the bridges that lets code you found in the wild become tracked work.