skills-maker

Tools used: Read / Grep / Glob to inspect existing skills, Write / Edit to author them, Bash(node:*) / Bash(ruby:*) for the frontmatter checks in scripts/, Bash(bash:*) for their regression bench, Bash(skills:*) / Bash(npx skills:*) for install and updates, Bash(gh:*) for repository visibility during export.

The user invoked this skill with the argument: $ARGUMENTS

This is a routing skill. Read $ARGUMENTS and the conversation context, pick exactly one workflow, read that workflow file, and follow its instructions inline.

All paths below are relative to this skill's own directory. Resolve them against wherever this skill is installed rather than assuming a location.

Where skills live

Keep one canonical copy in an agent-neutral location such as ~/.agents/skills/<name>/, and symlink each agent's skills directory to it as needed: one file then serves every agent, and no copy drifts. Each agent reads its own directory; Claude Code, for example, reads ~/.claude/skills/<name>/SKILL.md. When a workflow below says "the skills directory", resolve it for the agent in use.

The facts every workflow here depends on

The description is the whole trigger surface

Only the frontmatter is read before a skill loads. As far as discovery is concerned the body does not exist, so every phrase that should cause the skill to fire has to appear in description:. A trigger documented only in the body will never fire, because nothing reads the body until something has already decided to load it.

The corollary matters when refactoring: moving a rule out of a global instructions file and into a skill only works if whatever made an agent reach for it survives in the description. Otherwise the rule is unreachable rather than relocated.

YAML eats the description at #

In an unquoted YAML scalar, a space followed by # starts a comment. Everything after it is discarded with no parse error, no warning, and a skill that still loads and still works. The only symptom is triggers that never fire.