skill-builder
Skill1 starsChanged 4 months agoMITView on GitHub
Build a new Agent Skill that follows the agentskills.io specification and best practices — slim `SKILL.md` (≤ 200 lines / 5K tokens), valid kebab-case `name`, imperative `description` under 1024 chars, progressive disclosure via `references/`, bundled `assets/` and `scripts/`, and an MIT `LICENSE`. Use this skill whenever the user asks to create, scaffold, build, write, or author a new Agent Skill — including phrasings like "build a skill for X", "scaffold a new skill", "create an agent skill", "make me a skill that does X", "write a SKILL.md for ...", or "I want to publish a skill on agentskills.io". Also use when reviewing or refactoring an existing oversized `SKILL.md` (a sign that detail should be moved to `references/`).
74 other projects use a version of this.
Adopted by
Most recently taken up by
- Kikobazz123/lordgen-skill-buildertheir own version, first seen Nov 8, 2026
- AsiaOstrich/EngramGraphtheir own version, first seen Nov 8, 2026
- shetengteng/skillix-hubtheir own version, first seen Nov 8, 2026
- davidgfolch/AI-job-searchtheir own version, first seen Nov 8, 2026
- RKelln/hermes_skillstheir own version, first seen Nov 7, 2026
- beCyborg/jadlis-skill-buildertheir own version, first seen Nov 6, 2026
Used with
Projects with it also use contract-test, literature-research and 9 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.
squall-chuaSkillcontract-test
Test a running API against its own contract — OpenAPI, GraphQL, protobuf, or AsyncAPI — from the outside, and report every drift between what the contract promises and what the API does.
Also in 3 projects that use this
nickjwellsSkillliterature-research
Search academic literature and perform deep research reviews. Use when user asks to search PubMed, find academic papers, or do literature reviews.
Also in 3 projects that use this
nopandererSkillcommit-and-push
Automatically analyze git changes, generate Conventional Commits compliant commit messages, commit changes, and push to remote in a single automated workflow. Use when the user invokes /commit-and-push or explicitly requests to automatically commit and push changes following Conventional Commits format (feat:, fix:, docs:, etc.). This skill provides a fully automated git workflow without manual intervention.
Also in 3 projects that use this
MicrosoftSkillskill-reviewer
Review skill PRs with structured severity-rated feedback covering token budgets, routing conflicts, and repo conventions. WHEN: \"review skill\", \"review skill PR\", \"review skill changes\", \"check skill quality\", \"skill PR feedback\".
Also in 3 projects that use this
SkillPilotCHSkilllevel-up
Eine Automatisierung pro Woche finden, scopen, shippen. Output landet als proposed-Eintrag in cadence.md mit konkreten Implementations-Schritten.
Also in 3 projects that use this
MicrosoftSkillexcalidraw-diagram
Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.
Also in 4 projects that use this
Other versions74 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 74
- yusufkaraaslan/Skill_Seekers★ 15ksame name
- block/berd★ 1ksame name
- boshu2/agentops★ 453same name
- metaskills/skill-builder★ 112same name
- AsiaOstrich/universal-dev-standards★ 84same name
- Amazon-Quick/Amazon-Quick-official-catalog★ 50same name
- nateherkai/a-bunch-of-skills★ 41same name
- clasen/Skills★ 40same name
- sanqi-cd/Sanqi-Skills★ 28same name
- arctan303/creator.skill★ 19same name
64 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 repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-auditSkill
- autodreamSkill
- deep-discoverySkill
- generic-by-designSkill
- gitops-cd-developerSkill
- gitops-pipeline-developerSkill
- golang-script-developerSkill
- humanizerSkill
- information-architectureSkill
- interactive-deck-builderSkill
- javascript-script-developerSkill
- linux-script-developerSkill
- makefile-script-developerSkill
- plan-interviewSkill
- pre-commit-setupSkill
- python-script-developerSkill
- qaSkill
- teacher-modeSkill
- terraform-module-developerSkill
- typescript-script-developerSkill
- ui-deslopSkill
- xquik-x-dataSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. 0 are common, 4 are distinctive, and 10 are very specific to this project.
0
Common
Most of the 65 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
Create new Agent Skills that follow the agentskills.io spec and the official best practices.
- Very specific: line 46
Every skill is a folder with a SKILL.md.
- Very specific: line 75
Don't gate the immediate task: Always finish what the user asked for *first*, then make the suggestion at the end of your reply.
- Distinctive: line 81
Ground the skill in real expertise: Do not generate from "best practices for X" — the result will be vague boilerplate.
- Very specific: line 100
Optimize the description with eval queries: before publishing — write 8-10 should-trigger and 8-10 should-not-trigger prompts and run them …
- Very specific: line 134
Use bash scripts/new-skill.sh <name> "<desc>" to scaffold, then edit.
- Very specific: line 135
Keep SKILL.md ≤ 200 lines / 5,000 tokens.
- Distinctive: line 137
Write descriptions imperatively ("Use this skill when..."), with casual phrasing variants the user actually types.
- Very specific: line 139
Add an MIT LICENSE to match this repo.
- Very specific: line 140
Run bash scripts/validate-skill.sh <skill-dir> and iterate until 100%.
- Very specific: line 141
Run an eval pass on the description before publishing (see references/description-optimization.md).
- Very specific: line 142
Keep skills coherent — one skill per coherent unit of work.
- Distinctive: line 148
Use vague descriptions ("Helps with X", "This skill does Y").
- Distinctive: line 151
Add features the skill doesn't need (don't over-engineer).
“Common” is measured: kept by at least 6 in 10 of the 65 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
Skill Builder
Create new Agent Skills that follow the agentskills.io spec and the official best practices.
When to use
- The user asks to create, scaffold, build, or write a new Agent Skill.
- The user wants to publish a skill or refactor a bloated
SKILL.md. - A task chain ends in "and put it in a skill so I can reuse it across projects".
- The auto-suggest hook (
scripts/task-tracker.py) fires a system-reminder noting that a similar task has been asked 3+ times — propose using this skill to package it. - Self-monitor mode (always-on, even without the hook): track requests within the active conversation. When the user asks 3 substantively-similar tasks in a single session — the same kind of artifact, the same domain, the same workflow — proactively offer to package the recurring pattern as a skill. See Self-monitor mode below for the exact heuristic.
Required structure
Every skill is a folder with a SKILL.md. Optional directories carry detail loaded on demand:
<skill-name>/
├── SKILL.md # required: frontmatter + slim instructions (≤ 200 lines / 5K tokens)
├── LICENSE # MIT to match this repo
├── references/ # detailed docs the agent loads only when needed
├── assets/
│ ├── templates/ # - copy-edit starting points
│ └── examples/ # - full reference implementations
└── scripts/ # bundled executables (validators, scaffolders, processors)Frontmatter must include name (kebab-case ≤ 64 chars, matching folder) and description (≤ 1024 chars). See references/spec.md for the full field list and naming rules.
Self-monitor mode
The scripts/task-tracker.py hook only fires in sessions started after it was installed (Claude Code reads settings.json once per session). To make the loop work even in the current session, this skill instructs you — Claude — to do your own pattern-tracking from conversation context:
The rule. As you work, mentally tally: has the user asked for the same kind of task in this conversation already? "Same kind" means the same artifact (script / Makefile / doc / migration / etc.) and the same domain or workflow shape — not just the same word appearing twice.
- 2nd similar request — note it silently, finish the task as asked.
- 3rd similar request — pause and propose:
"I notice this is the third time you've asked for [pattern]. Want me to package this as a reusable skill via
skill-builder? I'd runbash skill-builder/scripts/new-skill.sh <name> "<description>"and fill in the references and templates from the patterns we've used. Say yes/no."
Don't auto-create. The user must confirm. If they decline, drop the suggestion and don't bring it up again unless a clearly-new pattern emerges.
Don't false-positive. A user asking three unrelated bug fixes is not a pattern. A user asking "write a script", "add a script", "make a script" is. Compare the underlying goal, not the surface words.
Don't gate the immediate task. Always finish what the user asked for first, then make the suggestion at the end of your reply. Never stall the actual work behind a meta-conversation about skills.
This rule applies whenever this skill is loaded, whether or not the hook has fired.
Workflow
- Ground the skill in real expertise. Do not generate from "best practices for X" — the result will be vague boilerplate. Extract from a real task you've completed, real runbooks, or real incident reports. Load
references/best-practices.mdif you want the full rationale. - Pick a kebab-case
name. Lowercase letters, digits, and single hyphens only; ≤ 64 chars; no leading/trailing/consecutive hyphens; must match the folder name. - Write the
descriptionlike an instruction, not a summary. Use imperative phrasing ("Use this skill when..."), focus on user intent, list casual phrasings the user might type. Stay under 1024 chars. Seereferences/description-optimization.mdfor the eval-loop that improves trigger rates. - Scaffold the folder with one command:
It creates the directory tree, writes a starterbash scripts/new-skill.sh <skill-name> "<one-line description>"SKILL.mdwith valid frontmatter, copies the MITLICENSE, and prints next steps. To start from scratch instead, copyassets/templates/SKILL.template.md(minimal) orassets/templates/SKILL-full.template.md(with all the canonical sections). - Write a slim
SKILL.mdbody — under 200 lines / 5,000 tokens. Use the canonical sections in this order:- When to use — bullet triggers
- Required structure — minimal canonical example
- Workflow — numbered steps with explicit "load
references/<topic>.mdwhen ..." pointers - Available resources — full inventory of bundled files
- Top gotchas — non-obvious environment/domain facts inline
- What you DO / What you do NOT do — short imperative lists
- Move detail into
references/<topic>.md. For each file, tell the agent when to load it (e.g. "Loadreferences/<error-handling>.mdif the API returns a non-200"), not just "seereferences/". Useassets/templates/reference.template.mdfor the file shape. - Bundle resources sensibly — copy-edit starting points in
assets/templates/, full worked examples inassets/examples/, executables (validators, scaffolders, helpers) inscripts/. For Python scripts prefer PEP 723 inline deps so they run withuv runand need no install step. Seereferences/scripts-guide.mdfor designing scripts for agentic use. - Add
LICENSE(the scaffolder does this automatically). Use MIT to match this repo. - Validate with
bash scripts/validate-skill.sh <skill-dir>— checks frontmatter shape, name format, name-matches-folder, description length, body length/tokens, license, that every referenced file exists, and that referenced files are mentioned inSKILL.md. Aim for 100%. - Optimize the description with eval queries before publishing — write 8-10 should-trigger and 8-10 should-not-trigger prompts and run them through your agent. See
references/description-optimization.md. - (Optional) Install the auto-suggest hook so the agent itself catches recurring tasks.
bash scripts/install-hook.shwiresscripts/task-tracker.pyinto~/.claude/settings.jsonas aUserPromptSubmithook. After 3 similar prompts (configurable), the hook emits a system-reminder that tells Claude to suggest packaging the recurring task as a skill via this skill. Seereferences/hooks.mdfor tuning and the manual install snippet.
Available resources
assets/templates/SKILL.template.md— minimal frontmatter-only starting point.assets/templates/SKILL-full.template.md— full structure with every canonical section.assets/templates/reference.template.md— shape forreferences/<topic>.mdfiles.assets/examples/roll-dice/— tiny worked example skill (matches the official quickstart).scripts/new-skill.sh— one-shot scaffolder; creates folder tree,SKILL.md,LICENSE.scripts/validate-skill.sh— spec-compliance checker; run after writing.scripts/task-tracker.py— Claude CodeUserPromptSubmithook. Watches the user's prompts and, when the same kind of task is asked 3 times (configurable), emits a system-reminder telling Claude to suggest packaging it as a skill.scripts/install-hook.sh— idempotent installer that wirestask-tracker.pyinto~/.claude/settings.json(or--projectfor./.claude/settings.local.json).references/spec.md— load when uncertain about a frontmatter field, naming rule, or directory convention.references/best-practices.md— load when designing a skill from scratch (grounding in real expertise, calibrating control, gotchas-section pattern, validation loops).references/description-optimization.md— load when the skill triggers too rarely or too often, or before publishing.references/eval.md— load when measuring whether the skill's outputs are good (test cases, assertions, train/val splits).references/scripts-guide.md— load when bundling executables inscripts/(one-off vs self-contained, PEP 723, designing for agentic use).references/hooks.md— load when installing, tuning, or troubleshooting the auto-suggest hook.
Top gotchas (always inline — do not skip)
namemust match the folder name exactly.pdf-tools/SKILL.mdwithname: pdf_toolsfails validation. Lowercase, hyphens, no underscores.- The description carries the entire triggering burden. Vague descriptions ("Helps with X") never activate. Use imperative phrasing and explicit casual variants ("...even if the user doesn't say 'CSV'").
- Body > 5,000 tokens slows every activation. Move detail to
references/<topic>.mdwith explicit load triggers. - Generic LLM boilerplate produces useless skills. "Handle errors appropriately" wastes tokens. Capture concrete project-specific gotchas, schemas, and procedures instead.
- Tell the agent when to load each reference file — not just "see references/". The agent loads
SKILL.mdonce, then loads references on demand based on your instructions. Without explicit triggers, it won't. - Bundled scripts must be non-interactive. Agents run in non-TTY shells; a script that prompts for input hangs forever. Accept everything via flags, env vars, or stdin.
- Don't add specific keywords from failed eval queries to the description — that's overfitting. Generalize to the underlying category.
- A skill is a coherent unit of work. Too narrow → multiple skills load for one task. Too broad → fails to trigger precisely. "Query database + format results" is one unit; adding "+ admin operations" is too much.
What you DO
- Ground every skill in real expertise — actual code, runbooks, conversation traces.
- Use
bash scripts/new-skill.sh <name> "<desc>"to scaffold, then edit. - Keep
SKILL.md≤ 200 lines / 5,000 tokens. Use progressive disclosure. - Tell the agent when to load each reference file with explicit triggers.
- Write descriptions imperatively ("Use this skill when..."), with casual phrasing variants the user actually types.
- Bundle templates in
assets/templates/, examples inassets/examples/, executables inscripts/. - Add an MIT
LICENSEto match this repo. - Run
bash scripts/validate-skill.sh <skill-dir>and iterate until 100%. - Run an eval pass on the description before publishing (see
references/description-optimization.md). - Keep skills coherent — one skill per coherent unit of work.
What you do NOT do
- Generate skills from "best practices for X" articles — they produce generic boilerplate.
- Pad
SKILL.mdwith definitions ("PDFs are documents that contain text"). - Use vague descriptions ("Helps with X", "This skill does Y").
- Mismatch
nameand folder, use uppercase, underscores, or consecutive hyphens. - Skip the LICENSE.
- Add features the skill doesn't need (don't over-engineer).
- Bundle interactive scripts that prompt for input — they hang in agent runs.
- Reference files in
SKILL.mdwithout telling the agent when to load them. - Bury gotchas in
references/— non-obvious environment facts belong inline so the agent reads them before hitting the issue.
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.

