Guides and writing skills

In one line: how Slima hands its own rules to your AI tool — the tools that answer "what can I do here", the operating guides, and the writing skills.

What this solves

Your AI tool does not arrive knowing how Slima works. It does not know that whether a file is manuscript or reference decides if the words count, that a .map cannot be rewritten whole, that every write is a commit.

It can find all of that out by colliding with it — one wrong write, one refusal, try again. Or it can ask. These tools are the asking.

Tool	What it returns
get_capabilities	What this server supports right now: which extensions you may write, how content types resolve, the tools available, the guide index
list_guides	The guide index: each one's title and when to load it
load_guide	One guide, in full
list_writing_skills	The writing-skill index
load_writing_skill	One writing skill, in full

Start the session with get_capabilities

Slima's MCP server tells the AI this the moment the connection opens: call get_capabilities first. Every field it returns is derived from the contract the server actually enforces, so it cannot drift from real behaviour the way a written description can.

Four blocks come back:

• A policy per extension, plus what that policy means in words (generic writes allowed / field-level tools only / not writable at all)
• Content types: the values, and how a new file's type is decided when you don't say (inherited from the containing folder, reference at the root)
• The tool list
• The guide index

get_capabilities lists every tool this server exposes, which makes it the tiebreaker when a client's tool descriptions and the server disagree.

Plus a handful of facts that cost people real work when they were left implicit: every write is a commit and there is no save step; only manuscript counts toward word counts, streaks and Beta Reader; edit_file beats a whole-file write because the author may be editing the same file; refer to files by path, because tokens are not stable identity across the author's devices.

The guides

Guides teach how to operate Slima. Load the one you need when you are about to do the thing it covers, not all of them up front.

Guide	When to load it
getting-started	First time on a Slima book. It is the map, and it points at the next one
book-structure	Before creating files. Manuscript vs reference, and how not to make the author's words vanish from their own word count
version-control-basics	Before a large rewrite. How writes become commits, and how not to overwrite what the author wrote while you were reading
notes-and-foreshadowing	Leaving notes, or tracking a setup and its payoff
comments-review-loop	Joining the editorial loop: leaving comments, answering ones left for you, and what stays the author's decision
beta-reader	Before commissioning a Beta Reader report — what it costs, how long it takes, how to poll for it
team-knowledge-base	Working inside a publisher or studio team. What the shared knowledge is, and what you will not be shown
script-studio	When you hit an older Script Studio book. What is structured, and what you may write
format-beats	Before touching a .beats file
format-timeline	Before touching a .timeline file
format-script	Before touching a .script file
format-relationship-map	Before touching a .map file
format-geomap	Before touching a .geomap file

A wrong slug does not come back as a bare "not found" — it comes back with the list of real ones, so one wrong guess still lands on the right guide.

The format-* guides are worth loading early: they cover the rules of the type itself (which fields are content and which are layout, what removing one thing takes with it), while Structured editing tools covers how the tool is called.

The writing skills

Writing skills are craft procedures, not Slima operation. They are the same step-by-step procedures the in-app AI Coach follows.

Skill	What it does
character_develop	Deepen an existing character: arc, voice, relationships, growth
character_create	Walk the author through building a new character from scratch
plot_architect	Design or analyse structure, outlines and narrative arcs
scene_craft	Polish one scene: pacing, sensory detail, tension, transitions
tension_map	Analyse the tension curve across chapters or the whole book
voice_polish	Identify and strengthen the book's voice and style
dialogue_coach	Make dialogue sound spoken, and keep character voices distinct
consistency_audit	Systematic check for timeline, setting, character and logic contradictions
world_build	Design or analyse worldbuilding systems: magic, culture, politics, economics
opening_hook	Analyse and improve the opening

The split in one line: if the task is about the writing, load a skill; if it is about operating Slima, load a guide.

Why none of this ships inside the package

Because you pin the package version. A guide written into the client stops at whatever version you pinned, and keeps teaching, in the same confident tone, something the server no longer supports.

Served from Slima, all of it updates the moment Slima deploys — for every client, pinned or not.

There is a second benefit. The type-specific parts of those guides are the same words the in-app AI Coach reads. One text, two readers, which is what keeps an outside AI and the in-app AI from teaching two different rules about the same file.

How to use it in practice

Saying this at the start of the conversation is cheaper than correcting it later:

Call get_capabilities as soon as you connect to Slima.
Then load the book-structure guide.
Before touching a timeline or a beat board, load the matching format-* guide.

Related

• Docs: Structured editing tools
• Docs: Query book schema with the resource
• Docs: What MCP can do, file type by file type
• Docs: What Slima MCP is