Skip to content
Docsturbobase.io

Agent skills

Shipped

Skills are the standing rules your instance gives its AI. A skill is a short instruction — “always filter the entity table by entity type”, “anything over $5,000 needs CFO approval before it is proposed” — that is placed into the assistant’s instructions on every relevant turn, whether or not the question mentions it.

They live at /admin/skills, alongside the MCP servers tab.

Skills or knowledge base?

Section titled “Skills or knowledge base?”

Your instance has two places to write down what it knows, and they behave differently. Putting something in the wrong one is the most common reason a rule “doesn’t stick”.

Knowledge base Skills
How the AI sees it Retrieved — the pages most related to the question are pulled in Injected — placed in the instructions every matching turn
Right for How your business works: processes, thresholds, conventions, context Rules that must hold every time, whether or not anyone asks
If it is long Fine — only the relevant part is retrieved Costly — it is in every prompt, so keep it short
When it does not apply The question was about something else Never; that is the point

The test: would the AI get this wrong if nobody reminded it? Then it is a skill. Would a person only need it when they went looking? Then it is a knowledge-base page.

A hard constraint written as a knowledge-base page will be followed when someone asks a question near it, and quietly ignored the rest of the time. That is the failure this split exists to prevent.

Drafts and publishing

Section titled “Drafts and publishing”

A skill’s text goes into your AI’s instructions word for word, so it is treated like a change you deploy rather than a note you jot down. There are two states, exactly as for a knowledge-base page:

  1. Draft. Every new skill starts here, and a draft is injected nowhere. This is where skills written by your app developers (turbobase skills push) and skills proposed in the Studio arrive.
  2. Published. The skill is live — its text is in the instructions on every matching turn.

Publish takes effect straight away. There is no separate “now release it” step: publishing a skill records a release containing that skill and puts it in force. Publishing one rule never ships someone else’s half-finished one, because the release is scoped to the skill you published.

Retracting is just as immediate, because you should never have to wait to stop something going wrong:

  • Unpublish it — move it back to draft — and it stops being injected on the next turn. Its text and history are kept, so publishing it again is one click.
  • Delete it and it is gone for good; earlier releases keep their own copy.

Draft and published are the only two states. If you remember a separate on/off switch beside them, it is gone — it answered the same question publishing already answers, and unpublishing does everything it did, just as fast.

Editing the text of a live skill is the one thing that is not immediate: your edit is saved but the AI keeps reading the published version until you publish again. So you can rewrite a rule that is currently in force without it changing under you mid-edit.

History and rollback

Section titled “History and rollback”

Every publish and unpublish is recorded as a numbered release, showing exactly which rules were live and what changed. Administrators can roll back to an earlier one when a rule turns out to make answers worse.

A rollback restores the text. It will not re-publish a skill you unpublished — something taken down for a reason stays down.

Where a skill applies

Section titled “Where a skill applies”

Each skill lists the surfaces it reaches. Every skill reaches Pilot; the rest are opt-in:

  • Pilot — your in-product assistant, and the chat channels that route through it. Always on.
  • External MCP clients — tools connected to your instance’s MCP server.
  • Authoring sessions — the CLI and Claude Code, when a developer is building an app against your instance.
  • Proposal Studio — solution drafting, solutioning and app generation.

Turning on the last two is usually what you want for engineering rules: they are what stop an app developer’s AI session rediscovering the same constraint every time.

A skill reaches every surface it is exposed to, on every turn. Connector skills additionally require their source to be connected.

Where skills come from

Section titled “Where skills come from”
  • Written by an administrator in the app.
  • Pushed by an app developer — turbobase skills push takes the rules recorded under ## Agent rules in a project’s INSTANCE-LEARNINGS.md and files them as drafts. The rules grouped under one ### sub-heading arrive as a single skill named after that heading, so a session that recorded twenty rules gives you a handful of reviewable entries rather than twenty. See Connect Claude Code.
  • Proposed in the Studio — a proposal can carry a skill solution when the right answer is not to change a system but to change what the AI always knows.
  • Bundled — first-party skills that ship with the platform. These are read-only; editing one forks it into a skill of your own.

Every route lands a draft. Writing a skill and publishing one are always separate acts — nothing an AI proposes reaches your instructions on its own.

Publishing is normally something an administrator does in the app. It can also be delegated to a developer’s access token, but only deliberately: the token needs the Publish skills capability, which is never granted by default and has to be ticked when the token is minted. It can be revoked on its own without withdrawing the developer’s ability to deploy apps, every publish records who did it, and anything published this way can be rolled back or deleted with one command. A token that can deploy an app cannot, by itself, change what your AI is told.

Section titled “Related”