Skip to content
Mirobody
Get Started

Development

Contributing

How to build, change, and contribute to the Mirobody C++ engine.

Welcome Contributors!

Section titled “Welcome Contributors!”

Mirobody is a C++11 engine built with CMake.

Ways to Contribute

Section titled “Ways to Contribute”
Add a vendor

A new vendor::Vendor in src/health/vendor/ — see Provider Integration

Add an MCP tool

A .cpp in res/mcp_tools/ using the MIROBODY_REGISTER_TOOL macro

Fix bugs

Report and fix issues

Improve docs

Enhance this documentation

Build the engine

Section titled “Build the engine”

Mirobody builds against system-installed libraries on Linux / WSL / macOS; Windows uses vcpkg.

The toolchain, the per-platform dependency lists, build.sh’s backend tokens, and the optional CMake feature gates are all in Development Setup — that page is the single copy, so this one doesn’t repeat it.

Terminal window
./build.sh            # host arch, PostgreSQL backend, into ./build
./build/mirobody      # run it (reads ./config.yml)

Change workflow

Section titled “Change workflow”

Fork & branch

Terminal window
git checkout -b feat/your-change

Make your change

Follow the existing structure — one concern per file, headers document the “why”. If you add a self-registering unit (an MCP tool or agent), drop the .cpp in the matching res/ directory; the build picks it up.

Build and test

Terminal window
./build.sh
ctest --test-dir build            # or: ./build/tests/mirobody_tests

See Running tests.

Commit & push

Terminal window
git add -A
git commit -m "feat: describe your change"
git push origin feat/your-change

Open a pull request

With a clear description: what it does, why, and how to test.

Code conventions

Section titled “Code conventions”
  • C++11. Match the surrounding style; the codebase leans on the standard library, rapidjson, and thin internal wrappers (client::HttpClient, storage::*) rather than heavy frameworks.
  • Header comments explain intent — especially why something is a stub or a workaround. New vendor stubs must record their reason (gated / contract mismatch / no such endpoint).
  • Don’t fabricate contracts. If a wire format isn’t publicly confirmable, leave an honest stub (throw VendorError/DocumentError with a reason) rather than guessing.
  • Add or update tests for behavior you change (Catch2, under tests/).

Pull Request Guidelines

Section titled “Pull Request Guidelines”
Title format

Conventional commits: feat:, fix:, docs:, refactor:, test:, chore:.

Description
  • What the PR does and why
  • How to build / test it
  • Linked issues
Checklist
  • Builds with ./build.sh
  • ctest passes
  • Tests added / updated
  • Docs updated if behavior changed
  • Stubs (if any) document their reason

Questions?

Section titled “Questions?”
GitHub Issues

Bug reports and feature requests

Mirobody Support

Direct technical support

Thank you for contributing!