# Commit Pr

> Mandatory Codex/Copilot publication adapter for opencode-swarm. Use for every GitHub issue assignment that results in code changes, commits, pushes, draft PRs, PR body edits, PR readying, release notes, or CI closeout. Must be loaded before `git push`, `gh pr create`, `gh pr edit`, or `gh pr ready`. Routes to the single canonical source of truth at `.claude/skills/commit-pr/SKILL.md`.

- Skill: `zaxbyhub/commit-pr` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add zaxbyhub/commit-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zaxbyhub/commit-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools, Productivity
- Author: zaxbyhub (https://skillmd.com/u/zaxbyhub)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zaxbyhub/commit-pr

---


# Commit & PR

Use this skill for Codex-side publication work in `opencode-swarm`.

## Source Of Truth

Read and follow [`../../../.claude/skills/commit-pr/SKILL.md`](../../../.claude/skills/commit-pr/SKILL.md) in full before committing, pushing, opening, or updating a PR.

That Claude skill remains the repository's canonical publish protocol. This Codex-native skill is the adapter layer: it tells Codex which tools to use, how to handle existing PRs, and how to finish the post-open lifecycle without drifting from the repo contract.

If instructions conflict:

1. `AGENTS.md`
2. `docs/engineering-invariants.md`
3. `../../../.claude/skills/commit-pr/SKILL.md`
4. this file

## Codex Execution Rules

- Use the available shell execution tool for `git`, `gh`, build, test, and CI commands.
- Use `apply_patch` for manual file edits.
- Use the runtime's parallel-execution capability for independent reads, status checks, and non-conflicting repo inspections.
- Do not stage `.Codex/`, IDE-local files, or unrelated worktree changes.
- Do not open a second PR when one already exists for the branch. Update the existing PR instead.

## Publish Modes

Infer the mode from the user request and branch state:

- `new-pr`: branch is ready to publish and no PR exists yet
- `pr-followup`: a PR already exists and you are addressing review feedback or syncing validation
- `closeout`: a PR already exists and you are updating body text, waiting on CI, marking ready, or confirming merge prerequisites

## Required Follow-Through

### Existing PR updates

If the branch already has a PR:

- inspect unresolved PR feedback surfaces before updating or readying the PR:
  review threads/comments, requested-changes reviews, CI/check failures,
  mergeability/conflicts, and whether check data belongs to the current head SHA
- update the existing PR body instead of creating a new PR
- refresh `## Summary`, `## Invariant audit`, and `## Test plan` when validation counts, caveats, or evidence changed
- verify the PR still points at the pushed branch head after any force-push
- use `$swarm-pr-feedback` when feedback needs fixes before closeout

### Draft vs ready

Default behavior:

- open or keep the PR as draft while follow-up edits are still expected, required checks are pending, or known caveats still need explanation
- mark the PR ready only after the body is current and required remote checks are green

If the user explicitly asks for a ready PR sooner, obey that request and document any remaining CI state clearly.

### Remote checks are authoritative

When the user asks to open, ship, ready, or close out a PR:

1. inspect remote checks with `gh pr view <n> --json statusCheckRollup,...` or `gh pr checks <n>`
2. verify check data belongs to the current `headRefOid` after every follow-up push
3. if a required job is `cancelled` and downstream jobs are `skipped`, inspect the run and rerun failed/cancelled jobs
4. if an obsolete older-head run is already failed or still consuming concurrency, inspect it before cancellation and cancel only when it is no longer the PR head under validation
5. wait for required checks to finish when practical
6. after conflict resolution, verify GitHub reports both `mergeable: MERGEABLE` and `mergeStateStatus: CLEAN`; local conflict-marker cleanup is not enough, and branch drift must appear in the closure ledger when it affected the PR
7. when `gh pr checks` looks stale, inspect the workflow run directly with `gh run view <run-id> --json headSha,status,conclusion,jobs,url`, and keep watching downstream integration/smoke jobs after unit jobs pass
8. if you edit the PR body after checks are green, expect PR Standards/title checks to rerun and re-check before calling the PR green
9. do not call the PR merge-ready while a required check is `cancelled`, `skipped`, `in_progress`, or otherwise non-green unless the user explicitly accepts that state

Recommended commands:

```powershell
gh pr view <number> --json body,headRefName,headRefOid,isDraft,mergeable,mergeStateStatus,state,statusCheckRollup,url
gh pr checks <number> --watch --fail-fast
gh run view <run-id> --json headSha,status,conclusion,jobs,url
gh run rerun <run-id> --failed
```

`dist/` is generated output and is not committed (#1047); do not stage it and there is no `dist-check` drift gate. If `package-check` fails, inspect the CI log: it is a source / build / `package.json#files` problem (an incomplete or unbuildable tarball), not generated-file drift. Fix the source or manifest and rerun `bun run package:smoke` locally.

After a forced install on Windows, `EPERM` while reading refreshed `node_modules`
is usually host friction; rerun the exact focused command with approved access
before treating it as a code failure.

### Issue comment requirement

If the PR closes an issue:

- confirm the issue comment exists with the PR link, what changed, how to use it, and migration notes
- if the PR merged before the comment was posted, add the missing issue comment immediately

## Working Pattern

1. Read `AGENTS.md`, `docs/engineering-invariants.md` as needed, and the canonical Claude `commit-pr` skill.
2. Run the required local validation from the canonical skill.
3. Stage only intended files.
4. Create or update the PR.
5. Refresh PR body text if the branch changed after review feedback.
6. Watch remote checks to a useful conclusion when the user asked for publication or closeout.
7. Verify issue comments, ready/draft state, and merge-readiness claims before finishing.

## Clean-Main And CI Reality Checks

When local validation is noisy or host-limited:

- compare suspicious failures against a clean `origin/main` worktree before blaming the branch
- document proven pre-existing failures in the PR body
- use remote CI as the cross-platform source of truth for merge-readiness

## Final Sanity Check

- one branch, one PR
- PR head matches pushed `HEAD`
- PR body matches current validation evidence
- issue comment exists when the PR closes an issue
- draft or ready state matches user intent
- required remote checks are green, or any remaining non-green state is explicitly explained