issue-to-pr-skills
AGENTS.md0 starsChanged 51 days agoMITView on GitHub
Public skill pack: 10 pipeline station skills (skills/), 37 supporting skills, 17 reviewer personas (agents/), guides (docs/). Consumers install it read-only — keep files portable (relative paths, no machine specifics). Counts are exact and must stay true: skills/ = 47 directories (10 stations + 37 supporting), agents/ = 17 personas. scripts/verify-mirror.js checks the skill set and is the source of truth for that number. This repository enforces a strict two-value version synchronization system: - Folder Version: VERSION / version.json /…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,542 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository52 other files it gives its agents.
- docs/agents.mdAGENTS.md
- skills/humanizer/AGENTS.mdAGENTS.md
- skills/vercel-composition-patterns/AGENTS.mdAGENTS.md
- skills/vercel-react-best-practices/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- api-and-interface-designSkill
- browser-testing-with-devtoolsSkill
- ci-cd-and-automationSkill
- click-path-auditSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- constraint-driven-developmentSkill
- context-engineeringSkill
- create-issueSkill
- debugging-and-error-recoverySkill
- deprecation-and-migrationSkill
- diagnosing-bugsSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- extract-design-systemSkill
- frontend-designSkill
- frontend-ui-engineeringSkill
- git-workflow-and-versioningSkill
- humanizerSkill
- idea-refineSkill
- iiib-iterate-after-buildSkill
- iii-build-planSkill
- ii-plan-issueSkill
- incremental-implementationSkill
- interview-meSkill
- i-pick-issueSkill
- iv-review-build-and-prSkill
- observability-and-instrumentationSkill
- performance-optimizationSkill
- pipeline-triageSkill
- planning-and-task-breakdownSkill
- playwright-cliSkill
- present-prSkill
- quick-fixSkill
- security-and-hardeningSkill
- shipping-and-launchSkill
- source-driven-developmentSkill
- spec-driven-developmentSkill
- tailwind-design-systemSkill
- test-driven-developmentSkill
- using-agent-skillsSkill
- v-babysit-pr-and-mergeSkill
- vercel-composition-patternsSkill
- vercel-react-best-practicesSkill
- verification-before-completionSkill
- vi-close-pipelineSkill
- web-design-guidelinesSkill
The file
We split this AGENTS.md into the rules it gives an agent
5 rules. About 0 are common, 0 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 14
Verify, don't assume: Every skill change must pass the validator (node scripts/validate.js skills/<name> — see scripts/ once added, or …
- Very specific: line 17
Keep site in sync: Run npm run check before submitting changes.
- Very specific: line 26
+0.1(Doc/Small Change): When editing docs, README, scripts, or site styles (npm run version:bump -- --doc). - Very specific: line 41
Every skill in skills/ is copied from the canonical agent home (~/.agents/skills/): the 10 pipeline/system stations (pipeline-triage, …
- Very specific: line 66
Run npm run check before every release commit.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AGENTS.md — working in this repo (Version: 16.1)
What this repo is
Public skill pack: 10 pipeline station skills (skills/), 37 supporting skills, 17 reviewer personas (agents/), guides (docs/). Consumers install it read-only — keep files portable (relative paths, no machine specifics).
Counts are exact and must stay true: skills/ = 47 directories (10 stations + 37 supporting), agents/ = 17 personas. scripts/verify-mirror.js checks the skill set and is the source of truth for that number.
Rules for changes here
- Portability first. No absolute paths, no usernames, no OS-specific homes. Agent homes are referenced as "this repo's
agents/directory". Line endings are LF everywhere, enforced by.gitattributes— never commit CRLF, and never let a working copy's line endings turn into a diff (seeCONTRIBUTING.md). - English only in skill content and reports. (Translations live in forks, not here.)
- One router owns a request — the pipeline's own triage rule applies to issues filed here too: bug reports and feature asks become GitHub issues, small fixes go direct.
- Verify, don't assume. Every skill change must pass the validator (
node scripts/validate.js skills/<name>— seescripts/once added, or validate frontmatter + relative links by hand):namematches folder, description non-empty, every relative file ref and backticked skill ref resolves. - Minimal diffs. Fix the finding, don't restyle the skill.
- Never commit scratch.
scratch/, OS temp, and per-issue work files don't belong in this repo. - Keep site in sync. Run
npm run checkbefore submitting changes.
Versioning & Site Synchronization
This repository enforces a strict two-value version synchronization system:
- Folder Version:
VERSION/version.json/package.json(source of truth). - Site Version:
site/version.json/site/index.html(public site).
Version Bump Policy
+0.1(Doc/Small Change): When editing docs, README, scripts, or site styles (npm run version:bump -- --doc).+1.0(Skill Change): Whenever modifying, adding, or deleting any skill inskills/or persona inagents/(npm run version:bump -- --skill).
Agent NPM Commands
npm run version:status— Displays the comparison board (Folder Version vs Site Version + SHA-256 hashes).npm run version:bump— Bumps the folder version (--skill,--doc, or auto-detect from git diff).npm run sync:site— Regeneratessite/skills.jsonfromskills/, writessite/version.json, and updates site badges.npm run check— Full gate: runs validate + mirror verification + version check + sync check. Plain&&chain, so a failure anywhere fails the command.npm run check:strict— same, plus--strict, which also fails on drift inside the 10 localized stations. Use before a release.npm test— Runs the test suite (scripts/version-sync.test.js).
The 47 mirrored skills are a copy — never hand-edit them
Every skill in skills/ is copied from the canonical agent home
(~/.agents/skills/): the 10 pipeline/system stations (pipeline-triage,
i-pick-issue, create-issue, ii-plan-issue, iii-build-plan,
iiib-iterate-after-build, iv-review-build-and-pr, v-babysit-pr-and-merge,
vi-close-pipeline, present-pr) plus the 37 supporting skills. Canonical is
authoritative for all of them.
Change the skill at the source, then re-sync:
npm run sync # copy all 47 into this pack
npm run check # validate + verify byte-identical + report driftOr per-file: node scripts/sync-from-canonical.js --check reports drift and
writes nothing; drop --check to apply. Note: the localized station files above
intentionally differ from canonical (English-only contracts, portable paths), so
sync:check reports that drift by name and does not fail on it
(scripts/drift-policy.js draws the line: a mirrored skill that drifted always
fails, localized drift fails only under --strict). scripts/verify-mirror.js
(npm run validate:mirror) is the guard that accounts for the localization and
must stay green. Do not silence npm run check with a trailing || echo — shell
precedence made that mask swallow every earlier failure, which is how the gate
came to exit 0 unconditionally.
Run npm run check before every release commit. A hand-edit here is overwritten
on the next sync — this pack already drifted once and was still advertising a
"Station VII" that no longer existed.Not synced on purpose: evals/snapshots/, evals/iteration-*/ (historical baselines) and results.json (local grading artifact). Skills that exist only in canonical are deliberately out of the public pack; adding one means adding it to the list in scripts/sync-from-canonical.js and the identical EXPECTED_SKILLS list in scripts/verify-mirror.js.
The writer and the gate share one rule set. scripts/content-rules.js holds what may be published: no Hebrew characters, no Hebrew reporting language, no machine-specific home path. sync-from-canonical.js applies blocksSync() before copying and verify-mirror.js applies contentViolation() after — so a file can never land in the pack only to be rejected afterwards. blocksSync() is deliberately narrower: it omits the Hebrew-reporting word heuristic, which is a property of the published pack, not of a canonical file (tried and reverted in #50). Adding a rule means adding it to that module, never inline.
The writer and the gate share one rule set. scripts/content-rules.js holds what may be published: no Hebrew characters, no Hebrew reporting language, no machine-specific home path. sync-from-canonical.js applies blocksSync() before copying and verify-mirror.js applies contentViolation() after — so a file can never land in the pack only to be rejected afterwards. blocksSync() is deliberately narrower: it omits the Hebrew-reporting word heuristic, which is a property of the published pack, not of a canonical file (tried and reverted in #50). Adding a rule means adding it to that module, never inline.
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.

