skills/agent-skills-creator/SKILL.md
Guides creation and improvement of best-practice agent skills following the open format specification. Covers frontmatter, progressive disclosure, reference files, rules folders, degrees of freedom, constraint calibration, executable scripts, MCP tool references, evaluations, constraint ablation, and an eleven-dimension audit protocol for existing skills. Use when creating a new skill, authoring SKILL.md, setting up a rules-based audit skill, structuring a skill bundle, writing scripts inside a skill, evaluating a skill, improving or rewriting an existing skill, or asking "how to write a skill", "improve this skill", "audit my skill", "review this SKILL.md", "simplify this skill", "is this skill over-constrained", or "rightsize this skill".
npx skillsauth add mblode/agent-skills agent-skills-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Create and improve skills in the Agent Skills open format: full lifecycle from pattern selection through validation and README update.
agents-md) or general documentation quality (use docs-writing).references/improving-existing-skills.md, which scores eleven audit dimensions, runs an ordered rewrite, then reuses Steps 5-8 for validation and shipping./doctor first: the harness ships skill and CLAUDE.md rightsizing, and this skill's audit is the deeper per-skill pass that follows it, not a replacement.| File | Read When |
|------|-----------|
| references/authoring-tips.md | Default when writing or cutting body content: judgement over rules, constraint calibration, degrees of freedom, content patterns, descriptions |
| references/skill-patterns.md | Choosing a structural pattern |
| references/format-specification.md | Directory layout, optional frontmatter fields, loading semantics, naming |
| references/rules-folder-structure.md | Building a rules-based audit/lint skill |
| references/improving-existing-skills.md | Auditing, scoring, simplifying, or rewriting an existing skill |
| references/executable-code.md | Skill includes scripts, depends on packages, or invokes MCP tools |
| references/evaluation-and-iteration.md | Designing evaluations, ablating constraints, testing across models |
Mechanical rules are not in any of these. scripts/validate.sh is their single statement:
scripts/validate.sh skills/<name> # one skill
scripts/validate.sh --all # every skill in the repo
Copy this checklist to track progress:
Skill creation progress:
- [ ] Step 1: Choose a pattern
- [ ] Step 2: Create directory and frontmatter
- [ ] Step 3: Write SKILL.md body
- [ ] Step 4: Add reference or rule files
- [ ] Step 5: Validate
- [ ] Step 6: Update README.md and docs/skills.mdx
- [ ] Step 7: Smoke-test installation
- [ ] Step 8: Evaluate and iterate
Simple/hub, workflow, rules-based, or mixed. references/skill-patterns.md has the shapes, the in-repo example for each, and the problem-to-pattern affinity table.
Create skills/<name>/SKILL.md with name and description. Write the description as a model trigger, not a human summary: what it does, what it covers, then "Use when..." with the phrases users actually say. validate.sh enforces the limits, so write for routing and let the script police the constraints.
references/authoring-tips.md carries the judgement. Apply:
references/ folder, each file linked from SKILL.md with a "Read when" conditionrules/ folder; references/rules-folder-structure.md covers _sections.md, _template.md, and file namingPrefer a reference that is code. An existing implementation or a test suite pins a contract better than prose describing it ("Reference-as-Spec"). Split by loading condition, not line count: two topics read at different moments are two files.
Advanced: scripts/ for executables Claude composes (see references/executable-code.md), config.json for setup context that would otherwise be re-asked every session, and on-demand PreToolUse/PostToolUse hooks for safety gates.
scripts/validate.sh skills/<name>
Output separates format (the spec) from house style (this repo's taste). Fix every FAIL; a SKIP always states why it did not apply.
Add a bullet under the matching category heading in both files, and bump the skill count near the top of the README:
- **[<skill-name>](./skills/<skill-name>/SKILL.md)**: <one-line description>
Categories: Architecture, Design, Writing, Quality, Shipping, Authoring. validate.sh verifies both bullets and the count.
npx skills add mblode/agent-skills -g --skill <name> -y
ls ~/.claude/skills/<name>/
skills add writes to ~/.agents/skills/<name>/, symlinked into ~/.claude/skills/<name>/ for Claude Code to pick up. For local iteration without reinstalling, symlink the repo folder directly and unlink when done:
ln -s /path/to/agent-skills/skills/<name> ~/.claude/skills/<name>
references/evaluation-and-iteration.md. Define 3+ scenarios, test on each target model, and iterate on observed behavior rather than assumptions. Ablate any rule you suspect is dead weight: delete it, rerun the scenarios, keep it only if one regresses.
--help, a tool description, or a rule filehelper, utils, tools, documents, data) that give the model nothing to route onagents-md for auditing AGENTS.md/CLAUDE.md instruction filesdocs-writing for documentation quality rulesdevelopment
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.