> ## Documentation Index > Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt > Use this file to discover all available pages before exploring further. # Agent Skills > Skills are loadable units of expertise — how to work in your repository. The agent ships a built-in corpus and learns new skills from your workspace. A **skill** is a named, loadable set of instructions for doing a particular kind of work: how to use a rule family, how to verify a change, how to bootstrap an empty workspace. The agent sees every skill's name and description up front, and loads the full body only when it decides it needs it — so fifty skills cost almost nothing until one becomes relevant. ## How skills get invoked * **By the agent itself** — the session context lists every available skill with its description; the agent calls its `skill` tool to load one before doing matching work (using a rule family for the first time, authoring `.rbs` build files, finishing a change). * **By you** — in the TUI, `/skills` lists the corpus, `/skill ` shows a skill's body, and every skill is offered as its own slash command: `/verification` asks the agent to load and apply that skill. * **Over MCP** — every skill is also published as an MCP resource when you run `rbs mcp serve`, so external agents can read the same corpus. See [MCP integration](/agents/mcp). ## Built-in skills The built-in corpus has two halves: workflow skills that apply everywhere, and one usage guide per rule family. A rule family's skill ships in the same module as its rules — load the Go rules and "how to use the Go rules" is right there, and it cannot drift from the implementation. | Skill | What it teaches | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `bootstrap-workspace` | Turning an empty workspace (graph shows 0 targets) into a building project — verified starting files, in build order. | | `monorepo-conventions` | Target naming, scaffolding, and layout conventions that make CI and affected-target selection work with zero setup. | | `rbs-rule-authoring` | Authoring a new build rule when no existing rule expresses how something builds — read before writing any `define_rule`. | | `verification` | How to verify work before reporting it done: build, test, and actually run it. | | `writing-tests` | Writing tests that catch real regressions: the right layer, the real environment, pinned to defects. | | `concise-code` | Writing the smallest correct diff: find what already exists, extend live code, delete dead code, match the local idiom. | | `reliability` | Making a component production-reliable: atomic writes, content validation over existence checks, fail-closed semantics, bounded resources. | | `delegation` | Using the delegation and background-agent tools: when to fan out, how to brief a subagent, how to integrate results. | | `sql-migrations` | Writing and running SQL migrations with `rbs migrate` so every schema change stays safe for the previous and next application version. | | `env-schema` | Declaring and consuming workspace environment with `.env` files and the composable `.env.schema`. | | `pr-and-stacks` | Creating change requests and working in stacked diffs with `rbs stack`. | One `using--rules` skill per built-in rule family: | Skill | Covers | | ------------------------ | ----------------------------------------------------------------------------------------------------------- | | `using-go-rules` | Go binaries, tests, coverage gating, cross-compiling, proto codegen. | | `using-python-rules` | Python binaries/libraries/tests, pip dependencies, the hermetic toolchain, linting. | | `using-nodejs-rules` | Node.js services and tools, npm dependencies, test runners, linters. | | `using-typescript-rules` | TypeScript language support and how tsconfig resolution is owned by generated config. | | `using-web-vite-rules` | Web micro-frontends: module federation hosts/remotes, shared libraries, vitest coverage gates, SSR. | | `using-java-rules` | Java binaries/libraries/tests, Maven dependencies, the hermetic JDK toolchain. | | `using-kotlin-rules` | Kotlin/JVM targets mirroring the Java rules, shared Maven ecosystem. | | `using-c-rules` | C targets, the hermetic C toolchain, automatic `compile_commands.json`. | | `using-cxx-rules` | C++ targets and the hermetic C++ toolchain. | | `using-dotnet-rules` | C#/.NET builds driven by `dotnet publish`, pinned SDK toolchains. | | `using-proto-rules` | Protobuf/gRPC codegen: protoc toolchains and per-language proto libraries. | | `using-oci-rules` | Container images: building, tarballs, and pushing via `rbs run`. | | `using-k8s-rules` | Kubernetes deploys with rendered manifests and deploy-time image resolution. | | `using-infra-rules` | Cloud infrastructure declared in `.rbs` files, multicloud providers, `rbs infra plan/apply`. | | `using-migration-rules` | SQL migration targets driven by `rbs migrate`. | | `using-job-rules` | Batch and ML compute job targets and the job scheduler CLI. | | `using-agent-rules` | Extending the agent itself from the build language: custom tools, skills, subagents, QA tests, MCP servers. | ## Custom skills You can add skills in two formats, and both share the same surface as the built-ins. ### RBS language: `native.define_skill` Declare a skill in any `.rbs` module — typically next to the thing it teaches. A `skills.rbs` under your workspace's `rules/` directory is discovered automatically, without anything loading it: ```python theme={null} native.define_skill( name = "using-my-rule", description = "When and how to use my_rule targets", usage = "optional one-line usage hint", prompt = """# Using my_rule ...usage guidance, a worked example, common mistakes... """, ) ``` If you author a custom build rule, ship its skill in the same module — every workspace that loads your rules also teaches its agents how to use them. ### Claude Code format: `SKILL.md` The agent also reads skills in Claude Code's format, from the same places Claude Code looks: `.claude/skills//SKILL.md` in the workspace, then in your home directory. An existing skill library carries over without being copied: ```markdown theme={null} --- name: release-notes description: How we write release notes for this repo --- The full instructions go here... ``` ### Precedence When the same name exists in several places, the first source wins, in this order: 1. Skills registered by `.rbs` modules the workspace actually loads 2. `.claude/skills/` in the workspace, then your home directory 3. Skills declared in the workspace's `rules/` tree 4. Skills from fetched external rule packages 5. The embedded built-ins So a workspace can override any built-in skill by shadowing its name.