Workspace connector and skills

A workspace skill is a skill your team writes - a SKILL.md and the files it points at - that your members' AI picks up from Kythene. Change it and the change reaches them on their next fetch, with no release and nobody reinstalling anything. It's how you write down "this is how we deploy" or "this is how we answer a refund request" once and have the agents of the people you give it to follow it.

Skills travel over the workspace connector, so that comes first.

Which members get which skills is set by toolkits: a published skill reaches only the members whose toolkits hold it, so a new workspace's skills reach nobody until one does.

Both are on the Team and Enterprise plans, and on self-host with a licence that includes them.

The workspace connector

Each workspace has its own MCP address:

https://kythene.com/mcp/s/<workspace>

Your own host if you self-host. It's at the top of the Connect your AI page, under Connector for your workspace's name, with a copy button. Add it to your client the same way as any other Kythene connection (the steps are in MCP and agents), and it shows up named after the workspace - Kythene - Acme, say.

It carries Kythene's own tools, the same ones as everywhere else, plus the workspace's skills and the tools of any servers it has added. Every call lands in that workspace without your agent having to say so, and a call that names a different workspace is refused - so an agent on the Acme connector can't write into your personal workspace by mistake.

Which address to use

There are two, and they differ in one thing:

• You're in one workspace on a paid plan - use its connector. You lose nothing and gain the skills.
• You're in several - add one connector per workspace whose skills you want. Clients keep each connector's tools apart, so the same tool in two workspaces can't collide. It's a bit more setup, but separate workspaces are usually separate work anyway.
• You'd rather have one connection for everything - keep the all-workspaces address. Your agent reaches every workspace, just without their skills.

You can add both, but your agent then sees every Kythene tool twice, so pick one per workspace.

On a free plan, or one that's lapsed, the connector refuses to connect with a message saying why, and the Connect page shows that instead of the copy button. The all-workspaces address keeps working either way.

How members' AIs get skills

The connector serves the published skills to the members whose toolkits hold them, viewers included. Owners and admins write them; nobody else can, and your own drafts stay with you.

Claude's clients don't read skills over MCP yet, so the connector also hands them over through tools:

1. brief - which your agent calls at the start of a session - lists the workspace's skills by name and description (up to 30; list_skills has the rest).
2. When a task matches one, the agent calls get_skill, which returns its SKILL.md and the list of its other files.
3. It fetches a file by path when the instructions point at it.

That's the same step-by-step loading a client does with native skills, and native skills take over when your client supports them. Members only ever get the published version.

Writing a skill

A skill is a directory with SKILL.md at the top:

deploy-api/
  SKILL.md
  references/steps.md

SKILL.md opens with frontmatter giving the skill's name and a description. The description is what an agent reads to decide whether the skill applies, so say when to use it, not just what it is:

---
name: deploy-api
description: Deploying the API service to production. Use when asked to ship, release or deploy the API.
---

# Deploying the API
...

Publish it either way:

• Ask your agent. "Publish ./deploy-api as a workspace skill" - it uses publish_skill.
• The CLI. kythe skill publish ./deploy-api. The directory is the whole skill; hidden files are left out and named so you know.

Kythene checks the skill before it reaches anyone. One that wouldn't load is refused with the reason, and what members already have is untouched. The rules:

• The name is lowercase letters, digits and single hyphens, up to 64 characters.
• Every file is UTF-8 text - skills are served as text.
• kythene-workflow is taken: it's Kythene's own skill, already on every connector.

Publishing says how many people the skill now reaches.

Revising it

Publish again and it's the next version, live for everyone at once - the fast path for a fix. To edit what's there:

kythe skill get deploy-api --out ./deploy-api-edit    # into a new or empty directory
# edit, then
kythe skill publish ./deploy-api-edit

Trying a change first: drafts

Publish with --draft (or ask your agent for a draft) and the change stays yours. Members keep getting the published version until you publish the draft.

How you try it depends on your client. One that reads MCP skills gets your draft in place of the published version, on your own connector only. On Claude's clients, which don't yet, ask your agent to get_skill the draft and follow it, or read it back with kythe skill get deploy-api --draft.

A skill has one draft at a time. If someone else's draft is waiting, writing over it is refused, naming whose it is: it gets published or discarded first, so nobody's work vanishes unseen.

kythe skill publish ./deploy-api --draft
kythe skill state deploy-api published --note "rollback step"

A skill's states

Over MCP that's set_skill_state; on the CLI, kythe skill archive|restore|delete|discard <name>, or kythe skill state <name> <state>. --version N publishes an earlier version again, which is the rollback. Archiving and deleting over MCP stop and ask you first, because both take the skill out of everyone's kit.

Settings -> Skills shows every skill with its state, who it reaches, and its version history, down to who published each version and when. It's for owners and admins, and read-only apart from the starters below. A lapsed plan keeps it readable, so you can still see what you had.

Settings -> Skills also lists four starters: onboard-a-new-client, write-a-ticket, write-up-a-decision and meeting-notes-to-actions. Preview one to read it, then Use this copies it into your workspace as a draft that only your own AI gets, to edit before you publish it. A name the workspace already has, in any state, deleted included, is refused, and nothing is written over it. Copying needs a plan with toolkits. Without one, Use this is withheld and the reason is shown, but the preview still works.

See the MCP reference for the four skill tools and the CLI reference for kythe skill.