fork-pr-operations

Manages fork pull request workflows including workflow approval, force-push protocol, and stale CI verification.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/pandejesal/drone-nav-sar --skill fork-pr-operations-pandejesal
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fork-pr-operations
Source: https://github.com/pandejesal/drone-nav-sar/tree/main/.swarm/bundled-skills/fork-pr-operations
Command: npx skills add https://github.com/pandejesal/drone-nav-sar --skill fork-pr-operations-pandejesal

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Fork pull requests face stricter GitHub security defaults than same-repo PRs: CI jobs stay in "waiting" status until approved, rebases require careful force-push handling, and bot reviewers generate confusing multi-round feedback. This Skill provides the operational patterns to handle these fork-specific lifecycle issues. ## Core Features & Use Cases - Workflow Approval: Approve pending GitHub Actions runs for fork PRs using gh api, including retry logic for the race condition where the run object is not yet created. - Safe Force-Push & Rebase: Enforce --force-with-lease over bare --force, with a standard rebase workflow against upstream/main and conventional remote naming (origin/upstream). - Stale CI Verification: Confirm that check data matches the current PR head SHA before canceling obsolete runs, plus guidance for handling multi-round bot reviews. - Use Case: After pushing a rebased branch to your fork, CI shows "waiting". Use this Skill to list pending runs, approve the workflow via the GitHub API, and verify the checks reference the new head SHA. ## Quick Start Approve the pending CI workflow run for my fork PR and verify the checks match the current head SHA.

Frequently Asked Questions about fork-pr-operations

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I approve a GitHub Actions workflow run for a fork PR?

Approve a fork PR workflow run with `gh api -X POST repos/<owner>/<repo>/actions/runs/<run-id>/approve`. First list pending runs with `gh run list --branch <branch>`, and wait a few seconds after pushing since the run object may not exist yet.

Why is my fork PR CI stuck in waiting status after pushing?

GitHub requires explicit workflow approval for fork PRs as a security default, so CI jobs remain in waiting status until a user with write access to the base repository approves the run. Fork owners without upstream write access cannot approve runs themselves.

Should I use git push --force or --force-with-lease?

Always use `--force-with-lease`, never bare `--force`. The lease check verifies the remote tracking branch matches your local expectation, so it fails safely if a collaborator pushed changes instead of overwriting their work.

How do I rebase a fork PR branch against upstream main?

Fetch the canonical repository with `git fetch upstream`, run `git rebase upstream/main`, resolve any conflicts, then push with `git push --force-with-lease origin <branch>`. The PR head SHA changes and CI re-triggers, subject to fork workflow approval.

How do I check if CI results are stale after a force-push?

Get the current PR head SHA with `gh pr view <number> --json headRefOid` and compare it against check data from `gh pr checks`. Only cancel runs after confirming they do not belong to the current head SHA.

Why does a bot reviewer post a new review after every push?

Automated bot reviewers post one review per push by design, so N pushes produce N reviews. Ignore bot APPROVE rounds, scan only for newly raised findings compared to prior rounds, and treat human reviewer findings as binding.