skill-creator

# Skill Creator Turn a reusable workflow into a dense skill, then verify it against a real prompt. ## Inputs to collect Collect only the missing information: 1. **Goal**: What should the skill help the model do? 2. **Triggers**: What user phrases should activate it? 3. **Boundaries**: What nearby requests should not trigger it? 4. **Success bar**: What does one good run look like? If the user only has a vague idea, clarify the request before continuing. Do not invent a long interview flow inside this skill. ## Mandatory platform command router This skill intentionally keeps executable shell recipes OUT of `SKILL.md`. Before you run any command for this skill, select exactly one platform command reference and use only that file's recipes. Router: 1. Read `<agent-context>.platform`. 2. If `platform` is `win32`: - REQUIRED: read `references/commands-windows-powershell.md`. - Use PowerShell recipes from that file only. - Do NOT use bash snippets, `/tmp/...`, `mkdir -p`, `cat <<EOF`, or `python3` assumptions. 3. If `platform` is `darwin` or `linux`: - REQUIRED: read `references/commands-macos-linux.md`. - Use bash/zsh recipes from that file only. 4. If `platform` is missing or unknown: - Do a tiny preflight to identify the shell/platform before running anything. - If still unclear, ask the user which environment is running the command. Never translate shell commands across platforms from memory. The platform reference files own every recipe this skill needs (`run-lint`, `eval-scratch-dir`, `baseline-output-paths`). ## Procedure 1. Check whether a matching skill already exists. Check the `<available_skills>` block already in your context — it lists every skill's name and description. Call `skill({ name: "<name>" })` to read a candidate in full. If a nearby skill already covers the use case, **do not create a duplicate**. Instead, tell the user to use `skill-refiner` to extend or improve the existing skill. 2. Determine the skill scope. Use the three-question test to decide where the skill lives: - **Will the answer change for a different user?** → User skill (`{{DATA_DIR}}/skills/`) - **Does it hold true across projects?** → Agent skill (`{{DATA_DIR}}/agents/<name>/skills/`) - **Only relevant to the current project?** → Project skill (`<repo>/.minimax/skills/` — the native workspace skill root; existing workspace skill roots also work) 3. Capture the reusable workflow from the lightest source available. - Prefer the just-finished conversation or user-provided workflow doc. - Condense it into the minimum procedure another model needs. - If the idea is still vague, clarify it with the user, then return here. 4. Design the skill around progressive disclosure. - Put trigger/boundary information in frontmatter `description`, not in a `When to use` section. - Keep `SKILL.md` focused on execution rules: procedure, output contract, failure handling. - Move bulky background, schemas, or variants into `references/`. - Add `scripts/` only for deterministic local work. 5. Draft `SKILL.md` with high information density. - Keep body sections short and imperative. - Remove README-style teaching, feature tours, redundant trigger lists, and API-overview prose. - Keep only one or two canonical examples. - Follow `references/skill-template.md`, `references/description-rubric.md`, and `references/anti-patterns.md`. - **Windows adaptation**: if the skill contains shell commands, scripts, or `python3` references, add a `## Windows (win32) platform notes` section with PowerShell equivalents or cross-platform alternatives. Pure-process skills (no shell commands) can skip this. Write the skill into the location determined in step 2: ``` {{DATA_DIR}}/skills/<skill-name>/ {{DATA_DIR}}/agents/<agent-name>/skills/<skill-name>/ <repo>/.minimax/skills/<skill-name>/ ``` Use this structure only when needed: ``` <skill-root>/ ├── SKILL.md ├── scripts/ # deterministic local work only └── references/ # bulk material the main file should not inline ``` Do not create extra scaffolding by default: `README.md`, `CHANGELOG.md`, `install.sh`, `.env`, `.env.example`, `.gitignore`, `assets/`, or `evals/`. For script bundling rules, see `references/when-to-bundle-scripts.md`. 6. Lint before eval. First locate the skill-creator install directory: call `skill({ name: "skill-creator" })` and take the directory of the returned `Location:` path. Then use the `run-lint` recipe from the selected platform command reference to run `node scripts/lint-skill.js` against the new skill path. Check for complete frontmatter, matching kebab-case names, a useful description, main-file size, forbidden files, and valid `references/` links. Do not move on until lint passes. 7. Eval against a real user prompt. Eval compares "with-skill" vs "without-skill" on a real prompt. **Pick a real eval prompt first**: a genuine user question that should trigger this skill. Launch two Task tool calls (subagents) with `run_in_background: true` so they run in parallel — foreground task calls execute sequentially. Use the `baseline-output-paths` recipe from the platform command reference for the writable scratch directory (do NOT hardcode `/tmp/`): 1. **Producer**: "Load skill at `<SKILL_PATH>`, use it to handle: `<EVAL_PROMPT>`. Write your process and output to `<scratch>/eval-<skill-name>/with-skill.md`." 2. **Baseline**: "Handle this task without loading any skill: `<EVAL_PROMPT>`. Write your process and output to `<scratch>/eval-<skill-name>/baseline.md`." Both eval tasks write process and output files under the scratch directory, so each Desktop Task call must use `agent_name: worker`. A background launch returns a task id immediately, not the result — poll with `task_query` until both tasks reach a terminal state and collect each result with `task_output`. Only then read the two files and write the comparison verdict yourself, covering all 5 points: 1. **Is with-skill actually better?** — explicit verdict: yes / no / mixed. 2. **If better, where?** — concrete to a procedure step or output-contract difference. 3. **If not better or worse, why?** — did the skill add unnecessary steps, overfit to a fixed format, or constrain the model's judgment? 4. **Improvement suggestions** — 3-5 concrete changes to `SKILL.md` or `references/`. 5. **Should a script be bundled?** — check the producer's process for a repeated deterministic action; also sanity-check token use (with-skill should not burn 2x baseline tokens without a quality gain). 8. Iterate only if eval exposes a real weakness. Read the comparison output, improve the skill, then repeat lint and eval. Stop when any of these is true: - the user is satisfied - the skill clearly beats or matches baseline without major regressions - two rounds in a row produce no meaningful gain ## Output contract Deliver: - a skill under the appropriate scope directory (user / agent / project) - a passing lint result - at least one evaluation round where the skill is not worse than baseline ## Failure handling - If lint keeps failing, rewrite the skill more simply instead of padding it. - If eval says the skill is worse than baseline, check whether the problem is description quality, body bloat, over-strict procedure, or whether the skill should exist at all. - If the user cancels the idea, remove the unfinished skill directory instead of keeping a half-product. ## Examples **Input**: "I just figured out how to check someone's availability in Feishu Calendar. Turn this into a skill." **Good path**: 1. Check `<available_skills>` in context and find no existing availability-checking skill. 2. Ask the scope question: this is user-agnostic and cross-project, so agent skill. 3. Draft a concise `SKILL.md` with the procedure, lint it, run eval. **Bad path**: immediately create a brand-new skill without checking for overlap first, or try to extend an existing calendar skill in this creator instead of directing to skill-refiner. ## Additional resources - `references/commands-macos-linux.md` - bash/zsh recipes (darwin/linux) - `references/commands-windows-powershell.md` - PowerShell recipes (win32) - `references/skill-template.md` - section skeleton - `references/description-rubric.md` - description guidance - `references/anti-patterns.md` - common failure modes - `references/when-to-bundle-scripts.md` - script vs subagent vs direct procedure - `scripts/lint-skill.js` - deterministic validation