Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →inkeep/open-knowledge-write-skill
Use when the user wants to create, author, write, or design a new Agent Skill (a SKILL.md) — for OpenKnowledge or for their editors — including requests like 'help me write a skill', 'make a skill that…', 'turn this workflow into a skill', or improving an existing skill's triggering and discipline. Also use when capturing reusable agent guidance that should live as an installable skill rather than a one-off prompt. Covers choosing scope (project vs global), the SKILL.md frontmatter contract, pro
Passed 18 of 18 test cases with the skill, and 6 of 18 without it.
and 12 more in the full report
12 fixed6 passed either way0 still failing0 broke4 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
I need to inspect the contents of references/schemas.md within an existing skill named graphql-builder. What command or tool invocation should I run to inspect this reference file content?
| Checked | Without skill | With skill |
|---|---|---|
| Invokes skills with name and file parameters to read the specific bundle file | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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
test cases passed, vs 6 / 18 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.