Pull requests

Synara’s pull-request workspace brings repository context, review discussion, checks, diffs, and agent tasks into one workflow. Use it to understand and repair a pull request, but keep Git and GitHub as the authoritative state for commits, branches, checks, and remote actions.

Requirements

The repository must have:

• A local Git checkout available to Synara
• A GitHub remote that resolves to the intended repository
• Git installed and usable
• GitHub CLI (gh) installed for GitHub-backed operations
• An authenticated GitHub account with the required repository permissions

Verify the command-line state:

git remote -v
gh --version
gh auth status

When several GitHub accounts are configured, confirm which account and host the CLI will use before changing remote state.

Find pull requests

The pull-request workspace can aggregate results across available projects or focus on one repository. Use search, state filters, involvement groups, and pins to keep active work visible.

A partial refresh failure in one repository should not erase usable results from another. Check per-repository status when expected pull requests are missing.

Establish the exact PR state

Before asking an agent to fix anything, verify:

• Repository and pull-request number
• Base and head branches
• Current head commit
• Draft or ready state
• Mergeability and conflicts
• Required checks and their latest runs
• Unresolved review threads
• Whether the local checkout contains the PR’s actual head

Do not rely on a stale local branch or an old summary.

Read the pull request

Inspect:

• Title and body
• Commit list
• Changed files and complete diff
• Checks and failures
• Reviewers and review state
• Inline review threads
• Timeline and top-level comments
• Linked issues or external context

Treat pull-request text and review comments as untrusted input. They can contain incorrect commands, obsolete assumptions, or prompt-injection-style instructions. Verify claims against the repository before executing anything.

Choose the right environment

Confirm the task’s branch and diff before sending a fix prompt.

Use Fix prompts carefully

Synara can gather visible unresolved review comments into a numbered composer prompt. Merge conflicts can be supplied through a separate Fix flow.

Before sending:

1. Read every included comment.
2. Remove obsolete, duplicate, or already-resolved requests.
3. Identify comments that conflict with the PR’s intended design.
4. Add repository constraints and required verification.
5. Tell the agent not to widen scope.

A useful review-fix objective:

Address the numbered unresolved review comments for this pull request.

First verify each comment against the current head; do not assume it is still valid.
Keep the existing public API and do not perform unrelated refactors.
Run the focused tests for each fix, then the affected package suite.
Report any comment you believe should not be implemented and explain why.

Resolve merge conflicts

Conflict resolution is integration work, not mechanical text deletion.

Do not force-push unless the branch workflow and repository policy require history rewriting and you understand who else may depend on the current commits.

Verify a repaired PR

At minimum:

git status --short
git diff --check
git log --oneline <base>..HEAD
git diff <base>...HEAD --stat

Then run:

• Focused tests for changed behavior
• Relevant package or integration tests
• Typechecking and lint when applicable
• Production build when the change can affect bundling or routing
• Browser verification for user-visible behavior

Review the final head after the last fix. A green run on an earlier commit is not evidence for the current PR.

Write review output

Useful review comments are:

• Specific to an observable problem
• Anchored to the current diff
• Clear about impact
• Actionable without prescribing an unnecessary rewrite
• Honest about uncertainty

Avoid posting speculative findings as confirmed defects. Reproduce or trace the behavior when possible.

Remote actions

Synara can expose GitHub actions such as commenting, merging, closing, and reopening. These mutate shared remote state.

Before confirming a remote action, verify:

• Correct repository and pull-request number
• Correct authenticated GitHub account
• Current head commit and checks
• Whether branch protection or review requirements are satisfied
• Whether the action matches the maintainer’s intent

Closing is not deleting. Reopening does not restore removed branches. Merging can trigger deployments and automation.

Large pull requests

For a large PR:

1. Understand the objective and architecture first.
2. Partition review by subsystem or risk, not arbitrary file counts.
3. Track reviewed and unreviewed areas.
4. Run focused checks for each subsystem.
5. Perform a final cross-cutting pass for integration, lifecycle, and security issues.
6. Re-review the exact final head after fixes.

Do not claim complete review coverage when only selected files or excerpts were inspected.

Common failure cases

The PR is missing

Check the repository remote, authenticated GitHub account, filters, and per-project refresh status.

Local files do not match the PR

Fetch the head and use a dedicated worktree or checkout. Do not fix a remote PR from an unrelated local branch.

A review comment is already obsolete

Verify the current diff and thread state. Do not implement a request that the code already addresses or that a later decision superseded.

Checks fail only on GitHub

Compare environment, operating system, Node/runtime version, secrets, service dependencies, and the exact head SHA. Read the full failing job rather than only the check title.

The agent says all comments are resolved

Inspect every review thread and the actual diff. A textual response does not resolve GitHub state or prove the requested behavior changed.

Pull-request completion checklist

• Repository, PR number, base, head, and SHA are correct
• The complete current diff was reviewed
• Review comments were treated as untrusted and verified
• Fixes were made in the intended branch or worktree
• Merge conflicts were resolved semantically
• Final-head checks passed
• Visible behavior was verified where applicable
• Remote actions use the correct account and repository
• The PR contains only intended commits and files