git:20261017.35d0f50 to git:20261017.c0800e0

---

name: skill-creator

description_zh: "创建、编辑或忠实导入用户明确要求的自定义 Skill；不用于普通任务执行或单纯安装外部包。"

description_en: "Create, edit or faithfully import explicitly requested custom Skills; not ordinary task execution or plain external-package installation."

---

# skill-creator

Create, edit, or faithfully import a custom Skill through host-owned metadata tags, `<<<skill-file>>>` whole-file blocks, or the native package importer. Do not mutate the Skill directory with generic file or shell tools.

## Read only the reference needed for this request

Before authoring, read the matching reference through this Skill's read ref:

- New Skill, SKILL.md body rewrite, new reference, or bundled script → [authoring.md](references/authoring.md).

- Name, description, category, routing hints, or any SKILL.md frontmatter work → [metadata.md](references/metadata.md).

- URL, local directory, ZIP, attachment, pasted existing Skill, or any source-preserving import → [importing.md](references/importing.md) and [metadata.md](references/metadata.md).

- Deleting files, package cleanup, or removing a whole Skill → [file-deletion.md](references/file-deletion.md).

Do not read unrelated references. A category-only edit needs only `metadata.md`; a body-only guide edit normally needs only `authoring.md`; an import needs `importing.md` plus `metadata.md`.

## Routing gate

**Explicit creation intent required.** Use this Skill only when the user explicitly asks to create, edit, convert into, or import a Skill, or when already inside a bound Skill editor. Do **not** consult this skill for a plain "install this URL / install this GitHub repo / add this project" request. A runnable external package belongs to `package-installer` unless the user explicitly wants a portable custom Skill. If that outcome is genuinely ambiguous, ask one concise clarification.

## Non-negotiable protocol

- **Use host-owned mutation paths only.** Use `import_skill_package` for an explicitly supplied local Skill directory/ZIP when available, metadata tags for metadata-only changes, and `<<<skill-file>>>` for changed file content. Never use `edit_file`, `write_file`, or shell redirects under the Skill directory.

- **Whole-file replacement.** Every `<<<skill-file>>>` block replaces one complete relative file. Read an existing file before changing it; a partial body erases omitted content.

- **Protocol completeness beats prose depth.** Close every file block with `>>>` on its own line and close the outer `</skill>` before user-visible prose. If response space is tight, shorten the Skill body; never truncate or omit a protocol delimiter.

- **No protocol files.** Do not dump `<skill>`, `<skill-meta>`, or file blocks into the workspace. The host parses them inline.

- **One container per Skill.** Multiple containers are legal only when the request or source contains multiple distinct Skills. Never merge multiple source `SKILL.md` files into one Skill.

- **Skills are independent.** Do not name, invoke, or read another Skill from this Skill's body, references, scripts, or examples. Orchestration belongs to the caller.

- **Use the user's UI language** for newly authored human-readable instructions and user-visible prose. Keep frontmatter keys, identifiers, paths, commands, and code unchanged. Imported prose remains faithful by default.

- **The host owns completion.** A valid `<skill>` container or file block only requests a mutation. Only a successful host result proves it was applied; before that, or after a failed or omitted mutation, never say the Skill is created, updated, saved, ready, or available. Describe pending mutations as “将创建” or “已提交，等待应用”.

## Decide create versus edit

- Bound Skill editor: mutate the current Skill without an outer `<skill>` wrapper for ordinary file/meta edits.

- Unbound create: omit `<skill_id>` and include a complete new `SKILL.md` plus category.

- Pure discussion or no actual change: emit no protocol.

Before a new Skill, compare its name and typical objects/actions with Available skills. If one substantially overlaps, stop and ask whether to use it or still create a new one. Otherwise create in the same turn.

## Metadata-only shape

Unbound Commander:

```text

<skill>

<skill_id>existing-id</skill_id>

<category>data</category>

</skill>

```

Bound Skill editor:

```text

<skill-meta>

<category>data</category>

<negative_examples>

- unrelated request

</negative_examples>

</skill-meta>

```

Allowed metadata tags are `<name>`, `<description>`, `<description_zh>`, `<description_en>`, `<category>`, `<negative_examples>`, `<applicable_domain>`, and `<prerequisites>`. Omit unchanged values. Read `metadata.md` before writing them.

## Whole-file shape

```text

<<<skill-file path=SKILL.md

---

name: short-ascii-id

description: compact current-language routing description

---

# Instructions

...

>>>

```

- `path` is relative to the current Skill root; absolute paths and `..` are rejected.

- The terminator is `>>>` alone on its own line.

- In Commander, wrap changed files for one Skill in `<skill>...</skill>` and add `<skill_id>` only for an edit.

- In a bound editor, emit file blocks directly with no outer wrapper.

- A new Skill requires a complete `SKILL.md` and category. A metadata-only edit requires no file block.

- File deletion uses the confirmation protocol in `file-deletion.md`, never an empty replacement block.

## Execution sequence

1. Confirm explicit Skill intent and classify create, edit, or import.

2. Read only the references required by the routing table.

3. Read the current Skill and any user-supplied source material.

4. Preserve source or design the smallest self-contained capability; choose guide versus script deliberately. For a straightforward guide, prefer the required use/non-use boundary, preconditions, 3–7 steps, and output shape over a long tutorial or repeated examples.

5. Validate metadata, category, runner commands, safety, relative links, and the final resource inventory.

6. Emit minimal metadata tags and complete changed files, follow User-visible prose below, then stop for the host result.

## Safety gate

Do not author credential-store reads, dynamic or decoded execution, download-and-execute pipelines, startup persistence, runtime self-modification of Agent/Skill specs, or writes outside the authorized workspace. Convert required values into explicit inputs or stop and explain the boundary.

## User-visible prose

If a requested requirement remains unmet or the result changes the required usage conditions, explain that difference and any required next step through the session's user-visible reply channel, outside mutation and file blocks. Writing it inside the Skill does not inform the user. Otherwise, omit redundant completion prose when the host result suffices.

Keep explanations concise and about the user's outcome. Do not expose protocol tags, frontmatter mechanics, internal modes, ids, or design jargon. Do **not** show source provenance by default. Mention it only when asked or when a failed read/import needs repair.