Skip to main content
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 for its components and the team workflow for the connected path.

​
Choose a next step

  • Set up your team. Follow organization onboarding and AI access. 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. Start with Work. 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. Discover the actual build and test targets using the build graph, then select bounded checks. Keep coverage requirements and report failed, skipped, cached and unavailable results separately. QA 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. 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. 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 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 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.