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.
`access-control`	Who may see what: the membership and ownership edges behind every access decision, the order the check applies, node-type and field restrictions as they travel in a schema file, querying and searching on a user's behalf instead of unfiltered, endpoint and AI tool access modes, and access-group declarations.
`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 administrator sees fewer of them

A skill about performing a change describes a command that refuses for an administrator who may only read the workspace, so reading it could only lead somewhere disappointing. Those are left out of that 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.