Guides opening and targeting pull requests across fork and owned-repository Git workflows.
npx skills add https://github.com/t-step/bindle-archive --skill fork-pr-flow-t-step
Please help me install this Agent Skill. Skill: fork-pr-flow Source: https://github.com/t-step/bindle-archive/tree/main/skills/fork-pr-flow Command: npx skills add https://github.com/t-step/bindle-archive --skill fork-pr-flow-t-step
gh pr create uses --repo <upstream-owner>/<repo> --base main --head <your-user>:feature/x, preventing the "upstream into upstream" mistake. - Branch discipline: Keeps main as a clean mirror of upstream, branches all work off fresh main, and rebases before opening the PR; optionally enforced with a no-commit-to-branch pre-commit hook. - Self-merge guardrail: The job ends at the open PR — never merge a PR you authored into upstream, including gh pr merge --auto, unless the operator explicitly names the merge. - Owned-repo variant: Covers the single-remote case where you are the upstream, with the same branch discipline but PRs targeting your own origin/main. - Use Case: You finished a feature on your fork of an open-source project. The Skill pushes the branch to origin only, opens the PR against upstream's base branch with a why-led description, and stops — leaving the merge to the maintainers. ## Quick Start Ask the agent to open a pull request from your fork's feature branch back to the upstream repository and confirm the head and base before creating it.High-intent search queries and answers about installing and using this skill.
Push your feature branch to origin, then run gh pr create with --repo <upstream-owner>/<repo>, --base main, and --head <your-username>:<branch>. Always print and confirm the head and base before creating, since gh often defaults --repo to upstream.
This happens when the PR head points at upstream's own branch instead of your fork's branch. Fix it by setting --head to <your-username>:<branch> so the PR goes from your fork's branch to upstream's base branch.
No. Push to origin only, and only when a PR is actually requested. You usually lack rights to upstream, and pushing there is never wanted; the default action is to commit locally and stop unless explicitly asked.
No. Commit access is not review — gh pr merge, gh pr merge --auto, and pushing a merge commit to upstream are all self-approval. Open the PR, report it, and stop; only an operator instruction that explicitly names the merge authorizes it.
Never commit to main directly; keep it as a mirror of upstream/main via git fetch upstream and git merge --ff-only. Branch every unit of work off fresh main, and optionally enforce this with a no-commit-to-branch pre-commit hook.
Yes, with one change: the PR base is your own origin/main instead of upstream/main. Head and base both being origin is correct here — the upstream-into-upstream mistake only applies to forks.
dyad-shRebases the current branch onto upstream changes, resolves conflicts, and pushes.
usesofiaFetch origin/main, merge it into the current branch, resolve conflicts, run tests, and push.
kagentiRebase the current Git branch onto the upstream main branch.
TabooLibPush the current branch to a fork and create a PR to the main repository.