Claude Skill

skill-authoring

Writes and revises agent skills so they trigger at the right moments and give usable instruction when they do. Use this when creating a new skill, editing an existing one, diagnosing a skill that fires too often or never fires, or reviewing a set of skills for overlap. Also use b

LLM Mart · 0 points · 16 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download cbrock84-headcount-plugins_technology_skills_skill-authoring-98d1c17.zip · 2 KB
Part of cbrock84/headcount — 160 skills

Install

skills CLI npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/technology/skills/skill-authoring
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart
Git git clone https://github.com/cbrock84/headcount.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Skill authoring

A skill is judged twice: on whether it loads at the right moment, and on whether it helps once loaded. Most fail the first test.

The description does the triggering

It is the only part read when deciding whether to load. Write it for that job:

  • Lead with what the skill does, in one clause.
  • Then when to reach for it — the situations, in the words someone would actually use, including the oblique ones ("why isn't this converting" as well as "CRO audit").
  • Name the edge cases that should still trigger it, and where useful, what should not.

Vague descriptions produce two failures at once: the skill misses cases it should catch, and fires on cases it cannot help.

The body does the work

Write for someone competent who has not thought about this problem today. That means:

  • Method over exhortation. "Be thorough" is noise. An ordered procedure is instruction.
  • State the failure behind each rule. A rule with no failure attached gets optimized away by the next reader.
  • Be specific enough to be wrong. Guidance too hedged to contradict is too vague to follow.
  • Put long material in references/ and say when to read it. The body should fit in working memory.

Overlap is the silent killer

Two skills whose descriptions both match a request means neither reliably wins. Before adding one, check what already covers the ground. Prefer extending an existing skill, or consolidating the family into one skill with references, over adding a near-neighbor.

Mechanics

  • name must be lowercase-hyphenated and equal the directory name, or the skill will not load.
  • One skill, one directory, SKILL.md at its root; supporting material in references/ and scripts/.

Verify before shipping

Write three requests that should trigger it and two that should not, and check the description actually discriminates. If a near-miss request would pull it in, tighten the description.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Never

  • Ship a skill whose description does not say when to use it. A skill that never triggers is dead weight.
  • Write a skill that restates what the model already does well without prompting.
  • Let two skills claim the same trigger. Move the boundary or merge them.
  • Ship without running the skill against the case that motivated writing it.
Files (headcount)
  • references
    • sources.md 864 B
      # Sources — `technology:skill-authoring`
      
      <!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
      
      Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
      
      ## Agent Skills documentation
      
      Anthropic · global · **read and cite only — copyrighted, do not reproduce**
      
      <https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview>
      
      **Authoritative for:** The SKILL.md format and its loading semantics — required frontmatter, body, and how bundled resources are surfaced. The format, not what makes a skill good.
      
      ---
      
      Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.
      
  • SKILL.md 3 KB
    ---
    name: skill-authoring
    description: Writes and revises agent skills so they trigger at the right moments and give usable instruction when they do. Use this when creating a new skill, editing an existing one, diagnosing a skill that fires too often or never fires, or reviewing a set of skills for overlap. Also use before adding to a skill library, to check the capability is not already covered.
    ---
    
    # Skill authoring
    
    A skill is judged twice: on whether it loads at the right moment, and on whether it helps once
    loaded. Most fail the first test.
    
    ## The description does the triggering
    
    It is the only part read when deciding whether to load. Write it for that job:
    
    - Lead with **what the skill does**, in one clause.
    - Then **when to reach for it** — the situations, in the words someone would actually use, including
      the oblique ones ("why isn't this converting" as well as "CRO audit").
    - Name the **edge cases that should still trigger it**, and where useful, what should *not*.
    
    Vague descriptions produce two failures at once: the skill misses cases it should catch, and fires
    on cases it cannot help.
    
    ## The body does the work
    
    Write for someone competent who has not thought about this problem today. That means:
    
    - **Method over exhortation.** "Be thorough" is noise. An ordered procedure is instruction.
    - **State the failure behind each rule.** A rule with no failure attached gets optimized away by the
      next reader.
    - **Be specific enough to be wrong.** Guidance too hedged to contradict is too vague to follow.
    - **Put long material in `references/`** and say when to read it. The body should fit in working
      memory.
    
    ## Overlap is the silent killer
    
    Two skills whose descriptions both match a request means neither reliably wins. Before adding one,
    check what already covers the ground. Prefer extending an existing skill, or consolidating the
    family into one skill with references, over adding a near-neighbor.
    
    ## Mechanics
    
    - `name` must be lowercase-hyphenated and equal the directory name, or the skill will not load.
    - One skill, one directory, `SKILL.md` at its root; supporting material in `references/` and
      `scripts/`.
    
    ## Verify before shipping
    
    Write three requests that should trigger it and two that should not, and check the description
    actually discriminates. If a near-miss request would pull it in, tighten the description.
    
    ## Sources
    
    `references/sources.md` in this skill lists the outside authorities that settle the questions
    here — what each one is authoritative for, and what you may do with it. Check them before
    answering on anything they cover, and cite what you used. Most are free to read and not free
    to reproduce; the use note on each is binding.
    
    ## Never
    
    - Ship a skill whose description does not say when to use it. A skill that never triggers is dead weight.
    - Write a skill that restates what the model already does well without prompting.
    - Let two skills claim the same trigger. Move the boundary or merge them.
    - Ship without running the skill against the case that motivated writing it.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related