Review And Merge PRs

Review And Merge PRs

Process PRs as a sequential human-in-the-loop merge gate. Work on one PR, make it ready for manual testing, stop for maintainer validation, merge only after approval, then move to the next PR.

Core rule

Do not merge a PR or start deep work on the next PR until the user explicitly validates the current PR in the current conversation. A prior request to review, check, pull, rebase, prepare, or "start" PRs is not merge approval.

Approval must be specific enough to mean the maintainer tested or accepts the current PR, for example: "ok merge", "validé", "merge celle-ci", or "c'est bon pour la #123".

Source of truth

Read these when relevant:

• docs/agents/validation.md
• docs/agents/smoke-tests.md for UI, mobile, navigation, WebView, audio, sync, download, or data-flow changes
• docs/agents/sensitive-areas.md for auth, sync, storage, backup/import/export, native config, releases, external services, or user-owned data
• CONTEXT.md and relevant docs/adr/ files when the PR changes domain behavior or architecture

Inputs

If the user names PR numbers, inspect only those PRs. Otherwise, inspect open PRs targeting master.

Build a lightweight queue first. Do not checkout every PR before processing the first one.

gh pr list --state open --base master --json number,title,headRefName,baseRefName,isDraft,mergeStateStatus,reviewDecision,statusCheckRollup,updatedAt,url

Default queue order:

1. PRs named by the user, in the order given.
2. Otherwise, open non-draft PRs targeting master, oldest first unless the user asks for a different priority.

Before starting the first PR, briefly report the queue and say which PR is first.

Per-PR cycle

Repeat this cycle for exactly one PR at a time.

1. Checkout and update

Fetch and inspect the current PR:

gh pr view <number> --json number,title,body,url,headRefName,baseRefName,isDraft,mergeStateStatus,reviewDecision,comments,reviews,statusCheckRollup,files,commits
gh api repos/smontlouis/bible-strong/pulls/<number>/comments --paginate

Then check it out:

gh pr checkout <number>

If the PR is behind origin/master, rebase it before asking the maintainer to test:

git fetch origin master
git rebase origin/master

If the rebase changes the branch, run validation and push the rebased branch:

git push --force-with-lease

2. Review and fix blockers

Inspect the diff against the target base:

git diff --stat origin/master...HEAD
git diff --name-only origin/master...HEAD
git diff origin/master...HEAD

Identify and resolve, before the manual test handoff:

• merge conflicts;
• red or missing checks that can be reproduced locally;
• action-worthy review comments;
• obvious regressions found in the diff;
• stale generated docs or validation artifacts that would create avoidable conflicts.

If a fix is needed, implement it on the PR branch, run relevant validation, commit, push, and mention the new commit in the handoff.

3. Run automated checks

Run the smallest useful validation set for the PR:

• focused ESLint for touched code;
• yarn format:check when formatting-sensitive files changed;
• yarn typecheck for TypeScript, navigation params, Redux, Jotai, helper, or shared API changes;
• focused yarn test ... for touched tests or helpers;
• resource checks such as CDN curl -I -L or generator commands when the PR changes downloadable resources.

Use full yarn lint, yarn test, or broader agent checks only when the change scope justifies it or focused checks are insufficient.

4. Handoff for manual testing

Stop after the current PR is ready to test. Do not merge and do not move to the next PR.

Give the maintainer a concise handoff:

• PR number, title, and URL;
• branch currently checked out;
• what changed in product terms;
• automated checks run and their result;
• review comments handled or still open;
• risk level and reason;
• exact simulator/manual test checklist;
• explicit next instruction: ask the maintainer to test and reply with approval to merge, or describe what failed.

Do not claim mobile behavior is verified unless you actually ran a simulator/emulator or inspected a real device flow. If simulator testing is expected from the maintainer, say that clearly.