agentleFS
conorbronsdonconorbronsdon/agent-skill-builder/SKILL.md

agent-skill-builder

Skill5 starsChanged 3 months agoMITView on GitHub

Builds, reviews, or migrates agent skills. Use when creating a SKILL.md, auditing an existing skill, or converting a legacy Claude Code command.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. realjaymes/marketingagentskills★ 68same name
    2. dimonier/skills★ 10same 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.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    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
  1. Distinctive:

    Read the host repository's applicable instruction files (AGENTS.md, CLAUDE.md, or equivalents) and inspect existing skills.

    line 27
  2. Very specific:

    Use disable-model-invocation: true when timing must remain user-controlled, especially publishing, deploying, sending, deleting, or other …

    line 41
  3. Very specific:

    Use user-invocable: false for background knowledge users should not run directly.

    line 42
  4. Distinctive:

    Leave both enabled when natural-language discovery is useful.

    line 43
  5. Distinctive:

    Do not force every skill into the same outline.

    line 50
  6. Very specific:

    Before writing, check whether <destination>/<name>/SKILL.md exists.

    line 55
  7. Distinctive:

    Add scripts or references only when they provide a concrete reusable benefit.

    line 58
  8. Distinctive:

    Run the bundled validator with the selected profile:

    line 62
  9. Distinctive:

    Test behavior in a fresh session when practical:

    line 71

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Skill Builder

Produce a ready-to-use skill from a plain-language request. Preserve the user's runtime, scope, and requested level of implementation.

Select the mode

Parse $ARGUMENTS; default to new when it contains a description.

  • new <description>: create or draft a skill.
  • review <path>: report actionable findings and run validation. Do not rewrite unless asked.
  • migrate <path>: convert a legacy .claude/commands/*.md file into a skill directory while preserving behavior.

Establish the contract

Infer what is already clear. Ask only when a missing choice would materially change the result.

  1. Choose the runtime:
    • Claude Code (default): read the Claude Code reference.
    • Portable Agent Skills: read the portable reference and omit Claude-only fields.
  2. Read the host repository's applicable instruction files (AGENTS.md, CLAUDE.md, or equivalents) and inspect existing skills. Match local conventions and avoid duplicate capabilities.
  3. Identify inputs, outputs, required resources, and the destination directory.
  4. Classify the skill:
    • Reference: standing domain rules or conventions.
    • Task: a bounded workflow with a defined result and stopping condition.
    • Tool-backed: a task that benefits from repeatable scripts or narrowly scoped tool grants.

Design decisions

Include only fields and instructions that change behavior.

  • Name: lowercase letters, digits, and hyphens. Portable skills require the frontmatter name to match the directory.
  • Description: lead with the capability and include phrases users would naturally say. Keep model-visible descriptions near 250 characters when practical.
  • Invocation (Claude Code only):
    • Use disable-model-invocation: true when timing must remain user-controlled, especially publishing, deploying, sending, deleting, or other consequential mutations.
    • Use user-invocable: false for background knowledge users should not run directly.
    • Leave both enabled when natural-language discovery is useful. Invocation control never replaces approval immediately before an external or hard-to-reverse mutation.
  • Arguments (Claude Code only): pair argument-hint with $ARGUMENTS, positional $N, or names declared in arguments:.
  • Forking (Claude Code only): use context: fork for self-contained tasks. Add background: false only when the invoking turn needs the result immediately.
  • Tool grants: allowed-tools pre-approves tools; it does not restrict the remaining pool. Grant only commands the workflow actually needs.
  • Dynamic injection (Claude Code only): use ! commands for bounded read-only context. Never interpolate skill arguments into shell commands, and never perform mutations during preprocessing.
  • Resources: keep shared instructions in SKILL.md; put conditional details in references/, repeated deterministic mechanics in scripts/, and output material in assets/.

Do not force every skill into the same outline. Reference skills usually need concise standing rules. Task skills need an objective, workflow, stopping conditions, and output. Tool-backed skills also need execution and failure behavior.

Implement or review

  • For new, draft only when the user asked for a draft. When the user asked to create or install the skill, write it and verify it.
  • Before writing, check whether <destination>/<name>/SKILL.md exists. Do not overwrite it without explicit approval.
  • For review, tie every finding to an observable behavior, specification rule, or concrete maintenance risk. Separate runtime errors from optional improvements.
  • For migrate, preserve command arguments and behavior, move substantial supporting material beside the new SKILL.md, then validate the chosen runtime.
  • Add scripts or references only when they provide a concrete reusable benefit. Remove scaffold placeholders before delivery.

Validate

Run the bundled validator with the selected profile:

python3 ${CLAUDE_SKILL_DIR}/scripts/validate_skill.py --profile claude-code <skill-directory>
python3 ${CLAUDE_SKILL_DIR}/scripts/validate_skill.py --profile agentskills <skill-directory>

For portable skills, also run skills-ref validate <skill-directory> when available. Report which checks ran and their exact PASS/FAIL results.

Test behavior in a fresh session when practical:

  • Direct invocation with realistic input.
  • A natural-language request that should activate a model-invocable skill.
  • A near-miss that should not activate it.
  • One mutation that should make a meaningful validator or workflow check fail, followed by restoration of the valid input.

For high-value skills, offer the official skill-creator eval loop for with-skill/without-skill comparisons and trigger tuning.

Deliver

Show the created or changed files, validator and test output, and any unresolved warnings. If files were written, do not ask whether to save them afterward. Ask for the next external action only when it requires separate authorization.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.