agentleFS
sxntixgosxntixgo/frugal-skills/skills/skill-creator/SKILL.md

skill-creator

Skill0 starsChanged 4 months agoMITView on GitHub

Authors a new Claude Code skill or edits an existing one in this repo, enforcing the repo's 8 authoring rules and scaffolding evals. Use when the user asks to create, write, add, or edit a skill.

189 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use taskflow-inbox-triage, mermaid-diagram-generator and 10 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.
  • AtomicBot-aiSkill

    taskflow-inbox-triage

    Also in 6 projects that use this

  • shalombSkill

    mermaid-diagram-generator

    Guide on creating and editing Mermaid charts safely. Use when asked to draw a diagram, flowchart, or architecture chart. Triggers on: 'mermaid', 'diagram', 'flowchart', 'visualize'.

    Also in 5 projects that use this

  • naman10parikhSkill

    ecosystem-reference

    Quick-access directory of Claude Code ecosystem repos, skills, plugins, MCPs, and patterns. Use when improving the harness.

    Also in 5 projects that use this

  • naman10parikhSkill

    fractal-delegation

    Also in 5 projects that use this

  • Liang-MHSkill

    stock_analysis

    获取 A 股、基金和港股的实时行情和技术分析数据

    Also in 5 projects that use this

  • nicepkgSkill

    community-led-growth

    Expert in community-led growth (CLG) - leveraging user communities to drive acquisition, retention, and expansion. Covers building developer communities, user groups, ambassador programs, and turning customers into advocates. Knows the difference between community as a feature vs community as a growth engine, and how to measure community ROI. Use when "community-led, CLG, ambassador program, champion program, user community, developer community, word of mouth, user group, " mentioned.

    Also in 5 projects that use this

  • +6 more from naman10parikh

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 185 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Create a new skill, or edit an existing skill in skills/.

    line 17
  2. Very specific:

    Run evals, grade, or render a verdict → that is skill-reviewer.

    line 22
  3. Very specific:

    Create a TodoWrite item for each of the 5 stages.

    line 28
  4. Distinctive:

    Do not draft anything until the user approves this: If the brief is vague or you're inventing requirements, ask — do not guess.

    line 38
  5. Very specific:

    Read references/writing-evals.md for the format and how to pick cases.

    line 58

“Common” is measured: kept by at least 6 in 10 of the 185 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.

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

Skill Creator

Build a skill through 5 gated stages. You BUILD the skill; you do NOT judge it — skill-reviewer runs the rubric and baseline evals. End by handing off.

This skill enforces 8 authoring rules. The full checklist is in references/skill-body.md. (When working inside this repo, the same rules are also documented in CLAUDE.md.)

Scope

This skill DOES:

  • Create a new skill, or edit an existing skill in skills/.
  • Clarify intent, draft frontmatter + body, scaffold evals/evals.json.
  • Enforce authoring rules 1–8.

This skill does NOT:

  • Run evals, grade, or render a verdict → that is skill-reviewer.
  • Invent the skill's domain requirements → ask the user.
  • Publish, install, or push anything.

Workflow

Create a TodoWrite item for each of the 5 stages. Each stage writes its output to ./.claude-skills-work/<skill>/ so work resumes if interrupted; say where you wrote it.

Stage 1 — Clarify intent ⛔ STOP GATE

Nail three things and write them to ./.claude-skills-work/<skill>/plan.md:

  • Trigger: the concrete situation where this skill should fire ("use when…").
  • Scope: what it DOES and, explicitly, what it does NOT do.
  • Success criteria: observable signs the skill worked.

Do not draft anything until the user approves this. If the brief is vague or you're inventing requirements, ask — do not guess.

Stage 2 — Frontmatter

Draft name (kebab-case, == directory) and description. The description is the ONLY thing Claude sees when deciding to load the skill, so the trigger must be concrete. Read references/writing-descriptions.md. Show it; adjust.

Stage 3 — Body

Draft the SKILL.md body: Scope block, a required-steps checklist (to be surfaced via TodoWrite), STOP/checkpoint gates, a Red-flags list, and pointers to any references/*.md. Keep it lean (< ~500 lines); push detail into references. Read references/skill-body.md for the structure and the 8-rule checklist. Show it.

Stage 4 — Scaffold + evals

For a NEW skill, run scripts/new_skill.sh <skill-name> to create the directory and stubs, then replace the generated SKILL.md skeleton with your approved Stage 2–3 drafts (the skeleton's TODO placeholders get overwritten). For an EDIT, skip scaffolding. Then write 3–5 realistic cases in evals/evals.json. Read references/writing-evals.md for the format and how to pick cases. Show them.

Stage 5 — Hand off

Tell the user to run skill-reviewer on the new skill (rubric + baseline eval comparison). Write a one-line resume pointer ("next: review") to ./.claude-skills-work/<skill>/plan.md. Do not self-judge.

Red flags (stop and correct)

If you notice…Do this
Drafting the body before Stage 1 is approvedSTOP — the Stage 1 gate is mandatory
A vague description ("helps with X")Rewrite with a concrete trigger; sanity-check it against the eval prompts
Inventing requirements the user didn't stateStop and ask
Skipping evals because "it obviously works"Evals are required (rule 8); scaffold them
SKILL.md filling up with reference detailMove detail to references/; keep the body lean
Mandating subagents in the new skillNot allowed except dev-time evals (rules 4 & 8)

Done when

  • The new/edited skill satisfies rules 1–8.
  • evals/evals.json has 3–5 realistic cases.
  • You have handed off to skill-reviewer and written the resume pointer.

References (load only at the stage that needs it)

  • references/writing-descriptions.md — Stage 2: the trigger/description.
  • references/skill-body.md — Stage 3: body structure + 8-rule checklist.
  • references/writing-evals.md — Stage 4: evals.json format + good cases.
  • references/examples.md — calibration: one strong, one weak skill, annotated.

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.