Agent Skill generation

reed skill generate produces an Agent Skill pack — a SKILL.md and its supporting files — from a configured OpenAPI spec.

json

{
  "skill": {
    "ingestion": {
      "output": "generated/skill-ingestion",
      "name": "acme-ingestion",
      "concepts": ["concepts/events", "concepts/identity"]
    }
  }
}

Then:

sh

reed skill generate

outputpathrequired

Where the pack is written, inside your repository.

namestring

1–64 characters, matching ^[a-z0-9]+(-[a-z0-9]+)*$ — the Agent Skills format’s own constraint, not one Reed invented.

conceptsstring[]

Page references bundled verbatim into the pack.

concepts is the part that matters

A spec describes endpoints. It does not describe what your concepts mean, which call order is correct, or which failure is retryable — and those are exactly what an agent gets wrong without help.

concepts names pages of your own documentation to bundle into the pack verbatim. The prose you already wrote for humans goes with the tools.

References are validated twice: the schema catches malformed entries and duplicates within the array, and a content-aware check catches a reference that resolves to no real page. An unresolvable concept fails the run rather than silently bundling nothing — a Skill missing the one page that explained the call ordering is worse than a Skill that refused to build.

It lands in your repository

Like MCP generation, output is a path in your project. Reed does not host or distribute the pack, and generating it changes nothing about your rendered site.

Keeping it current

Regenerate when the spec or the bundled pages change, and commit the result. Because the concepts are references rather than copies in your config, editing the underlying page and regenerating is enough — there is no second copy of the prose to keep in sync.