pre-pr
Skill2 starsChanged 13 days agoMITView on GitHub
Use before creating a pull request or pushing a new PR branch, when repository checks and changed-behavior coverage need verification.
- Commits and pushes
10 other projects use a version of this.
Adopted by
Most recently taken up by
- safe-global/safe-wallet-monorepotheir own version, first seen Nov 9, 2026
- salvo8519/fairmarktheir own version, first seen Nov 8, 2026
- TickLabVN/biopasstheir own version, first seen Nov 2, 2026
- JohnnyMcGee/claude-skillstheir own version, first seen Nov 1, 2026
- plastic-labs/honchotheir own version, first seen Oct 23, 2026
- MichinaoShimizu/kirokutheir own version, first seen Oct 11, 2026
Other versions10 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 10
- mongodb/mongo-go-driver★ 8.5ksame name
- plastic-labs/honcho★ 8ksame name
- TickLabVN/biopass★ 602same name
- safe-global/safe-wallet-monorepo★ 598same name
- asynkron/asynkron-skills★ 32same name
- MichinaoShimizu/kiroku★ 2same name
- Docat0209/SoloForge★ 1same name
- salvo8519/fairmark★ 1same name
- JohnnyMcGee/claude-skills★ 0same name
- nfeuer/project-foundation-kit★ 0same name
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 repository29 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apply-review-findingsSkill
- author-workflow-fanoutSkill
- chain-launcherSkill
- delegateSkill
- design-consultationSkill
- design-fail-closed-gateSkill
- document-releaseSkill
- gistSkill
- goal-promptSkill
- grokbotSkill
- incident-as-codeSkill
- investigateSkill
- learn-captureSkill
- office-hoursSkill
- orion-deep-researchSkill
- oss-loopSkill
- pre-compactSkill
- prove-control-bindsSkill
- prove-deploy-is-liveSkill
- readonlySkill
- reassert-guards-on-rewriteSkill
- reprobe-stale-premiseSkill
- scope-guardSkill
- shipSkill
- tdd-loopSkill
- tools-routerSkill
- triage-fanout-verdictsSkill
- xSkill
The file
We split this skill into the rules it gives an agent
10 rules. 0 are common, 7 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
7
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
- Distinctive: line 17
If no repo-local convention is found, fall back:
- Distinctive: line 31
Check that the current branch is NOT the base branch or any protected branch declared in repo-local config.
- Very specific: line 35
Read the repository's AGENTS.md or CLAUDE.md and CI configuration.
- Very specific: line 37
If the repository declares an existing trusted preflight executable, run it too.
- Distinctive: line 39
Do not install or activate hooks as part of this check.
- Distinctive: line 41
If no repo-local preflight exists, report as INFO: "No repo-local preflight found."
- Distinctive: line 56
If hits are found, report as BLOCKING (secrets are the one advisory pattern that blocks).
- Very specific: line 60
If .claude/pr-config.json exists and declares additional scan patterns:
- Distinctive: line 71
Run each pattern against the diff and report at the declared severity.
- Distinctive: line 73
If no repo-local patterns are configured, skip this step.
“Common” is measured: kept by at least 6 in 10 of the 8 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
Pre-PR Verification
Structured verification pass before creating any PR. Run this BEFORE gh pr create or git push for a new PR.
Step 1: Detect base branch
First check for repo-local PR convention. Look for a declared base branch in:
- Repo-local
AGENTS.mdorCLAUDE.md(some repos use a non-maindefault branch, e.g.develop,release, or a project-specific trunk; never assumemain) .claude/pr-config.jsonif it exists (field:baseBranch)
If no repo-local convention is found, fall back:
git remote show origin | grep 'HEAD branch' | sed 's/.*: //'Report which source determined the base branch.
Step 2: Verify working branch
CURRENT=$(git branch --show-current)Check that the current branch is NOT the base branch or any protected branch declared in repo-local config. If it is, report as BLOCKING.
Step 3: Run repo-local preflight
Read the repository's AGENTS.md or CLAUDE.md and CI configuration. Run
its declared applicable checks (for example, pytest, npm test, bun test).
If the repository declares an existing trusted preflight executable, run it too;
.claude/hooks/pre-commit.sh is one optional convention, not a bundled requirement.
Do not install or activate hooks as part of this check.
If no repo-local preflight exists, report as INFO: "No repo-local preflight found."
Step 4: Secret scan
Scan the diff against the base branch for credential patterns:
git diff <base-branch>...HEADPatterns to check (advisory, not a policy gate):
password,secret,token,api_key,apikey,private_key,auth_tokenfollowed by assignment with a string value- Base64-encoded strings longer than 40 characters that look like keys
- Your secrets manager's documented token prefixes (most managers publish a recognizable prefix for service/personal tokens; add yours here)
If hits are found, report as BLOCKING (secrets are the one advisory pattern that blocks).
Step 5: Repo-local optional patterns
If .claude/pr-config.json exists and declares additional scan patterns:
{
"scanPatterns": [
{ "pattern": "console\\.log", "severity": "WARNING", "label": "Debug logging" },
{ "pattern": "TODO|FIXME|HACK", "severity": "WARNING", "label": "Shipping markers" }
]
}Run each pattern against the diff and report at the declared severity.
If no repo-local patterns are configured, skip this step.
Step 6: File inventory
List all changed files with a one-line rationale:
git diff --stat <base-branch>...HEADFor each file, state what changed and why (based on the diff content and commit messages).
Step 7: Coverage of the diff
Review changed behavior as well as the suite's exit code:
- Identify each changed behavior, invariant, error path, authority gate, state
transition or side effect in
git diff <base-branch>...HEAD. - Name the highest useful test seam already available (unit, API/integration, CLI/hook, migration, or manual proof when automation is inappropriate).
- Map each behavior to a test or observed proof that would fail if it broke. Report WARNING for a missing match, especially for silent failure, fallback, authorization, data integrity and state changes. Existing green tests alone do not establish coverage of the changed behavior.
- Mechanical edits and prose-only documentation corrections need no new tests; report why this review is not applicable. A documented executable recipe or a change to a supported workflow is behavior and still needs a scenario/proof. Respect the current request's authority for any live proof; an absent grant means report the gap, not invoke production or a provider.
Worked example: a PR changes an API's 401 fallback, while its only test exercises
200 success. Report WARNING: 401 fallback has no matching failure-path test at
the API seam, even if the full suite passes. A Markdown spelling correction has
no changed behavior: report INFO: coverage review not applicable; prose-only.
This review is advisory. It does not weaken repository-required checks, convert warnings into approval, or grant push/PR/merge authority.
Output Format
## Pre-PR Report
**Base branch:** <branch> (source: <repo-local | origin default>)
**Current branch:** <branch>
**Files changed:** <count>
### BLOCKING
- [secrets found, protected-branch violation, preflight failure]
### WARNING
- [advisory findings: TODOs, debug markers, large diffs, repo-local patterns, changed behavior without matching proof]
### INFO
- [file inventory, branch state, preflight status]
### Result: CLEAR | ISSUES (<N> blocking, <N> warning)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.

