Agent Skills - ReasonOS Documentation

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 <name> 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.

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.

Workflow and engineering skills

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`.

Rule-family skills

One using-<family>-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:

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/<name>/SKILL.md in the workspace, then in your home directory. An existing skill library carries over without being copied:

---
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:

Skills registered by .rbs modules the workspace actually loads
.claude/skills/ in the workspace, then your home directory
Skills declared in the workspace’s rules/ tree
Skills from fetched external rule packages
The embedded built-ins

So a workspace can override any built-in skill by shadowing its name.

​How skills get invoked

​Built-in skills

​Custom skills

​RBS language: native.define_skill

​Claude Code format: SKILL.md

​Precedence