Create and package a Skill with ak:skill-creator

Use ak:skill-creator to create or refine a reusable Skill with concise core instructions, focused references, deterministic scripts, and validation evidence. New Skills stay in the current project by default; user-scope authoring requires an explicit request.

Choose ak:skill-creator for repeatable workflows

Use ak:skill-creator when

• A task pattern repeats and benefits from versioned instructions or scripts.
• You need to improve discovery metadata, scope boundaries, or test coverage.
• A Skill needs references, assets, packaging, portability review, or benchmark iteration.
• You want a distributable zip after validation.

Choose another workflow when

• The need is a one-off prompt, one personal preference, or general model knowledge.
• You need a bundle with commands, tools, MCP configuration, Hooks, or apps in addition to Skills. Use a plugin workflow.
• You only want to install an existing Skill. Use the appropriate discovery and installation workflow instead of authoring a duplicate.

Prepare intent and scope

Provide real usage examples, trigger phrases, expected outputs, non-goals, security boundaries, and whether objective evaluation is worthwhile. Confirm the output directory before scaffolding. The canonical artifact is SKILL.md plus only the scripts/, references/, agents/, and assets/ the workflow actually needs.

Run the Skill

Pass a Skill name or description. The Skill defines no mode flags.

/ak:skill-creator "Create a project-scoped release-notes Skill that validates headings and never publishes"

/ak:skill-creator "Create a project-scoped release-notes Skill that validates headings and never publishes"

$ak:skill-creator "Create a project-scoped release-notes Skill that validates headings and never publishes"

The bundled initializer accepts scripts/init_skill.py <skill-name> --path <output-directory>. It creates a new directory, SKILL.md, and placeholder scripts/, references/, and assets/ content; it refuses to initialize over an existing directory. Delete every unused placeholder before packaging.

Understand the creation stages

1. Capture intent. Agree on tasks, triggers, output, scope, refusal behavior, and test cases.
2. Research and de-duplicate. Check current practices, reusable tools, and installed Skills before creating a new surface.
3. Plan progressive disclosure. Keep purpose, triggers, and common workflow in SKILL.md; move detail to focused references and repeated deterministic work to tested scripts.
4. Initialize and write. Scaffold the chosen project path, replace placeholders, use relative resource paths, and keep runtime-specific behavior behind availability checks.
5. Test and evaluate. Run script tests and realistic with-Skill versus baseline evaluations when the required evaluation tooling is present.
6. Validate and package. Run the quick validator, then scripts/package_skill.py <skill-path> [output-directory] to produce a zip.
7. Iterate from evidence. Generalize from feedback without overfitting or duplicating instructions across files.

Keep file writes and distribution deliberate

The initializer creates directories and placeholder files. Packaging writes <skill-directory-name>.zip and can replace an existing archive with that name, so inspect the destination first. Tests, benchmark models, documentation lookup, and package installation can use network access, compute, tokens, and provider cost. Never place credentials, personal data, private paths, or internal prompts in Skill text, examples, logs, or assets.

Verify generated artifacts

A complete result should include:

• A project-scoped Skill directory with a valid SKILL.md.
• Specific discovery metadata, a clear use and non-use boundary, and concise imperative workflow instructions.
• Only needed references, scripts, Agent templates, and assets.
• Passing tests for included scripts and documented dependencies or environment names.
• Cross-runtime availability checks and safe fallback behavior when portability is claimed.
• Validation output and a reviewable zip when packaging was requested.
• Evaluation or benchmark evidence when the required external tooling was used.

The bundled quick validator checks basic frontmatter, required name and description fields, identifier shape, description length, and angle brackets. It does not prove line limits, script tests, reference quality, security, or runtime portability; review the full checklist manually before distribution.

Troubleshoot and limits

The included executable helpers initialize, validate, and package; broader benchmark and description-optimization steps described by the workflow require their separate tooling when available. The initializer and validator also use different maximum slug checks, so use a short kebab-case slug. The two release snapshots used for this page contain the same authoring workflow and scripts.