commit-pr
Skill517 starsChanged 3 days agoMITView on GitHub
Apply when committing, pushing, opening or updating a PR, writing a pull request, creating release notes, or closing out remote CI. Enforces the opencode-swarm invariant audit, release-note fragment workflow, full validation suite, issue comment requirement, and post-PR lifecycle rules.
- Deletes or force-pushes
- Commits and pushes
We split this skill into the rules it gives an agent
37 rules. 0 are common, 24 are distinctive, and 13 are very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
24
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
Follow every step in order.
- Distinctive: line 23
Before any build, test, push, or PR action, read:
- Distinctive: line 46
If a touched invariant cannot be proven from source and test output, do not push.
- Distinctive: line 50
If invariants 1, 2, or 3 are touched, run all three:
- Distinctive: line 58
If invariant 3 is touched, audit changed source files for subprocess use:
- Distinctive: line 64
If invariant 11 is touched, run:
- Very specific: line 71
If invariant 7 is touched, confirm the writing-tests skill was loaded and that new test seams avoid leaking mock.module.
- Distinctive: line 75
Run before publication work:
- Very specific: line 85
Delete ONLY those three exact publication-cache files.
- Very specific: line 92
If this changeset edited any SKILL.md file's wording, also run file:.swarm/bundled-skills/skill-edit-validation/SKILL.md's …
- Very specific: line 96
Use conventional commit format <type>(<scope>): <description> exactly.
- Distinctive: line 113
Create a pending release fragment and do not calculate a version manually.
- Distinctive: line 131
Before finalizing a release note fragment, verify every concrete reference against the actual codebase:
- Very specific: line 136
Script names: check package.json scripts or scripts/ directory.
- Distinctive: line 140
Remove or correct any reference that does not resolve.
- Distinctive: line 146
Do not manually edit:
- Distinctive: line 156
Run the full validation stack before pushing.
- Very specific: line 247
If a failure looks unrelated, prove it on clean origin/main before carrying it into the PR body:
- Very specific: line 259
If the failure reproduces on main, document it under ## Pre-existing failures.
- Very specific: line 275
If any .github/workflows/*.yml file changed, every third-party uses: must be pinned to a full 40-character SHA.
- Distinctive: line 279
Before opening a PR, verify no local-only files are staged:
- Distinctive: line 285
Prefer a single clean commit for the branch before initial PR publication.
- Distinctive: line 295
If a review cycle is already active and inline comments depend on current SHAs, avoid resquashing until threads are resolved.
- Distinctive: line 297
If pushing to a PR branch owned by another agent or bot, push to the PR's actual head branch:
- Distinctive: line 307
If the PR is from a fork (head repository differs from base repository), GitHub requires explicit workflow approval after every push.
- Distinctive: line 321
Before git push, run both checks:
- Very specific: line 337
Before generating the PR body, read .swarm/issue-reference.json.
- Distinctive: line 380
If HEAD changes, the body is edited, or you rerun validation, REGENERATE this receipt — a stale or mismatched receipt is rejected by the …
- Distinctive: line 418
If a PR already exists for the branch:
- Distinctive: line 420
do not open a second PR
- Very specific: line 422
use ../swarm-pr-feedback/SKILL.md when feedback needs fixes before closeout
- Distinctive: line 423
update the existing PR body when summary, invariant evidence, test counts, caveats, or pre-existing failure notes changed
- Distinctive: line 424
keep the PR draft while follow-up edits are still expected or required checks are still pending
- Very specific: line 426
after any follow-up push or force-push, verify the PR head matches the expected commit and that reported checks belong to the current …
- Very specific: line 444
If a required GitHub Actions job is cancelled and downstream jobs are skipped:
- Distinctive: line 452
if the cancellation looks like orchestration or infrastructure rather than a code failure, rerun the failed or cancelled jobs:
- Very specific: line 464
Do not call the PR green or merge-ready while a required job is cancelled, skipped, in_progress, or otherwise non-green unless the user …
“Common” is measured: kept by at least 6 in 10 of the 6 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
Commit & PR Protocol
Graph-first evidence contract
Before publication, use repo_map diff_context and impact_cone as a final drift check, then verify the direct source, Git diff, and tests. Graph evidence is advisory only. If freshness is stale or inconclusive, confidence is low, source is missing, the language is unsupported/dynamic, the graph is absent, or an action fails, publication decisions rely on the direct evidence.
Follow every step in order. Do not skip steps.
Step -1 - Mandatory invariant audit
Before any build, test, push, or PR action, read:
../../../AGENTS.md../../../docs/engineering-invariants.md
For every touched invariant, prepare concrete evidence for the PR body. The PR body must include:
## Invariant audit
- 1 (plugin init): touched / not touched - <evidence>
- 2 (runtime portability): touched / not touched - <evidence>
- 3 (subprocesses): touched / not touched - <evidence>
- 4 (.swarm containment): touched / not touched - <evidence>
- 5 (plan durability): touched / not touched - <evidence>
- 6 (test_runner safety): touched / not touched - <evidence>
- 7 (test writing): touched / not touched - <evidence>
- 8 (session state): touched / not touched - <evidence>
- 9 (guardrails/retry): touched / not touched - <evidence>
- 10 (chat/system msg): touched / not touched - <evidence>
- 11 (tool registration): touched / not touched - <evidence>
- 12 (release/cache): touched / not touched - <evidence>If a touched invariant cannot be proven from source and test output, do not push.
Required validations for touched invariants
If invariants 1, 2, or 3 are touched, run all three:
bun run build
node scripts/repro-704.mjs
node --input-type=module -e "await import('./dist/index.js'); console.log('dist import OK')"If invariant 3 is touched, audit changed source files for subprocess use:
git diff --name-only origin/main..HEAD | xargs -r grep -nE "bunSpawn\(|spawn\(|spawnSync\(" || trueIf invariant 11 is touched, run:
bun --smol test tests/unit/config --timeout 60000
for f in tests/unit/tools/*.test.ts; do bun --smol test "$f" --timeout 30000; doneIf invariant 7 is touched, confirm the writing-tests skill was loaded and that new test seams avoid leaking mock.module.
Step 0 - Session start hygiene
Run before publication work:
git fetch origin main
rm -f .swarm/evidence/pr_body.md
rm -f .swarm/evidence/commit-pr-validation.md
rm -f .swarm/evidence/publication-evidence.json
git status --shortDelete ONLY those three exact publication-cache files. NEVER broad-delete
.swarm/evidence/*.json — that directory also holds authoritative task/gate
evidence ({taskId}.json), final-council.json, and phase-council records
(issue #2131 finding 4a).
On Windows, prefer temporary save branches over git stash. If you must stash, use git stash push --include-untracked and verify the stash contents.
If this changeset edited any SKILL.md file's wording, also run file:.swarm/bundled-skills/skill-edit-validation/SKILL.md's content-assertion sweep before committing, to catch stale test assertions.
Step 1 - Commit and PR titles
Use conventional commit format <type>(<scope>): <description> exactly.
- description is lowercase and does not end with a period
- allowed types:
feat,fix,perf,revert,docs,chore,refactor,test,ci,build
Choose the PR title type by the main change:
- new capability ->
feat - bug fix only ->
fix - docs or chore only -> non-bump types
The squash merge commit message must match the PR title exactly.
Note: The PR title MUST follow
<type>(<scope>): <description>exactly — CI runsaction-semantic-pull-requestwhich will fail thecheck-titlejob if the format is wrong. Do not deviate from this format.
Step 2 - Release note fragment
Create a pending release fragment and do not calculate a version manually.
Required file shape:
docs/releases/pending/<unique-slug>.mdThe fragment should cover:
- what changed
- why
- migration steps, if any
- breaking changes, if any
- known caveats
Ground-truth verification (mandatory)
Before finalizing a release note fragment, verify every concrete reference against the actual codebase:
- File paths:
grep -r "path/to/file"— confirm each referenced file exists at the stated path. - Script names: check
package.jsonscripts orscripts/directory. - Attribute/variable names: grep for the exact identifier in
src/. - Environment variables: grep for the exact name in
src/and config.
Remove or correct any reference that does not resolve. AI-generated fragments frequently hallucinate paths and names — this step is not optional.
Bot authors (e.g. [bot], Copilot) are exempt from this requirement by CI. The user-visible surface is defined once, in scripts/user-visible-paths.ts, and covers src/, bin/, binaries/, runners/, .github/workflows/, the three native skill trees, package.json, and docs/configuration.md — so a workflow, skills, or docs/configuration.md PR does need a fragment. Tests-, scripts-, examples-, and dependency-manifest-only PRs do not: those paths never reach users.
Do not manually edit:
package.jsonversionCHANGELOG.md.release-please-manifest.json— exception: reconciliation when the manifest desyncs from actual releases (see below)
For the full release-please manifest desync diagnosis and fix protocol, read references/pr-incident-playbook.md.
Step 3 - Mandatory validation suite
Run the full validation stack before pushing. The exact commands may be narrowed only when the repo contract or current task explicitly justifies it in evidence, not by intuition.
Pre-flight
dist/ is not committed (#1047) — do not stage it. Confirm the build succeeds:
bun run build
node --input-type=module -e "await import('./dist/index.js'); console.log('dist import OK')"Tier 1 - quality
Run both linter AND formatter — e.g., bunx @biomejs/biome@<version> check --write . or equivalent — because CI quality gates reject code that passes tests but fails style validation. Pin the tool version to match the version in package.json (@biomejs/biome); unversioned bunx biome resolves to a different version than the CI gate uses. (the repo script bun run lint:ci runs the pinned Biome version; prefer it over invoking bunx biome directly).
bun run typecheck
bun run lint:ci
bun run scripts/check-tool-registration.ts
bun run check:mock-cleanup
bun run check:invariants
bun run check:cross-contamination
bun run check:test-clock
bun run check:runtime-src-refs
bun run check:events
bun run check:retention
bun run check:registry-citations
bun run check:core-events
bun run check:shell-audit
bun run check:trajectory-store
bun run check:test-file-cap
bun run scripts/check-vacuous-assertions.ts
bun run check:pending-fragment
bun run check:gate-portability
bun run check:bare-spawn
bun run scripts/check-config-consumption.ts
bun run check:test-tmpdir
bun run check:bash-portability
bun run check:error-channel-discard
bun run check:path-identity
bun run check:token-formula
(cd scripts/swarm-model && node --test)
bun run package:smokeThe CI quality job also fails closed when either required dependency is not successful before running the expensive checks:
if [[ "$DETECT_RELEASE_RESULT" != "success" || "$RELEASE_OWNER_RESULT" != "success" ]]; then
echo "::error::required dependency failed: detect-release=$DETECT_RELEASE_RESULT, release-owner-guard=$RELEASE_OWNER_RESULT"
exit 1
fiThis list is the FULL blocking CI quality contract (issue #2131 finding 4c):
every quality-job step in .github/workflows/ci.yml plus the package:smoke
pack check. tests/unit/skills/commit-pr-validation-parity.test.ts derives the
list from the workflow — if CI adds a quality step, the parity test fails until
this skill teaches it.
Tier 2 - unit tests
bun run test:unit:ci # CI-equivalent unit gate (quarantine ledgers + retry budget)
bun run test:unit:ci <file>... # scoped mode: run only the listed repo-relative test filesbun run test:unit:ci runs scripts/ci/run-unit-tests-local.ts, the CI-equivalent unit gate with per-platform quarantine ledgers (scripts/ci/quarantined-tests.txt, quarantined-tests-macos.txt, quarantined-tests-windows.txt) and the retry budget. The full serial run is 45–90 min, so use the scoped mode (bun run test:unit:ci <file>...) when the evidence justifies narrowing (e.g. you only touched one module). This closes the gap the hand-rolled loops left (~40% of CI's colocated src/** tests were uncovered).
Tier 3 - integration
bun test tests/integration ./test --timeout 120000Tier 4 - security and adversarial
bun test tests/security --timeout 120000
bun test tests/adversarial --timeout 120000Tier 5 - smoke
bun test tests/smoke --timeout 120000Pre-existing failure handling
If a failure looks unrelated, prove it on clean origin/main before carrying it into the PR body:
git worktree add /tmp/repro-check origin/main
cd /tmp/repro-check
bun install --frozen-lockfile
bun run build
bun --smol test <repo-relative-path-to-failing-test> --timeout 120000
cd ..
git worktree remove /tmp/repro-checkIf the failure reproduces on main, document it under ## Pre-existing failures. Do not silently inherit it.
dist/ is generated, not committed
dist/ is build output and is git-ignored (#1047); do not stage or commit it, and
there is no dist-check drift gate. The authoritative artifact check is package-check,
which runs npm pack and verifies the packed tarball is complete (type declarations,
grammar assets), installs it in a temp project, imports it under Node, and runs the CLI.
A package-check failure is a source / build / package.json#files problem — fix the
source or manifest and rebuild; never "commit dist to make CI green." CI builds dist/
itself (the unit, package-check, and smoke jobs run bun run build), and
release/publish builds from source.
Step 4 - Workflow changes
If any .github/workflows/*.yml file changed, every third-party uses: must be pinned to a full 40-character SHA.
Step 5 - History shape
Before opening a PR, verify no local-only files are staged:
git diff --name-only HEAD origin/main | grep -E '\.(local\.json|vscode|idea)' || truePrefer a single clean commit for the branch before initial PR publication. Resolve the canonical remote first (see "Canonical remote resolution" below), then squash/push:
git fetch <canonical-remote> <base-branch>
git log --oneline <canonical-remote>/<base-branch>..HEAD
git reset --soft <canonical-remote>/<base-branch>
git commit -m "type(scope): description"
git push --force-with-lease -u <canonical-remote> <branch-name>If a review cycle is already active and inline comments depend on current SHAs, avoid resquashing until threads are resolved.
If pushing to a PR branch owned by another agent or bot, push to the PR's actual head branch:
$prBranch = gh pr view <number> --json headRefName --jq '.headRefName'
git fetch <canonical-remote> $prBranch
git push <canonical-remote> "<your-local-branch>:$prBranch" --force-with-leaseFork PR workflow approval
If the PR is from a fork (head repository differs from base repository), GitHub requires explicit workflow approval after every push. CI jobs will remain in "waiting" status until approved:
# List pending runs
gh run list --repo <upstream-owner>/<upstream-repo> --branch <branch-name> --limit 5
# Approve the pending run
gh api -X POST repos/<upstream-owner>/<upstream-repo>/actions/runs/<run-id>/approveThis requires actions: write permission on the base repository. See the fork-pr-operations skill for the full protocol including race conditions, permission requirements, and stale CI verification.
Pre-push: Push Protection and Canonical Remote
Before git push, run both checks:
- Push protection scan — scan for literal secret patterns that trigger GitHub push protection:
git log origin/main..HEAD -p | grep -E 'sk_live|ghp_|xox[abprs]-|AKIA|eyJ|AIza' || true - Canonical remote resolution — push to the canonical-org remote, not a personal fork:
git remote -v # identify the org-owned remote git push -u <canonical-remote> <branch>
For full details, patterns, workarounds, and anecdotes, read references/pr-incident-playbook.md.
Step 6 - PR creation
Before generating the PR body, read .swarm/issue-reference.json. If it exists and
contains a number field, auto-populate Closes #<number> as the first line of the
PR body. If the file does not exist, fall back to the Closes #<issue-number> placeholder.
PR body requirements:
Closes #<issue-number>as the first line when the PR resolves an issue## Summary## Invariant audit## Test plan
CI enforces both the section ORDER (Summary, then Invariant audit, then Test plan) and that each heading is on its own line with nothing trailing but whitespace (see .github/workflows/pr-standards.yml).
Publication-gate evidence
A repository publication gate (.github/hooks/pr-publication-gate.json ->
scripts/copilot-pr-publication-gate.sh) may block gh pr create, gh pr edit,
and gh pr ready until publication evidence exists. Before publishing, write:
.swarm/evidence/pr_body.md— the exact PR body you will publish (must contain## Summary,## Invariant audit, and## Test plan)..swarm/evidence/commit-pr-validation.md— the validation commands you ran and their results..swarm/evidence/publication-evidence.json— the versioned, freshness-bound receipt (issue #2131 finding 4b). The gate verifies it against the CURRENT git state and the EXACT body being published:BODY_SHA256=$(sha256sum .swarm/evidence/pr_body.md | cut -d' ' -f1) cat > .swarm/evidence/publication-evidence.json <<EOF { "schema_version": 1, "state": "validated", "repository": "$(git remote get-url origin)", "head_sha": "$(git rev-parse HEAD)", "body_sha256": "$BODY_SHA256", "validation_commands": ["bun run typecheck", "bun run lint:ci"], "recorded_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)" } EOFpr_numbermay be added once the PR exists (forgh pr edit/gh pr ready). If HEAD changes, the body is edited, or you rerun validation, REGENERATE this receipt — a stale or mismatched receipt is rejected by the gate.
These files live under .swarm/ (runtime state, never committed) and double as the
evidence the gate checks. Keep them current if you edit the PR body or rerun
validation. The CI pr-standards check enforces the same body contract server-side.
PowerShell-safe pattern:
$refPath = ".swarm/issue-reference.json"
$closesLine = if ((Test-Path $refPath) -and ($ref = Get-Content $refPath -Raw | ConvertFrom-Json) -and $ref.number) {
"Closes #$($ref.number)"
} else {
"Closes #<issue-number>"
}
$body = @"
$closesLine
## Summary
- <bullet 1>
- <bullet 2>
## Invariant audit
- 1 (plugin init): not touched - <evidence>
## Test plan
- [ ] <validation item>
"@
$utf8NoBom = New-Object -TypeName System.Text.UTF8Encoding -ArgumentList $false
$prBodyPath = Join-Path ([System.IO.Path]::GetTempPath()) "pr_body.txt"
[System.IO.File]::WriteAllText($prBodyPath, $body, $utf8NoBom)
gh pr create --title "<type>(<scope>): <description>" --body-file $prBodyPath --base mainDetailed reference material moved to .claude/skills/commit-pr/references/pr-publication.md (issue #2907 progressive-disclosure budget).
Step 7 - Existing PR follow-up and closeout
If a PR already exists for the branch:
- do not open a second PR
- inspect unresolved PR feedback surfaces before updating or readying the PR: review threads/comments, requested-changes reviews, CI/check failures, mergeability/conflicts, and whether check data belongs to the current head SHA
- use
../swarm-pr-feedback/SKILL.mdwhen feedback needs fixes before closeout - update the existing PR body when summary, invariant evidence, test counts, caveats, or pre-existing failure notes changed
- keep the PR draft while follow-up edits are still expected or required checks are still pending
- mark the PR ready only after the body is current and required remote checks are green, unless the user explicitly wants it ready earlier
- after any follow-up push or force-push, verify the PR head matches the expected commit and that reported checks belong to the current
headRefOid:
gh pr view <number> --json headRefOid,body,isDraft,state,mergeable,mergeStateStatus,statusCheckRollup,urlUseful commands:
gh pr edit <number> --body-file "$env:TEMP\pr_body.txt"
gh pr ready <number>
gh pr checks <number> --watch --fail-fastDetailed reference material moved to .claude/skills/commit-pr/references/closeout-playbook.md (issue #2907 progressive-disclosure budget), including the pre-queue merge-group CI simulation: before queueing, run file:.swarm/bundled-skills/merge-queue-readiness/SKILL.md per the playbook's Merge queue section.
Step 8 - Cancelled jobs and skipped dependents
If a required GitHub Actions job is cancelled and downstream jobs are skipped:
- inspect the run:
gh run view <run-id> --json status,conclusion,jobs,url- if the cancellation looks like orchestration or infrastructure rather than a code failure, rerun the failed or cancelled jobs:
gh run rerun <run-id> --failed- re-check the PR until required jobs are green:
gh pr checks <number> --watch --fail-fastDo not call the PR green or merge-ready while a required job is cancelled, skipped, in_progress, or otherwise non-green unless the user explicitly accepts that state.
Step 9 - Pre-merge checklist
- invariant audit is complete and current
- required build and validation commands ran for touched invariants
test_runnerwas not used with broad repo-validation scopes- release fragment exists and version files are untouched
dist/was NOT staged (it is generated output, not committed — #1047)- PR body has
Closes,## Summary,## Invariant audit, and## Test plan - if this was review follow-up, the PR body was refreshed to match current evidence
- if the PR resolves an issue, the issue comment was posted with PR link, what changed, how to use it, and migration notes
- if any required job was cancelled and dependent jobs skipped, the run was rerun or the non-green state was explicitly accepted by the user
- for high-risk work (security, isolation, IPC, auth, payments, migrations), an independent adversarial review subagent ran before the final substantive push and all confirmed findings were addressed — if this was not done before pushing, run the review now and force-push a corrected commit before marking the PR ready
- all required CI checks are green before calling the PR merge-ready
Other versions7 projects use a version of this.
Word for word · 1
- zaxbysauce/opencode-swarm★ 517100% same
Edited · 0
None found.
Wrote their own version · 6
- videojs/video.js★ 40ksame name
- samuelclay/NewsBlur★ 7.7ksame name
- fboulnois/skills★ 1same name
- parthsidpara/lazyskills★ 1same name
- pujakesuma/my-claude-skills★ 1same name
- tiantaiyang/claude-skills★ 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 repository66 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- ci-fix-monitorSkill
- codebase-review-swarmSkill
- commit-prSkill
- contributingSkill
- engineering-conventionsSkill
- fork-pr-operationsSkill
- guardrail-patternsSkill
- issue-tracerSkill
- mock-to-internals-migrationSkill
- pr-review-fixSkill
- qa-sweepSkill
- research-firstSkill
- running-testsSkill
- subprocess-safetySkill
- swarm-ci-monitorSkill
- swarm-implementSkill
- swarm-pr-feedbackSkill
- swarm-pr-reviewSkill
- swarm-pr-subscribeSkill
- swarmSkill
- tech-debt-ci-reviewSkill
- test-file-splitSkill
- unswarmSkill
- writing-testsSkill
- brainstormSkill
- clarifySkill
- clarify-specSkill
- codebase-review-swarmSkill
- consultSkill
- councilSkill
- critic-gateSkill
- deep-diveSkill
- deep-researchSkill
- design-docsSkill
- discoverSkill
- durable-session-stateSkill
- editing-skillsSkill
- engineering-conventionsSkill
- executeSkill
- fork-pr-operationsSkill
- graphifySkill
- issue-ingestSkill
- issue-tracerSkill
- orchestrating-subagentsSkill
- phase-wrapSkill
- pre-phase-briefingSkill
- qa-sweepSkill
- research-firstSkill
- rust-crate-ciSkill
- specifySkill
- swarm-ci-monitorSkill
- swarm-implementSkill
- swarm-planSkill
- swarm-pr-feedbackSkill
- swarm-pr-reviewSkill
- swarm-pr-subscribeSkill
- swarm-resumeSkill
- The first 60 shown.
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.

