Skillify

Turn any runbook into an installable skill.

You already wrote the runbook — the ops doc, the incident playbook, the "how I always fix this" note. loopskill_skillify takes that text, validates it as a skill, classifies its category, finds related skills already in the catalog by embedding similarity, and writes it into your bundle as an installable row. One call, no manual metadata entry.

Worked example — input

A plain, messy-but-real runbook (nothing pre-formatted for a catalog — this is what an internal ops doc actually looks like):

---
name: restart-flaky-nginx
description: Restart nginx when health checks fail 3x in a row, verify it
  recovers, and page on-call if it doesn't.
---

# Restart flaky nginx

When the health checker flags nginx as down 3 consecutive times:

1. SSH to the affected host.
2. Run `sudo systemctl restart nginx`.
3. Wait 10s, then `curl -sf http://localhost/healthz`.
4. If step 3 succeeds, log the recovery and exit.
5. If step 3 fails twice more, page on-call via the incident webhook.

Known gotcha: nginx sometimes fails to bind because a previous worker
process held port 443 open. `sudo fuser -k 443/tcp` before the restart
if step 2 doesn't clear the issue.

The call

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "loopskill_skillify",
    "arguments": {
      "slug": "restart-flaky-nginx-demo",
      "content": "<the SKILL.md text above>",
      "visibility": "private"
    }
  }
}

Same JSON-RPC 2.0 shape over https://app.loopskill.io/api/mcp/http/ as every other MCP call — see MCP setup for the full initialize/session handshake. visibility: "private" writes to your own bundle only; set "public_pending_review" to submit it for the public catalog.

Real output

The actual response, verified live 2026-09-01 (not a mockup):

{
  "slug": "restart-flaky-nginx-demo",
  "cookbook_id": "b28cf8bd-405d-481e-ab1a-8cccf1a6d940",
  "category": "dev-tools",
  "related_skills": [
    "super-memory",
    "musk-5-step-algorithm",
    "plan-for-goal",
    "ruthless-mentor",
    "hub-search-claude-code"
  ],
  "status": "created"
}

Read literally: the runbook was validated (frontmatter parsed OK), auto-classified into the dev-tools category, matched against 5 related skills already in the catalog by embedding cosine similarity (so a buyer browsing one sees this one too), and written as a new row in the target bundle (status: "created" — a re-run with the same slug would instead return "updated"). No manual category picker, no manual related-skills search.

What gets validated

• YAML frontmatter — name and description are required; malformed frontmatter returns {"code": "invalid_frontmatter"} instead of silently writing a broken row.
• Ownership — writes go to your bundle (resolved from your API key), never an ambiguous default. Pass target_cookbook_id to target a specific one.
• Public submissions (visibility: "public_pending_review") go through the same registry quality gate every catalog entry passes before a cold visitor can see it.