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

# Use ReasonOS with your AI assistant

> Describe your goal, discover the tools your connection supports, and ask for work you can verify.

Give your assistant this page and describe the outcome you want. You can ask it
to explore ReasonOS, help configure your team, work on an issue, or check a
change. You do not need to write RBS or Starlark to set that direction. When a
workflow needs build definitions, your assistant can inspect the connected
version's rules and propose the source for you to review.

Your assistant supplies the reasoning and edits. ReasonOS supplies the project
records, branch workspaces, build graph and supported execution and evidence
services. Which of these your assistant can use depends on its MCP connection,
your permissions and the running deployment.

## Start with an example you can inspect

> I lead an engineering team evaluating ReasonOS. First explain which parts
> would help us take an issue through implementation and verification. If my
> assistant is connected, inspect one project and an existing issue I choose.
> Show its linked change and any available CI or QA evidence, including the
> revision and result. Tell me what is unavailable. Start with reads; propose
> any changes or executions before doing them.

Without a connection, your assistant can explain the documented workflow and
its prerequisites. With a supported authenticated connection, it can inspect
records you may access. This example does not assume a public demo workspace
or create resources. Ask your assistant to identify missing evidence.

For a result to be useful, ask your assistant to explain what it actually read
or executed, what ReasonOS contributed, and what still needs a person or a
working environment. Read [the platform overview](https://docs.reasonos.com/index.md) for its components
and [the team workflow](https://docs.reasonos.com/workflow/getting-work-done.md) for the connected path.

## Choose a next step

* **Set up your team.** Follow [organization onboarding](https://docs.reasonos.com/onboarding.md) and
  [AI access](https://docs.reasonos.com/platform/ai-accounts-and-keys.md). Ask which prerequisites are
  configured, missing or unverified for your goal. A saved credential or URL
  does not establish a working connection. Setup currently uses the documented
  settings and available tools; this page does not provide an automatic wizard.
* **Work on an issue.** Follow [Work on an issue](https://docs.reasonos.com/workflow/work-on-an-issue.md).
  Start with [Work](https://docs.reasonos.com/platform/work.md). Choose the organization,
  project and issue, read its acceptance criteria, then agree the scope and
  branch before editing. A managed branch server stays on its assigned branch;
  another branch means another node, not checking out the shared server.
* **Validate a change.** Follow [Validate a change](https://docs.reasonos.com/workflow/validate-a-change.md).
  Discover the actual build and test targets using
  [the build graph](https://docs.reasonos.com/build/packages-and-targets.md), then select bounded checks.
  Keep [coverage requirements](https://docs.reasonos.com/build/commands.md) and report failed, skipped,
  cached and unavailable results separately. [QA](https://docs.reasonos.com/platform/qa.md) also needs a
  running application and its own configuration. Building a current
  `qa_test` declaration emits its definition; platform QA execution is a
  separate operation that can consume model resources.
* **Review the evidence.** Follow [Review a change](https://docs.reasonos.com/workflow/review-a-change.md).
  Link the issue, change, exact revision and available
  CI or QA result. A prior passing run does not verify a later commit. A
  merged change does not establish deployment, and a CI deployment report
  alone does not verify what is running.
* **Resume interrupted work.** Follow [Recover and resume](https://docs.reasonos.com/workflow/recover-and-resume.md).
  Read the current issue, branch and prior result
  before retrying. Preserve other edits and drafts. If a write may have
  completed without an acknowledgement, inspect the destination first; do
  not replay it simply because the connection failed.

These are directions for using existing features. A complete demonstration
still needs the relevant tools, project state and environment. Ask the
assistant to name a missing capability rather than simulate success.

## Know which connection you have

[Local RBS MCP](https://docs.reasonos.com/agents/mcp.md#serving-rbs-as-an-mcp-server) works on a local
workspace's files, rules and build graph. It does not by itself connect to
hosted ReasonOS issues or your organization's settings. Its curated tool list
includes build and test: those execute project code and can write artifacts
or access the network. Curated does not mean a read-only execution sandbox.

[Managed project-work MCP](https://docs.reasonos.com/agents/mcp.md#work-tools-on-managed-branch-servers)
acts through the person's delegated access and project scope. Other configured
ReasonOS connections may expose a wider organization tool list. Use the MCP
configuration supplied by your deployment or managed session; do not copy a
coworker's credentials or put tokens in a prompt, repository or handoff.

Clients differ in how they discover tools, resources and server instructions.
If yours does not load this page automatically, provide its link explicitly.
The assistant should inspect the tools offered by its current connection;
report any missing tools before planning an action.

## Instructions for your assistant

1. Ask for the customer's goal and identify the connection and mode. For an
   organization connection, use `whoami` and `list_projects` when offered;
   in a branch-scoped session, keep its supplied project and branch scope.
   Read the relevant existing issue and current cycle before proposing work.
2. Discover current tools and schemas. Use `api_catalog` for supported routes
   when available. For local RBS authoring, inspect `rbs_rules`, skills exposed under
   `rbs://skills/*`, and embedded source, then use `rbs_validate`; static validation is
   not a successful build. Do not invent rule names, attributes or primitives.
3. State prerequisites and the smallest useful action. Respect the customer's
   existing authorization. Obtain authorization for new grants, spending,
   destructive actions or publication when it has not already been given.
   Enter secrets only through the product's secure settings or approved client
   configuration, never through the conversation.
4. Read before editing, preserve concurrent work, and reconcile uncertain
   outcomes. Use a managed node only for its assigned branch. Report definite
   refusal, partial completion and unknown completion accurately.
5. Return inspectable evidence: project and branch, source revision, tool or
   execution result, freshness or cache status, and limits. A source edit,
   a successful transport response and a running deployed feature are
   different milestones.

Keep feature details in the linked guides. If a guide and the connected
runtime differ, report the difference and inspect the current schema before
acting. Tool discovery and authorization still apply to every request.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.