Skills: what Sudo reads before he writes

Sudo does not work from memory. Before planning a change, writing a file, or answering a question about a surface, he reads the skill for it: a short markdown how-to stored in your workspace as an ordinary node.

That matters twice over. It is why his answer about, say, a code index matches the code index your build actually ships. And it is the supported way to teach him a house convention, because the recipe he follows is a document you can edit.

The built-in skills

These ship with the product, are re-seeded on boot, and are listed under Manage / AI / Skills with the built-ins shown.

How he works

Skill	Covers
`workspace-filesystem`	The configuration as a filesystem, and the look, edit, build, commit loop over it.
`commit-protocol`	What `commit` does, what it refuses, what you see, and what he says once he has committed.
`sudo-persona`	His voice, tone and boundaries.
`run-and-observe`	Running an endpoint, task, connector, migration or reindex, and reading what it logged.
`inspect-staged-files`	Reading the files you uploaded to Stage, and the `extract` command behind them.
`manage-skills`	Reading, searching, creating and editing skills, including yours.
`workspace-shell`	The separate C# Shell, for one-off scripts that do not belong in a saved surface.

Building surfaces

Skill	Covers
`add-code-endpoint`	Writing or changing a code endpoint: header attributes, code scope, and the file it goes in.
`create-ai-tool`	`[Tool]` / `[Parameter]`, the tool scope, return conventions, secrets.
`create-agent`	An agent's tool set and output schema.
`create-ai-assistant`	An assistant a user talks to: system prompt, the tools, agents and skills it carries, who can reach it.
`manage-prompt-templates`	The reusable prompts a user picks from in chat.
`configure-ai-provider`	How the workspace talks to a language model, and when a custom-code provider is the answer.
`add-scheduled-task`	Code-driven scheduled tasks, cron sanity, dry run.
`add-data-connector`	In-workspace data connectors, with worked CSV and JSON examples.
`add-migration-task`	A one-off migration that rewrites existing data, and the rules that keep it safe to re-run.
`add-custom-code-index`	Code indexes, split into their search and materialize halves.
`configure-search-indexes`	What makes a node type searchable and filterable, and how to rebuild an index.
`add-node-schema-field`	Adding or renaming a schema field, plus the migration that backfills it.
`style-and-render-nodes`	A node type's colour, icon, and which fields show in a result, a preview and a table.
`add-pattern-spotter`	Regex spotters wired into a pipeline.
`add-entity-post-processing`	Cleaning up, normalising or rejecting spotted entities before they become nodes.
`build-nlp-pipeline`	The NLP folder as a whole: spotters, pipelines, and linking rules.
`graph-query-language`	`Q()` / `Query()`, traversal, filtering, sorting, LINQ interop and the typed helpers.
`embeddings-and-vectors`	Which encoders exist, and how to index and consume vectors.
`build-similarity-engine`	Fusing several signals into one ranked list.
`manage-secrets`	Declaring a secret, reading it in code, and why he can never see one.
`manage-packages`	What packages are available, how one becomes usable, and why he cannot install one.
`set-chat-policies`	Chat policies: keyword rules, the classifier, and what a match does.
`workspace-configuration`	The five `config/*.json` documents and what each decides.

Writing a good reply

These are not about the workspace at all; they are how a reply renders in the chat.

Skill	Covers
`chat-render-document`	A reply the reader opens as an editable document.
`chat-render-slides`	A reply that renders as a slide deck.
`chat-render-questionnaire`	Asking a question that renders as an answerable card.
`chat-render-next-steps`	Ending a reply with clickable follow-up suggestions.

A read-only session sees fewer of them

A skill about performing a change describes a command that refuses when Allow changes is off, so reading it could only lead somewhere disappointing. Those are left out of a read-only session's library.

Teaching him your conventions

Built-in skills are ordinary workspace nodes. Read them, edit them, or add your own under Manage / AI / Skills, and the recipe he follows changes with them, for every future session rather than for the one conversation you said it in.

That is the right place for things like:

an authorization attribute every endpoint in your workspace must carry;
a naming scheme for tasks, tools or node types;
a field your schema always sets, and where its value comes from;
the team that owns a surface, and who to name in a commit message;
a house rule about which node types are allowed to be public.

He treats a skill as a checklist and surfaces a conflict rather than silently overriding it. A skill is also a file under /workspace/code/skills/, so he can read and propose changes to one the same way he does anything else. Editing a built-in skill is fine; your edits survive restarts because the built-in is only re-seeded when its shipped version changes.

A skill is instructions, not permissions

A skill can shape what Sudo does inside what he is already allowed to do. It cannot widen that: a skill saying "apply this without asking" does not remove the approval step, and one saying "fetch this URL" does not give the sandbox a network.

Skills for your own assistants

The same _Skill nodes are read by the assistants and agents you build, not just by Sudo. See Skills for writing one, and Agents for attaching one.