Agentic RAD

Microbus is built for rapid agent-driven development. Its conventions, structured project layout, and automation hooks all serve one goal: getting a coding agent from prompt to working microservice as quickly and reliably as possible. Bootstrapping, building, testing, deploying, and even upgrading the framework are all agent-guided.

Why Microservices Fit Agents

A microservice is a small, well-defined unit of code. That property is exactly what coding agents are best at:

• Tighter build-test-debug cycles. Microservices are small enough to build and run integration tests in seconds, giving the agent rapid feedback on every change.
• Smaller contexts that fit in memory. Each microservice is self-contained, so the agent does not need to load an entire monorepo to be productive.
• More accurate code. Focused context and clear conventions reduce the likelihood of hallucinations.
• Parallelism. Independent microservices can be developed by multiple agents working in parallel without merge conflicts.

What the Agent Produces

For each microservice, the agent writes:

• The implementation of the features you ask for - endpoints, events, configs, tickers, workflow tasks.
• A client stub so other microservices can call yours in a type-safe fashion.
• Integration tests that exercise the microservice along with its real downstream dependencies, runnable inside go test.
• A manifest.yaml cataloging the microservice’s surface, an OpenAPI document describing each endpoint, and the interservice ACL entries derived from the actual call sites.
• A CLAUDE.md design record auto-maintained alongside the code, and a PROMPTS.md trail of every prompt that shaped the microservice.

Everything follows a uniform code structure, so the agent orients itself from a quick glance at the manifest rather than reading a thousand lines.

How the Agent Is Guided

The agent does not operate on instinct. A layered guidance system trains it to write correct Microbus code:

• Agent rules. .claude/rules/microbus.md is the conventions reference - project structure, naming, error handling, idiomatic uses of the Connector API. It ships with each release of Microbus and is not edited by hand.
• Agent skills. The .claude/skills/ directory holds step-by-step playbooks for common tasks. When a developer’s prompt matches a skill, the agent follows the playbook rather than improvising, so behavior stays consistent across microservices and developers.
• CLAUDE.md. A global file at the project root holds project-wide context. A local file per microservice captures the why behind that microservice’s design choices, maintained by the agent as it works so future agents can safely evolve the code.

The Development Loop

Features are added one at a time. Each prompt is a focused, incremental change: new code only, tests written or updated, manifest kept in sync.

After the prompt, the agent builds the project, runs the integration tests, and reads any failure output. Failures get fixed and tested again. Because microservices are small, the loop is tight - typically seconds per iteration.

Local development covers IDE setup, breakpoints, and running the entire solution locally for the agent to work against.

Specialized Skills

A handful of larger skills handle longer-running jobs:

• Bootstrapping a new project lays down the project skeleton and .claude/ setup with one prompt.
• SQL CRUD microservices scaffold a complete database-backed service from a single prompt - tables, migrations, REST API, multi-tenancy, the lot.
• Upgrading Microbus walks the project through a framework version bump - bumping the module, refreshing framework-owned files, regenerating code, adapting callsites for breaking changes, and verifying the build.

For a deeper walkthrough of using these capabilities to build a microservice end-to-end, see Building a Microservice.