You open the pull request in the workspace and ask a coding agent to review or fix it. Use Chat on an open pull request to open or start its AI chat.
Where do you connect the repository?
Start with a workspace folder that is a Git repository. Your machine must have access to its remote. For GitHub records, that remote must point to the GitHub repository you want to use.
Open Workspace Settings → Git in the workspace for that project. A workspace means one project in Aiola, and the Git page belongs to it. Under Repository, paste the remote URL when the workspace is not connected.
Status shows Connected or Not connected for that repository. Remote URL shows the repository remote for the connection. The contribution graph shows repository activity for the connected remote.
What can you read on a pull request?
From the workspace GitHub page, open the pull request on the connected repository. That page operates on the active repository you connected. The Pull Requests tab shows state, details, timeline, comments, changed files, and diff statistics. Open a record to inspect its information before starting the AI chat. Use the expanded Checks section when addressing failed checks.
Search, filter by state, or refresh the records on the workspace GitHub page. Select multiple records when a bulk action should apply to them.
The same workspace page has an Issues tab next to Pull Requests. An issue record shows state, labels, details, timeline, and comments.
Local overlays sit on the GitHub records in the workspace. One overlay can mark human review or AI review. Another can mark a possible duplicate, and none of these marks change GitHub.
How do you start the review thread?
Pick Claude Code, Codex, Cursor, Grok CLI, OpenCode, or Antigravity for the review. Each option uses your configured access, your own subscription, and no token markup.
The chat composer lets you select the provider and model. It also offers permission mode, branch controls, and project or new worktree execution. Available controls depend on the provider, and context choices can lock after the thread starts.
Set review instructions under Workspace Settings → Workspace → Instructions. The Pull Request Analysis prompt applies to Chat on a pull request. The custom instructions documentation lists the prompts and their triggers.
Analyze and Fix It are issue actions on the same GitHub page. The first investigates an open issue inside an AI workflow. Fix It asks an agent to implement a fix for that issue. Pull request actions, including the check fixes, are listed in the table below.
| Action | Result |
|---|---|
| Chat | Opens or starts AI chat for an open pull request; becomes Open chat when a chat exists |
| Fix failing checks | Addresses failed checks from the list or the action menu |
| Fix all | Addresses all failed checks from the expanded Checks section |
| Comment | Adds a GitHub comment on the pull request |
| Merge | Merges the pull request when that pull request is eligible |
| Close or reopen | Changes the pull request state from the app when you close it or reopen it |
What can you do with an issue?
You can comment on an issue from the workspace GitHub page. Close or reopen changes the issue state on that same page. Lock or unlock changes conversation locking for the issue. You can close an issue as completed, not planned, or duplicate.
Scan for duplicates compares open issues with available open and closed issues. Enable Auto-close duplicate issues to comment on a match and close it. Leave that setting off to keep the duplicate mark local.
Comment on issues after fix posts the AI summary to the issue. After an analysis, Comment on issues after analyze posts that analysis to the issue. Close issues after fix closes the issue after Fix It succeeds.
What should you check after a fix?
Read the review and compare each finding with the actual diff. When checks fail, use Fix failing checks or Fix all for those failures. After that action, inspect the resulting changes before you accept them. Run the relevant checks before you accept the result. The PR Check Fix prompt applies to Fix all for failing pull-request checks. Edit that prompt under Workspace Settings → Workspace → Instructions when you need different fix instructions.
What do Git settings change?
Set the branch prefix under Branches before an AI workflow creates a branch. Aiola applies that prefix when the workflow creates the branch. The same Git settings decide whether AI actions use worktrees. Analysis and fix prompts belong under Workspace → Instructions, a separate settings page.
Enable Comment on PRs after review to post an AI summary after a review. That setting is distinct from the Chat action on the open pull request. Git settings decide whether those results are written back.
Run app log actions in worktree uses a fresh worktree for App Logs actions. Feedback actions use a fresh worktree when Run feedback actions in worktree is on. GitHub issue actions use a fresh worktree when Run GitHub issue actions in worktree is on.
When should you merge?
Read the updated diff and the check results yourself before you merge. Add a concise GitHub comment that contains only findings you verified. Merge an eligible pull request from the app only after that review is done.
How do you find a pull request across workspaces?
Central GitHub helps when the pull request sits in another connected workspace. It has exactly two tabs, Issues and Pull Requests. Aiola fetches records per workspace, then attaches each workspace ID and name. The combined list keeps every record tied to its owning workspace.
Actions in Central resolve back to the record's owning workspace. That resolution happens before Aiola runs the action. The GitHub documentation describes the workspace page and Central GitHub.
Try it in Aiola: download the desktop app for free. Desktop version 2.0.8 runs on macOS 12 or newer and on Windows 10 or newer. Open your project as a workspace and review the pull request from there.
