$npx -y skills add pssah4/vault-operator --skill skill-creatorGuide for creating effective Vault Operator skills. Use when the user wants to build a new skill (or refine an existing one) that captures a repeatable workflow, a domain expertise, or a tool-integration recipe. Triggers include phrases like "build me a skill", "kannst du das aut
| 1 | # Skill Creator |
| 2 | |
| 3 | This skill guides the agent through creating a Vault Operator skill that another agent run can pick up and execute reliably. It is the basic authoring flow: initialize, edit, validate. |
| 4 | |
| 5 | **If the `skill-creator-pro` skill is available, prefer it for anything beyond a trivial one-step skill.** The Pro flow adds a guided requirements dialog (it interviews the user when they cannot state exactly what they need), a feasibility check against the actual plugin runtime and sandbox limits, a confirmed skill brief before any file is written, and a dry-run. This basic flow stays fully usable on its own; the Pro flow is the upgrade for designing non-trivial skills reliably. |
| 6 | |
| 7 | ## Binding rules (read first, no exceptions) |
| 8 | |
| 9 | 1. **The skill folder lives ONLY at `<agent-folder>/data/skills/{skill_name}/`.** Any other path (`Tools & Settings/Skills/`, `Notes/skills/`, vault-root, etc.) is invisible to the discovery layer. A skill written elsewhere does not exist. |
| 10 | 2. **`init_skill` is the ONLY way to create the folder.** Do NOT call `create_folder` or `write_file` to seed a new skill manually. Even when you "know" the layout, route through `init_skill` so the validator stays happy and the source-frontmatter is correct. |
| 11 | 3. **Existing artifacts at the wrong path are NOT proof the task is done.** If you find a half-finished `weekly-meeting-summary` under `Tools & Settings/Skills/` or similar, treat it as garbage from a previous broken run. Delete it after you have the real skill landed at `data/skills/{name}/`. |
| 12 | 4. **`quick_validate` is mandatory before declaring done.** Step 5 is not optional. A skill that "looks right" but was never validated is not finished. |
| 13 | 5. **Do not short-circuit by reusing a similar-sounding existing skill.** When the user asks to BUILD a new skill, build a new one. Reuse means edit-and-save under the same name -- different name means new skill, even if the domain overlaps with something that already exists. |
| 14 | |
| 15 | ## About Vault Operator skills |
| 16 | |
| 17 | A Vault Operator skill is a folder under `<agent-folder>/data/skills/{skill_name}/` that contains: |
| 18 | |
| 19 | - `SKILL.md` -- the only required file. YAML frontmatter (`name`, `description`) plus markdown body. |
| 20 | - `scripts/` -- optional JavaScript helpers executable via `run_skill_script`. |
| 21 | - `references/` -- optional markdown files the agent loads on demand. |
| 22 | - `assets/` -- optional binary files the skill emits as output. |
| 23 | |
| 24 | The frontmatter `description` is the trigger. The agent picks the skill based on description alone, never reads the body until the skill activates. |
| 25 | |
| 26 | ## Core principles |
| 27 | |
| 28 | ### Concise wins |
| 29 | |
| 30 | Context window is a shared resource. Only add information the agent does not already have. Every paragraph must justify its tokens. Prefer one concrete example over a paragraph of theory. |
| 31 | |
| 32 | ### Match freedom to fragility |
| 33 | |
| 34 | Pick the right level of detail for each step: |
| 35 | |
| 36 | - **High freedom (text instructions)** -- many valid approaches, agent decides. |
| 37 | - **Medium freedom (pseudocode, parametrized scripts)** -- preferred pattern with variation room. |
| 38 | - **Low freedom (specific scripts, few parameters)** -- fragile or sequence-critical work. |
| 39 | |
| 40 | A narrow bridge with cliffs needs guardrails. An open field allows many routes. |
| 41 | |
| 42 | ### Progressive disclosure |
| 43 | |
| 44 | Keep `SKILL.md` under 500 lines. When a section grows past that, move it into a `references/` file and link to it from the body. Reference files load on demand; the body loads on every skill activation. |
| 45 | |
| 46 | ## Anatomy of a skill folder |
| 47 | |
| 48 | ``` |
| 49 | <agent-folder>/data/skills/{skill_name}/ |
| 50 | ├── SKILL.md (required) |
| 51 | ├── scripts/ (optional) |
| 52 | │ └── *.js (executable via run_skill_script) |
| 53 | ├── references/ (optional, load on demand via read_file) |
| 54 | │ └── *.md |
| 55 | └── assets/ (optional, copied into output) |
| 56 | └── * |
| 57 | ``` |
| 58 | |
| 59 | ### Frontmatter rules (binding) |
| 60 | |
| 61 | Only two fields are written: |
| 62 | |
| 63 | ```yaml |
| 64 | --- |
| 65 | name: my-skill |
| 66 | description: One concise paragraph that explains WHAT the skill does and WHEN to use it. Include explicit triggers so the agent picks it up from the user phrasing. |
| 67 | --- |
| 68 | ``` |
| 69 | |
| 70 | Hard constraints enforced by the validator: |
| 71 | |
| 72 | - `name` is kebab-case (`[a-z0-9-]+`), max 64 characters, no leading or trailing hyphen, no double hyphens. |
| 73 | - `name` cannot contain the reserved words `anthropic` or `claude`. |
| 74 | - `description` is max 1024 characters, no angle brackets, single line. |
| 75 | - Allowed-only properties: `name`, `description`. Adding extra keys triggers a warning in the discovery layer. |
| 76 | |
| 77 | ### Anti-patterns |
| 78 | |
| 79 | Do NOT create the following in a skill folder: |
| 80 | |
| 81 | - `README.md` -- the skill body already tells the agent everything it needs. |