Open Knowledge Write Skill

Writing an OpenKnowledge skill

You are helping the user author an Agent Skill — a SKILL.md file (plus optional references/ and scripts/) that teaches an AI agent how to do a recurring task. In OpenKnowledge a skill is a first-class, versioned, installable artifact: you author it with the write / edit skill verbs, then install it into the user's editors.

Skills earn their keep by being recognized at the right moment and followed faithfully. Most of the craft is in two places: a description that triggers reliably, and a body short and concrete enough that the agent actually does what it says. Work the stages below in order, but jump to where the user already is.

Stage 1 — Capture intent and classify the skill

Gate — does this already exist? Check BEFORE you build. First list managed skills with skills({}), then read any likely match with skills({ name }); these are the Project/Global skills OpenKnowledge already manages. Also search the public marketplace with skills({ query: "<2-4 trigger words>" }) before drafting when the task sounds reusable beyond this project. Each marketplace row returns name, source, and description; inspect the strongest descriptions, then import a chosen candidate with import({ source, skill: name, add: [...] }) and adapt it only if reuse is the right call. Use the Vercel find-skills skill, npx skills find <query>, or manual skills.sh search only when the OK MCP skills({ query }) path is unavailable. If the user already has a skills.sh page open, pass the full skill-page URL as source, e.g. import({ source: "https://www.skills.sh/<owner>/<repo>/<skill>", add: [...] }) — the middle segment is the REPO, not a literal skills. Do not run npx skills add as the default install path in this flow: import through OpenKnowledge (import({ source, skill, add })) so the skill lands as a real folder with provenance, versioning, and managed fan-out; add says where it goes, and install afterwards changes where it lives. Use 2-4 concrete trigger phrases from the user's request plus the domain or tool name, then open/read the strongest candidates' descriptions before judging. If an existing or public skill covers most of it, STOP and recommend reuse — a near-duplicate with overlapping triggers mis-fires and dilutes both. If a public skill is close but not exact, decide WITH the user whether to import/adapt it into OpenKnowledge, install it outside OK with the Skills CLI, or write a narrower companion whose description explicitly hands off to it. Build a new skill only when it is genuinely distinct. Surface the overlap and the installed-skill plus marketplace search outcome before drafting or writing anything. This is a disclosure gate: tell the user what you checked, what matched, and why reuse/import/adapt/new-skill is the right next step. Never discover overlap after the skill is written. If skills({ query }) / skills.sh is unreachable, say so plainly and continue with the installed-skill check.

Ask only what you can't infer:

• What recurring task should this skill handle? Get one concrete example.
• Skill type, because it sets how much rigor to apply:
• Reference / technique (most skills) — "how to do X." Prose body, examples.
• Discipline — enforces a behavior the agent tends to skip under pressure (e.g. "always write a failing test first"). These need the RED baseline + pressure-testing in Stage 4–6; reference skills don't.
• Degrees of freedom (calibrate body precision to task fragility): high (free prose — judgment tasks), medium (parameterized steps), low (a fixed scripts/ command — when any deviation breaks the result). Don't over-specify a judgment task or under-specify a fragile one.

Stage 2 — Resolve scope FIRST (never infer silently)

Scope determines where the skill lives and where install fans it. This is the user's decision and has different blast radius — make it explicit.

Default heuristic: inside an OK project and the task is specific to it → project; "for all my work / globally" → global; otherwise ask one question. State the choice and its consequence before writing.

Developing a skills repo or plugin? Then NEITHER scope applies. If the repo you are working in is itself a skill distribution — a plugin (e.g. a .claude-plugin/ manifest or marketplace listing) or a catalog repo that shelves skills as skills/<name>/ for others to import — the skill you are authoring is a product of that repo, not an installation into it. Write it in the repo's own layout, beside its sibling skills, following the format the repo already uses. Do not place it under .claude/skills/ or .agents/skills/ here, and do not install it: consumers get it by installing the plugin or importing from the repo, and the plugin's own repo loads nothing from itself. install is only for skills the current project or user should load. If you are unsure whether the repo is a distribution or a consumer, ask — writing to the wrong place ships a skill nobody can find.

Stage 3 — Plan the contents

• Body = the durable, reusable instructions — under ~500 lines. If it's growing past that, move depth into references/<topic>.md (loaded only when needed) and point at it from the body. For a project skill the reference auto-connects in the graph either way, so a backticked ` references/<topic>.md path is fine; use a [[references/<topic>]]` wiki-link only when you want the mention to be a clickable inline link. For a global skill use a plain backtick path — global references aren't graph docs, so a wiki-link there dangles. Keep references one level deep.
• Do NOT include: a README/CHANGELOG/QUICK_REFERENCE, install instructions for the skill itself, version histories, or anything host-specific. The skill is the instructions, not documentation about the instructions.
• For a discipline skill, plan the failure mode you're correcting and how you'll prove the skill fixes it (Stage 4).

Stage 4 — RED baseline (discipline skills only)

Before writing the skill, run the scenario WITHOUT it and capture what the agent does wrong — verbatim, including its rationalizations ("the test is trivial so I skipped it"). Those rationalizations are the exact loopholes the skill body must close. Run the scenario in a fresh agent session with the skill absent — a new chat, a sub-agent, or a second terminal — and keep the transcript; if you have no way to run it clean, reason through the baseline with the user instead. Skip this stage for plain reference skills.

Stage 5 — Draft the skill

Author the source with the skill verb (fs-direct; a live preview updates if a server is running):

write({ skill: { name: "<lowercase-hyphen-name>", description: "<triggers>", body: "<markdown>", scope: "project" } })

Frontmatter contract (validated on write — get it right):

• name — lowercase letters, digits, hyphens; ≤64; equals the directory.
• description — ≤1024 chars, no XML tags, no `version` field. See Stage 7.
• Nothing else. OK never injects its own frontmatter; bookkeeping lives in .ok/.

Write the body as direct instructions to the agent (imperative, second person), concrete over abstract.

Add depth files — references/*.md (loaded on demand) and scripts/* (shown as text, never executed by OK) — through the skill verbs, never native Write/cat:

# write one or more bundle files (independent of body — no need to resend SKILL.md)