---
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.