Skip to content
Leverage AI Developer Support

PR Readiness

Use this page after implementation and local verification, before opening a PR.

Expected Path

Section titled “Expected Path”
  1. Confirm the branch follows Branching And Initiative Work.
  2. Confirm the branch is based on dev unless the task explicitly targeted another base.
  3. Run git status --short and account for every changed or untracked file.
  4. Run git log --oneline dev..HEAD and git diff --name-status dev...HEAD.
  5. Run git diff --check and fix whitespace or conflict-marker issues.
  6. Rerun the most relevant app-local verification after hooks or formatters modify files.
  7. Draft the PR body from .github/pull_request_template.md.

Post-PR Codex Review

Section titled “Post-PR Codex Review”

After opening the PR, request Codex review with @codex review unless automatic Codex review is enabled for the repo.

Use focused prompts for high-risk areas when the branch touches security, privacy, auth, customer-cluster deployment, data persistence, shared contracts, or behavior that could lose data. Example:

@codex review for security regressions, missing tests, customer-cluster boundary issues, and risky behavior changes.

Treat Codex comments as required review feedback:

  • Fix valid findings.
  • If a finding is not applicable, reply with concrete technical reasoning and evidence.
  • Do not leave Codex comments unresolved, hidden, collapsed, or silently ignored.
  • Do not merge while any P0/P1 Codex issue remains unaddressed.

If Codex suggests a fix, a human may use @codex fix .... Any resulting changes still require normal local verification and this PR readiness check again.

The final PR handoff should say whether Codex review was run, automatic, blocked, or still pending.

What To Call Out

Section titled “What To Call Out”
  • Docs-only branches can skip bun run test:local when the app-local type/build checks passed and no runtime behavior changed.
  • Connector lifecycle, auth, CMS boundary, customer-cluster, chat orchestration, eval, or model-policy changes need explicit verification notes.
  • Visual/browser checks should be mentioned when UI behavior changed; if they were not run, say which flow remains unchecked and why.

Canonical Sources

Section titled “Canonical Sources”
  • .github/pull_request_template.md
  • apps/support-dev/src/content/docs/workflows/branching-and-initiative-work.md
  • .agents/skills/pre-pr-readiness/SKILL.md
  • .agents/skills/verification-before-completion/SKILL.md

Official Docs

Section titled “Official Docs”