open-pr
Skill1 starsChanged 3 months agoMITView on GitHub
Open or update a GitHub pull request with a short, evidence-backed description built from the repo's own PR template, the branch's commit bodies, and real test/lint runs. Use when a branch is finished and needs a PR, when a PR has an empty or stale description, or when the user says "raise a PR" / "open a PR" / "fill the PR description". Labels failing checks pre-existing vs introduced.
- Commits and pushes
62 other projects use a version of this.
Adopted by
Most recently taken up by
- 0xdeafcafe/skillstheir own version, first seen Nov 6, 2026
- pascalorg/editortheir own version, first seen Nov 6, 2026
- Significant-Gravitas/AutoGPTtheir own version, first seen Nov 4, 2026
- angusfretwell/skillstheir own version, first seen Nov 4, 2026
- mongodb/docstheir own version, first seen Nov 2, 2026
- elpiarthera/vantage-startertheir own version, first seen Nov 1, 2026
Used with
Projects with it also use review-change, commit-push and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
thlaureSkillreview-change
Use this skill when the user asks for a code review, a correctness pass, a check before PR, or asks whether a Signalist change follows project conventions.
Also in 4 projects that use this
DataCoveySkillcommit-push
Commit and push the changes made on this chat session to the current branch. Use best practices from Conventional Commits.
Also in 3 projects that use this
Codagent-AISkillimplement-change
Implements an approved change in one continuous session, with tiered test runs. Use when asked to implement a change from its approved definition, or to invoke codagent:implement-change.
Also in 3 projects that use this
saffron-healthSkilladdress-review
Address PR review comments systematically. Use when responding to code review feedback on a pull request.
Also in 3 projects that use this
DockerSkillreview-pr
Review one or more incoming Docker documentation pull requests as a maintainer. Independently validate technical claims, assess editorial fit and information architecture, choose a verdict, and draft exact inline or PR-wide feedback behind a confirmation gate. Use for requests such as "review PR 123", "is this PR correct?", "does this information belong here?", "validate this PR", or "help review backlog PRs". Do not use to maintain or fix a PR you own; use maintain-pr for that.
Also in 10 projects that use this
SentrySkillwrite-tests
Write tests following project conventions. Use when adding new tests or modifying existing ones.
Also in 4 projects that use this
Other versions62 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 62
- Significant-Gravitas/AutoGPT★ 188ksame name
- storybookjs/storybook★ 91ksame name
- pascalorg/editor★ 25ksame name
- dask/dask★ 14ksame name
- polarsource/polar★ 10ksame name
- cloudflare/agents★ 6ksame name
- Kiln-AI/Kiln★ 5.3ksame name
- analogjs/analog★ 3.2ksame name
- raine/workmux★ 3ksame name
- Akylas/OSS-DocumentScanner★ 2.6ksame name
52 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository4 other files it gives its agents.
- bigstep-brandingSkill
- handoffSkill
- start-ticketSkill
- tech-docSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 61 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 19
Stop if: not a git repo, on the default branch, or 0 commits ahead of base.
- Very specific: line 32
Use $BASE (the remote ref) for every diff and test comparison — a local branch is often stale.
- Distinctive: line 44
Never force-push. A failed push isn't fatal — report the error, still compose the body.
- Very specific: line 54
If the file list spans apps this branch never touched, $BASE is wrong — fix it, don't report.
- Very specific: line 77
Don't anchor that filename pattern with $ — vitest appends (8 tests | 1 failed) 927ms.
“Common” is measured: kept by at least 6 in 10 of the 61 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Open PR
Core principle
The commit bodies are the source material. Summarise them; never invent a narrative they don't support. If the commits are thin, say so and ask for the missing "why".
1. Preflight
git branch --show-current && git status --shortStop if: not a git repo, on the default branch, or 0 commits ahead of base. Dirty tree → warn that evidence may not match what's pushed, then continue.
2. Resolve the PR and the base ref
gh pr view --json number,baseRefName,url,body 2>/dev/null
git fetch --quiet origin
BASE_NAME=<baseRefName, else the user's argument, else origin's default branch, else main>
BASE=$(git rev-parse --verify --quiet "origin/$BASE_NAME" >/dev/null \
&& echo "origin/$BASE_NAME" || echo "$BASE_NAME")Use $BASE (the remote ref) for every diff and test comparison — a local branch is often
stale. $BASE_NAME is only for gh pr create --base. Report $BASE in step 9, and mention it
if the local ref differs.
PR exists → edit it. No gh / no remote → compose anyway, deliver via clipboard.
3. Push
git rev-parse --abbrev-ref @{u} 2>/dev/null || git push -u origin "$(git branch --show-current)"Never force-push. A failed push isn't fatal — report the error, still compose the body.
4. Gather facts
git log "$BASE"..HEAD --format='%n===%n%H%n%s%n%n%b' # full bodies
git diff "$BASE"...HEAD --stat
git diff "$BASE"...HEAD --name-only | sortIf the file list spans apps this branch never touched, $BASE is wrong — fix it, don't report.
5. Find the template
First that exists: .github/pull_request_template.md, .github/PULL_REQUEST_TEMPLATE.md,
PULL_REQUEST_TEMPLATE.md, .github/PULL_REQUEST_TEMPLATE/*.md. None → generic body (step 7).
6. Verify
Runner: nx.json → npx nx affected -t lint typecheck test --base="$BASE" --head=HEAD.
Else package.json scripts with the lockfile's package manager (check command -v first, else
npx). Neither → record "no runner detected", skip to 7.
Run each target once, tee to a file, then grep the file. Never re-run to answer a follow-up.
OUT=$(mktemp); npx nx affected -t lint typecheck test --base="$BASE" --head=HEAD \
--skip-nx-cache 2>&1 | sed 's/\x1b\[[0-9;]*m//g' | tee "$OUT" | tail -40
grep -E "Test Files|Tests |Failed tasks" "$OUT"
grep -E "^ *❯ " "$OUT" | awk '{print $2}' | grep -E "\.test\.[jt]sx?$" | sort -uDon't anchor that filename pattern with $ — vitest appends (8 tests | 1 failed) 927ms.
Only if something failed, check whether it's inherited — one run at the merge base, tee'd:
MB=$(git merge-base "$BASE" HEAD); WT=$(mktemp -d)/mb
git worktree add -q --detach "$WT" "$MB"
ln -s "$(git rev-parse --show-toplevel)/node_modules" "$WT/node_modules"
BASE_OUT=$(mktemp)
(cd "$WT" && npx nx run <project>:<target> --skip-nx-cache 2>&1 \
| sed 's/\x1b\[[0-9;]*m//g' | tee "$BASE_OUT" | tail -20)
rm -f "$WT/node_modules" && git worktree remove --force "$WT"
extract() { grep -E "^ *❯ " "$1" | awk '{print $2}' | grep -E "\.test\.[jt]sx?$" | sort -u; }
comm -13 <(extract "$BASE_OUT") <(extract "$OUT") # empty = no regressions from this branchSymlink node_modules in (a fresh worktree has none) and remove the symlink before
git worktree remove. Compare SETS, not totals. Two suite runs per invocation, max.
7. Compose
Fill the template, else:
## Summary
- <3–4 bullets from the commit bodies; root cause first>
## Changes
- `<app>` — <one line>
## Verification
- <runner> — <observed counts>
<!-- generated-by: open-pr -->- Delete non-applicable template sections — never print one to mark it N/A.
- 45-line budget. Over it: merge thin per-app sections into one list, fold the AC verdict into the last Summary bullet, combine Verification lines. Never drop a pre-existing-failure entry or an unticked-box reason.
- Summary ≤4 bullets. Changes: one line per app. Verification: real numbers only.
- Pre-existing failures: a short section only if some exist — target, file, merge-base evidence.
- Tick only what was verified this run; otherwise
- [ ]with— <reason>. - Scope checkboxes from changed top-level paths.
- AC table only if a ticket key is in the branch/commits AND the tracker is reachable.
- End with
<!-- generated-by: open-pr -->.
Title: type(scope): description, <72 chars, matching git log's convention.
8. Deliver
BODY=$(mktemp /tmp/pr-body-XXXX.md)
gh pr create --base "$BASE_NAME" --title "<title>" --body-file "$BODY" # NAME, not $BASE
gh pr edit <number> --body-file "$BODY" # existing PR
pbcopy < "$BODY" # no gh: also print the path + pull/new/<branch> URLA non-empty existing body without the marker is human-written — show it and ask first.
9. Report
PR URL, title, $BASE used, every unticked box and why, any pre-existing failure.
Failure behaviour
| Condition | Behaviour |
No gh / unauthenticated / no remote | Clipboard + path + pull/new/<branch>; never claim a PR was created |
| Push fails | Report the error, still compose |
| PR exists | Edit it (marker rule above) |
| No template | Generic body |
| No runner | "no runner detected" |
| Verification errors/times out | Body emitted, verification marked incomplete + cause |
| Dirty tree | Warn evidence may not match |
| Local base behind remote | Use origin/<name>, say so |
| Default branch / 0 commits ahead | Stop and explain |
Never
- Tick an unverified checkbox, or state an unobserved test count.
- Overwrite a human-written description without asking.
- Invent AC verdicts or claim a tracker was consulted.
- Diff or run
nx affectedagainst a bare local branch when a remote ref exists. - Re-run a suite for an answer the saved output already has.
- Force-push, amend commits, or write inside the repo tree.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

