- name
- github-pr-acceptance
- description
- Use when the user explicitly asks to accept or merge a GitHub pull request and the PR must show as merged on GitHub, not only in local git history.
# GitHub PR Acceptance
## When To Use
Use this skill when the user explicitly asks to accept/merge a pull request on GitHub (not just locally).
## Goal
Ensure the PR is shown as **MERGED** on GitHub, with `mergedAt` and `mergeCommit` populated.
## Workflow
1. Perform local integration first
- Merge intended work into local `main` using repository merge rules.
2. Push `main` to canonical remote
- For this project, canonical remote is `https://github.com/friuns2/codexUI.git`.
3. Verify PR state
- Run:
- `gh pr view <number> --repo friuns2/codexUI --json state,mergedAt,mergeCommit,mergeStateStatus,url`
- If `state` is `MERGED`, stop.
4. If still `OPEN`
- If `mergeStateStatus` is `DIRTY` (common after rebase or cross-repo PR):
- push reconciled branch to PR head ref.
- if still open, create a no-content linkage merge commit on `main` against exact PR head SHA:
- `git checkout main`
- `git merge --no-ff -s ours <pr-head-sha> -m "Merge pull request #<number> from <owner>/<branch>"`
- push `main` again.
5. Final verification (mandatory)
- Re-run `gh pr view ...` and confirm:
- `state: MERGED`
- `mergedAt` is non-null
- `mergeCommit` is non-null
## Notes
- Local merge alone is not enough when user asks for GitHub acceptance.
- Cross-repo PRs may remain open even after equivalent code lands if ancestry/linkage is missing.
- If contributor attribution matters, avoid rewriting PR commit ancestry where possible.
View on GitHub