pull-requests

name	pull-requests
description	Guidelines for creating and managing Pull Requests in this repo

Pull Request Guidelines

Attribution Footer

Public work (issues/PRs/commits) must use 🤖 in the title and include this footer in the body:

---

_Generated with `mux` • Model: `<modelString>` • Thinking: `<thinkingLevel>` • Cost: `$<costs>`_

<!-- mux-attribution: model=<modelString> thinking=<thinkingLevel> costs=<costs> -->

Always check $MUX_MODEL_STRING, $MUX_THINKING_LEVEL, and $MUX_COSTS_USD via bash before creating or updating PRs—include them in the footer if set.

Lifecycle Rules

• Before submitting a PR, ensure the branch name reflects the work and the base branch is correct.
  • PRs are always squash-merged into main.
  • Often, work begins from another PR's merged state; rebase onto main before submitting a new PR.
• Reuse existing PRs; never close or recreate without instruction.
• Force-push minor PR updates; otherwise add a new commit to preserve the change timeline.
• If a PR is already open for your change, keep it up to date with the latest commits; don't leave it stale.
• Never enable auto-merge or merge into main yourself. The user must explicitly merge PRs.

CI & Validation

• During active iteration, using ./scripts/wait_pr_checks.sh <pr_number> is optional.
• Before declaring a PR complete, you MUST wait until all required checks pass.
• When you are done coding and want end-to-end readiness waiting, prefer ./scripts/wait_pr_ready.sh <pr_number> (Codex wait first, CI checks second).
• Waiting for PR checks can take 10+ minutes, so prefer local validation first (for this repo: make verify-vendor, make test, make build) to catch issues early.
• If asked to fix an issue in CI, first replicate it locally, get it to pass locally, then wait for required CI checks to pass.

Status Decoding

Field	Value	Meaning
mergeable	MERGEABLE	Clean, no conflicts
mergeable	CONFLICTING	Needs resolution
mergeStateStatus	CLEAN	Ready to merge
mergeStateStatus	BLOCKED	Waiting for CI
mergeStateStatus	BEHIND	Needs rebase
mergeStateStatus	DIRTY	Has conflicts

If behind: git fetch origin && git rebase origin/main && git push --force-with-lease.

Codex Review Workflow

When posting multi-line comments with gh (e.g., @codex review), do not rely on \n escapes inside quoted --body strings (they will be sent as literal text). Prefer --body-file - with a heredoc to preserve real newlines:

gh pr comment <pr_number> --body-file - <<'EOF'
@codex review

<message>
EOF

Handling Codex Comments

Use these scripts to check, resolve, and wait on Codex review comments:

• ./scripts/check_codex_comments.sh <pr_number> — Lists unresolved Codex comments (both regular comments and review threads). Outputs thread IDs needed for resolution.

• ./scripts/resolve_pr_comment.sh <thread_id> — Resolves a review thread by its ID (e.g., PRRT_abc123).

• ./scripts/wait_pr_codex.sh <pr_number> — Waits for Codex to respond to the latest @codex review request. When the PR looks good, Codex leaves an explicit approval comment (e.g., it will say Didn't find any major issues).

• ./scripts/wait_pr_ready.sh <pr_number> — Convenience wrapper that runs Codex waiting first and CI checks second. Use it when you are done coding and want to block until the PR is ready or actionable feedback appears.

When Codex leaves review comments, you must address them before the PR can merge:

1. Address the feedback in your branch.
2. Resolve each review thread before pushing: ./scripts/resolve_pr_comment.sh <thread_id>
3. Push your fixes.
4. Comment @codex review to re-request review.
5. Run ./scripts/wait_pr_codex.sh <pr_number> to wait for the next Codex response (either new comments to address, or an explicit approval comment).

Required Loop Discipline

Completion criteria are strict: you MUST continue this loop until Codex explicitly approves, all Codex review threads are resolved, and all required CI checks pass. You MUST NOT mark work complete earlier.

After a PR is open, you MUST stay in a review loop until those completion criteria are met:

1. Run local validation and push fixes.
2. Request review with @codex review.
3. Run ./scripts/wait_pr_codex.sh <pr_number> and wait for Codex to respond.
4. If Codex leaves comments, address them, resolve each thread, push, and repeat from step 2.
5. Once Codex explicitly approves, run ./scripts/wait_pr_checks.sh <pr_number> and wait for required checks to pass.

The only early-stop exception is when a reviewer is clearly misunderstanding the change intent and further edits would be counterproductive. In that case, leave a clarifying PR comment and pause for human direction.

PR Title Conventions

• Title prefixes: perf|refactor|fix|feat|ci|tests|bench
• Example: 🤖 fix: handle workspace rename edge cases
• Use tests: for test-only changes (test helpers, flaky test fixes, storybook)
• Use ci: for CI config changes

PR Bodies

Structure

PR bodies should generally follow this structure; omit sections that are N/A or trivially inferable for the change.

• Summary
  • Single-paragraph executive summary of the change
• Background
  • The "why" behind the change
  • What problem this solves
  • Relevant commits, issues, or PRs that capture more context
• Implementation
• Validation
  • Steps taken to prove the change works as intended
  • Avoid boilerplate like ran tests; include this section only for novel, change-specific steps
  • Do not include steps implied by passing PR checks
• Risks
  • PRs that touch intricate logic must include an assessment of regression risk
  • Explain regression risk in terms of severity and affected product areas

Upkeep

Once the code is pushed to the remote (even if not yet a Pull Request), do your best to commit and push all changes before responding to ensure its visible to the user. Commits on the working branch are for yourself to understand the change, they do not have to follow repository conventions as the PR body and title become the commit subject and body respectively.

Whenever generating a compaction summary, include whether or not a Pull Request was opened and the general state of the remote (e.g. CI checks, known reviews, divergence).