Pull Requests & CI
When an agent finishes, the remaining steps are to open a PR, wait for CI, review, and merge. Lattis provides these actions in the same workspace as the agent session.
PR and CI features use Lattis’s built-in GitHub integration. Connect your account once, in Settings › Accounts › GitHub (or during first-run onboarding):
- Click Connect GitHub. Lattis shows a short code.
- Enter the code at github.com/login/device and approve.
That’s it — no GitHub CLI required. If you previously used the gh CLI,
Lattis imports its sign-in automatically on first launch after the update.
With GitHub connected, Lattis reads each branch’s PR and check status and enables the actions below. Without it, branches still work as worktrees — you just won’t see PR state, and PR actions point you at the connect card.
Branch actions
Section titled “Branch actions”Right-click a branch (or use its action menu) for everything you need to move work along:
| Action | What it does |
|---|---|
| Pull Latest | Pull the branch’s remote changes into the worktree. |
| Pull Latest Main | Bring the base branch up to date. |
| Commit / Commit and Push | Commit the worktree’s changes, optionally pushing. |
| Push | Push commits to the remote. |
| Open Pull Request | Create a PR for the branch. |
| Request Review | Ask people or a team to review it (see below). |
| Mark Ready for Review | Flip a draft PR to ready. |
| View PR in Browser | Open the PR on GitHub. |
| Merge Pull Request | Merge it (see below). |
| Close Pull Request | Close without merging. |
| Copy Branch Name / Delete local branch | Housekeeping. |
The menu adapts to context — you’ll see Open Pull Request when there’s no PR yet, and Mark Ready for Review only while a PR is a draft. Request Review appears on a non-draft PR, because GitHub takes no review request for a draft.
Request a review
Section titled “Request a review”When you open a pull request that nobody has been asked to review, Lattis prompts
you to fix that. An agent that runs gh pr create in its own terminal raises the
same prompt, because Lattis detects the pull request on GitHub rather than
hooking its own button. You can also raise it yourself at any time, from the
branch menu or the command palette, with Request Review.
Reviewers are picked in the app, not in a browser tab. The picker opens ranked, with the reason on each row:
| Group | Who it holds |
|---|---|
| Wrote this code | Whoever wrote the lines this PR changes, from your local git history. |
| Reviews your work | Whoever reviewed your recent pull requests in this repository. |
| GitHub suggests | GitHub’s own suggestion. |
| Teams | Your organization’s teams. |
| Everyone else | The rest of the roster. |
The first group uses local repository history to identify people who contributed to the changed code.
Teams need the read:org scope. Connect (or reconnect) GitHub in
Settings › Accounts to grant it. Without the scope the picker hides the Teams
group and the rest of the list works as usual.
After a reviewer requests changes, the Review view drives the fixes and offers Re-request review when every thread is resolved. See Respond to review feedback.
To review the pull requests other people send you, see Code Review.
Reading CI at a glance
Section titled “Reading CI at a glance”Each branch’s PR icon is colored by its state, so you can triage a whole project from the sidebar:
- Green — checks passed and the branch is currently eligible to merge.
- Violet — checks passed; just needs a human review.
- Amber — CI still running.
- Red — blocked: CI failed, conflicts, changes requested, or the branch is behind a protected base.
- Muted — draft.
See Stoplights & Status for the full color key.
Merging
Section titled “Merging”Choosing Merge Pull Request asks you to confirm, then in one step:
Merges the PR using the repository’s default merge method, deletes the remote branch, and removes the local branch and its worktree.
It’s worktree-aware, so merging one branch won’t disturb the other checkouts you have open. Once it’s done, the branch drops out of the sidebar and you’re clear to move on to the next one.
A typical loop
Section titled “A typical loop”- An agent finishes and you Commit and Push, then Open Pull Request.
- Lattis prompts you to Request Review, and you pick the people who wrote the code you changed.
- The PR icon goes amber while CI runs, then violet when checks pass.
- Your reviewer’s copy of Lattis lists the request in PENDING REVIEWS, and one click puts them in the Review layout.
- The reviewer requests changes. Their threads land in your Review view, anchored to the lines they describe.
- You run Auto Fix and push. Lattis replies to each fixed thread with the commit id and resolves it on GitHub. One click re-requests the review. See Respond to review feedback.
- The reviewer approves, and you Merge.
Across multiple branches, the sidebar provides a summary of pull-request activity.
Limitations
Section titled “Limitations”Pull-request features work with repositories hosted on github.com:
- GitHub Enterprise (and any other host) isn’t supported. Lattis will tell you so rather than quietly query the wrong server.
- Forks are supported for PR actions. Lattis looks for the pull request on
the local repository first, then, for a fork clone with no PR of its own, on
the fork’s upstream parent — so reviews, comments, and merges land on
whichever repository actually owns the pull request. The sidebar poll and the
pending-review queue consult the fork parent too, so a fork → upstream pull
request shows in the sidebar and its branch menu like any other. Opening a
new pull request still targets the local repository (a fork-internal PR);
open a fork-to-upstream PR from GitHub (or
gh).