Naming agent skills
npx -y skills add narumiruna/skills --skill naming-agent-skillsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Deprecated compatibility reference for choosing, reviewing, renaming, or standardizing agent skill names. Use the active creating-agent-skills workflow for current naming and authorized repository rename work.
SKILL.md
2.7 KB, as published. Nobody here has run it
Naming Agent Skills (Deprecated Reference)
Use creating-agent-skills for the maintained workflow. This reference preserves the former $naming-agent-skills behavior for explicit local use.
Name the task and trigger the skill represents, not its implementation.
Rules
- Use lowercase kebab-case: letters, meaningful digits, and single hyphens; no leading or trailing hyphen.
- Prefer two to four specific words and stay within the target framework's length limit.
- Avoid vague words such as
helper,utils,tools,assistant,magic,smart,general,data,files, ordocuments. - Avoid product or organization names unless the trigger is genuinely product-specific.
- Prefer user intent over implementation detail and a name that remains valid if internals change.
- Inspect sibling names and references; minimize overlap with existing triggers.
Use <verb-ing>-<object> as a useful default, not a mandate. Preserve the skill's original meaning when another pattern is clearer or the library has an established convention. Domain-first or command-style names are valid when they match the surrounding collection.
Selection
- Read the skill's actual description and workflow; do not name from an informal label alone.
- Identify the triggering action, object or domain, and any necessary product qualifier.
- Generate a small set of candidates in the repository's naming style.
- Compare candidates for specificity, searchability, future stability, and collision risk.
- Recommend one name with the deciding reason and mention alternatives only when they represent a real tradeoff.
Prefer analyzing-test-results over parse-json, and adding-message-timestamps over a product-prefixed name unless the behavior is product-specific.
Rename Boundary
Distinguish a naming recommendation from a requested repository rename. Do not edit files when the user asked only for names or review.
For an authorized rename, use the skill-maintenance workflow and update the directory, frontmatter name, UI metadata/default prompt, catalog, links, examples, tests, and other exact-name references as one bounded change. Preserve compatibility notes when external consumers depend on the old name, then run repository validation.
Output
Lead with the recommendation or verdict and its brief reason. For multiple skills, use a current/recommended/reason table. Include conflicts or compatibility work that would affect adoption; omit formulaic alternatives and repeated rules.