fork-and-pr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited fork-and-pr (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Walk a contributor through the standard "fork + branch + commit + push + PR" flow against a GitHub repo they don't have write access to. The user knows what they want to change; this skill codifies the boring gh/git syntax around it so they don't have to remember it.
Trigger when the user wants to contribute upward to a repo they don't own. Common phrasings: "I want to make a PR to X", "contribute a fix to X", "fork and PR", "open a PR against the upstream X repo", or right after a git push fails with 403 on a clone of someone else's repo.
Skip when:
git push + gh pr create – no fork needed).gh itself (Resource protected by organization SAML enforcement). That's a one-time per-org token authorization at https://github.com/settings/tokens, not a per-PR step. Tell them to grant SSO on their gh CLI token and retry; don't try to drive that through this skill.Usually one or more of:
owner/name or full URL, e.g. SalesforceCommerceCloud/plugin_sitemap).If the upstream repo isn't named, ask. If the intent isn't named, ask before step 3 (branch naming) – not before steps 1–2.
The skill runs as five steps with a deliberate pause between steps 3 and 4. Steps 1–3 set up the workspace; the user makes their edits and commits; steps 4–5 publish.
Figure out which of four starting states the user is in. Run, in the directory the user is operating from:
git rev-parse --show-toplevel 2>/dev/null
git remote -v 2>/dev/null
gh repo view <upstream> --json viewerPermission,parent 2>&1Interpret:
git rev-parse fails) → state A: no clone yet.https://github.com/settings/tokens; don't try to fork through it.For state A or B, run:
gh repo fork <upstream> --clone --remote--clone clones the fork into the current directory if state A; if state B (already in a clone of upstream), gh swaps origin to point at the new fork and renames the existing remote to upstream automatically. --remote ensures the rename happens.
For state C (fork on GitHub but not cloned locally), gh repo clone <user>/<repo> then git remote add upstream <upstream>.
For state D, no-op.
After this step, git remote -v should show origin = user's fork, upstream = the target repo. Confirm before proceeding.
Suggest a branch name based on the user's stated intent. Conventions vary by upstream repo, but reasonable defaults:
fix/<short-slug> for bug fixesfeat/<short-slug> for featureschore/<short-slug> for maintenance/dependency/cleanupdocs/<short-slug> for docs-only changesIf the upstream repo has a CONTRIBUTING.md with a different convention, follow that instead. Run:
git checkout -b <branch-name>This is the handoff. Tell the user explicitly:
"Branch<name>is ready. Make your edits, commit them (git add <files>thengit commit), and tell me when you're done – I'll push and open the PR."
Then stop. Do not poll git status or proactively check on their progress; wait for them to come back with "done", "committed", "ready", or similar.
While paused, if the user asks code questions or wants help with the change itself, that's a different task – help them, but don't push or open the PR until they say they're done.
When the user confirms they've committed:
git push -u origin <branch-name>
gh pr create --repo <upstream> --web--web opens the PR creation page in the browser with the branch and base pre-filled. This is preferable to authoring title/body on the CLI for first-time contributions to a repo, because the upstream may have a PR template (.github/PULL_REQUEST_TEMPLATE.md) that only renders in the web UI.
If the user explicitly wants to skip the browser, drop --web and gh will prompt for title and body inline – or pass --title / --body directly if the user already knows what they want.
gh pr create. Confirm by checking gh repo view --json viewerPermission.gh auth status will show which one is active. The fork lands under the active account. If they want it under a different account, gh auth switch first.master, develop): gh pr create auto-detects it. Don't hardcode main anywhere.gh repo fork is idempotent (it'll reuse the existing fork) but won't sync it. If their fork is stale and they want a clean branch off current upstream, git fetch upstream && git checkout -b <branch> upstream/<default-branch> before step 4.gh (gh auth login – one-time setup, not per-PR).gh tokens (per-org, browser-driven, one-time).gh printed and stop. Don't ask follow-ups.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.