---
name: skailify
description: "Use when a user wants to move an existing coding-agent skill (a Claude Code skill under ~/.claude/skills/, or any SKILL.md directory) into a skaile library so it can be versioned, placed in a domain, and published. Trigger phrases: 'skailify my skill', 'import this Claude skill into my library', 'move my ~/.claude skill into skaile', 'turn my CC skill into a skaile asset', 'add my local skill to the library'. Drives `skaile asset import` + `skaile library domain` and verifies with `skaile validate`."
metadata:
  version: "0.1.0"
  source: AUTHORED
  stage: alpha
  tags:
    - skaile
    - library
    - import
    - migrate
    - claude-code
    - skill
    - domain
    - manifest
  requires:
    - "skill:skaile-author-asset"
    - "skill:manifest-compliance"
---

# Skailify a skill

Move an existing coding-agent skill into a **skaile library** — frontmatter
normalized to the skaile schema, placed under a domain, and wired into
`skaile.manifest.yaml` — in one `skaile asset import` call. For the
source/library/store model and publish lifecycle read **[skaile-author-asset]**;
for naming rules read **[manifest-compliance]**.

## What `import` does that a copy doesn't

A Claude Code `SKILL.md` carries only `name` + `description`. A skaile asset
additionally needs a `metadata:` block (`version`, `stage`, `tags`) and a
canonical lowercase-kebab name. `skaile asset import` performs that transform,
scaffolds the domain on demand, and auto-appends the `skaile.manifest.yaml`
entry. The low-level `skaile asset migrate` only copies bytes — use `import`.

## The flow

1. **Confirm a library exists.** `skaile library list`. If none:
   `skaile library init personal` (add `--git <url>` to make it publishable).
2. **Pick a domain.** A domain is the first-level dir and the publisher
   namespace (`@<domain>/<name>`). List with `skaile library domain list`.
   Create one if needed — `import --domain` will also scaffold it:
   ```bash
   skaile library domain create docs            # → docs/DOMAIN.md, publisher @docs
   ```
3. **Import.** By bare name (resolved from `~/.claude/skills/`) or by path:
   ```bash
   skaile asset import starlight-docs --domain docs
   skaile asset import ./path/to/my-skill --domain docs --version 1.0.0
   ```
   Companion files in the skill dir (e.g. `file-loader.ts`, `references/`) are
   copied along. A non-kebab name is slugified and reported.
4. **Verify.** `skaile validate <library-path>` — must report all manifest(s)
   valid before you publish.

## Options that matter

| Flag | Use |
|---|---|
| `--domain <name>` | Place + scaffold the domain. Omit → library root, repo-level publisher. |
| `--version <semver>` | Stamp when the skill ships none (default `0.1.0`). |
| `--stage <stage>` | `alpha` (default) \| `beta` \| `stable`. |
| `--to <library>` | Target a non-default library. |
| `--no-normalize` | Copy frontmatter verbatim (rare — only if already skaile-shaped). |
| `--commit` | Auto-commit in a git-backed library. |

## After import

- Edit the stamped `metadata.tags` if `import` left them empty.
- To publish: `skaile library publish <kind>:@<publisher>/<name>@<version>`
  (needs a git-linked library — see [skaile-author-asset]).
- Re-running `import` for the same `(kind, name)` updates its manifest entry in
  place rather than duplicating it.

## Common mistakes

| Mistake | Fix |
|---|---|
| Using `asset migrate` then hand-editing frontmatter | Use `asset import` — it normalizes + wires the manifest. |
| `domain create` / `domain list` errors "no default library" | One library is used automatically; with several pass `--library`. |
| Skipping `skaile validate` | Always validate before publish — catches non-canonical names. |
| Expecting `~/.claude/skills` bytes to stay in sync | `import` copies; future edits to the library copy don't reach `~/.claude`. |