Skip to main content
Three artifacts exist so a coding agent can work against this API without guessing. They differ in size and purpose, and an agent needs at most two of them at a time.
All three are AI CMS only. They describe this API and nothing else on the platform.

​
Which one to load

You are writing code that calls this API. Load the agent skill. It is the only artifact that tells you what the SDKs actually do, including the places where they disagree with each other and the two bugs you need to route around. Reading the endpoint list instead will get you a plausible request that fails. You are planning, or you need to know what exists. Load llms.txt. It answers “is there an endpoint for repurpose?” in one read. You want to check your work. Look at the matching example project — eight of them run the same sequence in different stacks.

​
The skill file

The skill is maintained in the public SDK repository, so it is versioned and installable rather than copy-pasted:
Download it directly:

Download SKILL.md

The complete skill, as a plain file

​
Installing it

The repository already contains the skill at .claude/skills/octavia-cms/, so cloning it into your project installs the skill:
Then work in that checkout. The skill is discovered on startup and loaded whenever a request matches its description — articles, categories, forms, the AI endpoints, or reports. To use it from a different project, copy just the skill directory:
Verify it is picked up:
The file must be named SKILL.md and sit at .claude/skills/<name>/SKILL.md. The name and description in its frontmatter are what the agent matches against, so keep the description naming the resources you actually use.

​
Any other agent

The same file works as a system-prompt section, a tool description, or a retrieval-document chunk. It is written as rules rather than prose precisely so it survives being pasted into any of those without editing. For a hosted model with no filesystem, paste the block from the agent skill page verbatim as a system message. Keep it whole — the rules reference each other, and the pagination rule is meaningless without the envelope rule above it.

​
Fetching the map

​
What the skill is protecting you from

Each rule in the skill exists because ignoring it produces code that compiles and then fails at runtime. The three that bite hardest: The wrong headers. The only header is x-api-key. x-tenant-id, x-service-status, x-user-id and Authorization are set by the gateway from the key, and no SDK accepts them. If you generate code that sets them, the request is wrong and the habit is now in your codebase. Pagination in the wrong place. pagination is inside data, not beside it:
And the row key is per-resource — articleListItem for articles but author for authors, items for statistics pages. The facade is not the wire. There are two result shapes, and PHP is the outlier with no wrapper at all. Code written against JavaScript’s res.ok and res.error.message is wrong in PHP, and res.meta does not exist there.

​
A worked example

Given: “add a contact form to our Next.js app and send submissions to the CMS.” An agent that loads only llms.txt will find the forms endpoints and write something like:
getAll returns only a submissions count per form, with no id or title, so it cannot drive a picker. An agent that loads the skill writes:

​
Keeping it current

The skill lives in the SDK repository, so it is updated in the same commit as the SDK and the spec. Pull it to pick up changes:
If you find code that contradicts the skill, that is a bug in one of the two — and worth reporting, because every agent that reads the file will make the same mistake.

Agent skill

The skill itself

Example projects

Working code in eight stacks