Skip to content
Back to skills

Skill Creator

ASecurity

Create or revise a reusable agent skill from a user's workflow, domain knowledge, or tool instructions. Use whenever a user wants to create, capture, package, edit, or turn something into a skill.

  • 5 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added August 31, 2026
documentationgitdocumentation

Security analysis

A100/100

Scanned August 31, 2026

npx -y skills add instrument-org/instrument --skill skill-creator --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Skill Creator?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Skill Creator
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/instrument-org-skill-creator/badge)](https://www.skillsdirectory.com/skills/instrument-org-skill-creator)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: skill-creator
description: Create or revise a reusable agent skill from a user's workflow, domain knowledge, or tool instructions. Use whenever a user wants to create, capture, package, edit, or turn something into a skill.
---

# Skill Creator

Create and revise focused, reusable skill packages in the Instrument workspace.

Skills live in `/skills/<name>/`, a writable mount outside the task root. Write and edit them with the ordinary file tools. A skill saved there is available to `load_skill` immediately.

## Workflow

1. Understand what the skill should enable, when it should trigger, and what a successful result looks like. Reuse details already present in the conversation before asking questions.
2. Ask only the questions whose answers would materially change the skill. Use concrete examples to resolve ambiguity.
3. Decide whether the skill needs only instructions or also reusable scripts, references, or assets.
4. Draft a concise `SKILL.md` body. Assume the agent already knows general concepts and include only domain-specific procedures, constraints, and decision guidance.
5. Write the package to `/skills/<name>/`. Check whether that directory already exists first. If it does, stop and ask whether to revise that existing skill or choose another name; revising is fine, silently replacing the wrong skill is not.
6. Run `validate-skill <name>` and fix what it reports. A skill with broken frontmatter fails silently by never appearing at all, so this is the only confirmation that what you wrote is a skill.
7. Tell the user the skill name and that it is available from Skills and the prompt slash menu.

## Package design

Every skill requires `SKILL.md`, whose frontmatter must set `name` and `description`:

```markdown
---
name: <directory name>
description: <what it does and when to use it>
---
```

Add `disable-model-invocation: true` when the skill should only ever run because the user asked for it by name. It then stays listed in Skills and the slash menu but is kept out of the catalog agents choose from.

Add `user-invocable: false` when the skill should be available for automatic model loading but hidden from the slash menu and other direct manual-invocation affordances.

Avoid combining `disable-model-invocation: true` with `user-invocable: false` unless the user explicitly wants a skill that is neither auto-loaded nor manually invocable.

The runtime also understands `compatibility`, and it tolerates harmless extra keys. When revising or importing an existing skill, preserve frontmatter keys such as `argument-hint`, `allowed-tools`, `context`, `license`, and `metadata` unless you have a specific reason to change them. Do not delete extra keys only to chase validation cleanliness.

Optional resources use these directories:

- `scripts/` for deterministic or repeatedly rewritten operations
- `references/` for details loaded only when needed
- `assets/` for templates and other files used in outputs

Do not create auxiliary documentation such as a README, installation guide, changelog, or quick reference.

## Naming and description

- Use lowercase letters, digits, and hyphens only. The directory name is the skill's identity, so it must match the `name` in frontmatter.
- Keep the name under 64 characters and prefer a short action-oriented phrase.
- Make the description explain both what the skill does and the situations that should trigger it. Trigger guidance belongs in the description, not the body.

## Writing guidance

- Use imperative instructions.
- Match specificity to risk: flexible prose for judgment calls, parameterized scripts for repeatable work, and exact steps for fragile operations.
- Keep the main file comfortably under 500 lines and 5000 tokens. Put extensive schemas, examples, or variants in directly linked reference files.
- Avoid duplicating information between `SKILL.md` and resources.
- Include examples when they clarify an input, output, or decision boundary.

This first creation flow does not run evaluations automatically. If the user asks to test the skill, create it first and then help them exercise it in a new task.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.