en un clic
merge-pr
Merge a PR and update upstream GitHub issues with progress
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Menu
Merge a PR and update upstream GitHub issues with progress
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Full implementation lifecycle with adversarial review using subagents
Address PR review feedback and verify independently
Draft and create a GitHub issue from a description, investigation, or conversation context. Use when a problem is too large for a quick fix, when you want to propose a change for later, or when the user asks to "file an issue", "create an issue", "draft an issue", "open a ticket", or "log this for later". Also useful when another skill (like tune) determines a change is too large and needs to be tracked as an issue instead.
Validate a PR against PR standards before requesting review
Health-check the LifeOS persona layer (files load, /chat matches the Telegram bots per persona, no personal values leak into committed persona files, frontmatter valid) and open every persona doc in Sublime for editing.
On-demand routing health check for /chat. Verifies every model (auto / Sonnet / Opus / Gemma-local / Claude Code) on BOTH text and voice, across every persona, and that messaging a persona in /chat is identical to messaging its Telegram bot.
| name | merge-pr |
| description | Merge a PR and update upstream GitHub issues with progress |
| argument-hint | <pr-number> [--base <branch>] |
Merge the PR named by the leading token of $ARGUMENTS and update all linked GitHub issues with what was delivered.
Arguments. The leading token is the PR number. An optional --base <branch> may follow; it is informational only — the authoritative base is baseRefName from the PR metadata below (the branch the PR actually targets). Default base is main. The base determines whether the post-merge timestamp-normalization step runs (see Step 2).
The PR number is the first whitespace-separated token of $ARGUMENTS (anything after it, e.g. --base <branch>, is stripped here):
gh pr view $(echo "$ARGUMENTS" | awk '{print $1}') --json number,title,body,state,mergeable,mergeStateStatus,reviewDecision,statusCheckRollup,headRefName,baseRefName,additions,deletions,changedFilesgh pr checks $(echo "$ARGUMENTS" | awk '{print $1}') 2>/dev/null || echo "NO_CHECKS"Check that the PR is safe to merge. For each check, determine pass/fail:
OPEN. If already merged or closed, report and stop.mergeable must not be CONFLICTING. If conflicts exist, report and stop..claude/skills/pr-check/SKILL.md and execute its validation checks against the PR. All checks must pass (WARN is acceptable, FAIL is not). Fix any failures if possible; otherwise report what needs to be fixed and stop.reviewDecision from the PR metadata. If CHANGES_REQUESTED, stop and report. If REVIEW_REQUIRED or empty/null (no reviews submitted), escalate to the user. Only proceed if APPROVED or if the user explicitly confirms.If validation fails, stop and report exactly what needs to be fixed. Do not merge.
If validation requires human judgment (e.g., a check is flaky, the PR has unresolved conversations), stop and consult the user with the evidence.
Squash-merge the PR into its base branch and delete the remote branch. gh pr merge targets the PR's own base (baseRefName), so this works for any base. Use only the PR number (first token):
gh pr merge <pr-number> --squash --delete-branch
If the merge fails, report the error and stop.
Normalize commit timestamp (privacy: hides work schedule) — only when the base is main.
After a merge into main succeeds, pull the merge commit and normalize its timestamp to 12:00 UTC on the same date. This matches the post-commit hook behavior, which doesn't run for GitHub-side merges.
git checkout main && git pull origin main
NORM_DATE="$(date -u -d "$(git log -1 --format='%ad' --date=short) 12:00" '+%Y-%m-%dT12:00:00+00:00')"
GIT_AUTHOR_DATE="$NORM_DATE" GIT_COMMITTER_DATE="$NORM_DATE" \
git commit --amend --no-edit --no-verify --date="$NORM_DATE"
git push --force-with-lease origin main
If the force-push fails (e.g., another commit landed), warn the user but do not retry. The merge itself already succeeded.
If the base is not main (a stacked sub-PR landing on an integration branch), skip the normalize-and-force-push step entirely. Force-pushing an amended commit to a shared integration branch would clobber other sub-PRs that may be landing concurrently, and the final integration→main PR's own merge will get its timestamp normalized when it lands on main anyway. The squash-merge into the integration branch is sufficient.
Extract issue references from the PR title and description. Look for:
Closes #N, Fixes #N, Resolves #N (case-insensitive) — the PR fully addresses the issueRelates to #N, Part of #N — the PR partially addresses or relates to the issueFor each referenced issue, fetch the issue with gh issue view <N> --json state,title and post an update:
For closing references (issue should be auto-closed by GitHub):
gh issue comment <N> --body "$(cat <<'EOF'
## Delivered
**PR:** #<pr-number> — <PR title>
### Changes delivered
- <bullet summary extracted from PR description and diff>
This PR fully addresses this issue.
EOF
)"
For partial references:
gh issue comment <N> --body "$(cat <<'EOF'
## Progress Update
**PR:** #<pr-number> — <PR title>
### Changes delivered
- <bullet summary extracted from PR description>
### Remaining work
<What this issue still needs, based on reading the issue body vs. what was delivered. If unclear, state "See issue description for remaining scope.">
EOF
)"
If no issues are referenced, skip this step.
Output a summary:
## Merge Complete
**PR:** #<number> — <title>
**Merged to:** <base branch>
**Issues updated:** <list of issue numbers, or "none">
### Changes
- <bullet summary>
Stop and consult the user when: