Skip to main content

​
Design philosophy

Simple terminal operations — rqb init, rqb serve, rqb validate, rqb exec — work best when run directly. They are fast, composable, and don’t need an agent in the loop. Slash commands exist for tasks that are genuinely complex: where the right answer depends on understanding your codebase, your domain model, or the relationships between data — not just executing a formula.

​
Available commands

/rqb

Create specs, enrich expected responses, or build and run pipelines. Routes automatically based on what you pass.

/rqb-debug

Diagnose a failing endpoint or pipeline across validation, execution, and diff.

​
/rqb

When to use: Creating new specs, enriching expected responses and tests, or building and running flow pipelines. The command routes based on your argument:

​
Scan mode

What makes it intelligent: The agent doesn’t just run rqb import project and stop. When automatic discovery produces stubs, the agent reads your handler source code — request/response types, DTOs, model classes — and produces specs with real field names and semantically accurate example values. A user.email field becomes "[email protected]", not "string". What the agent does:
  1. Tries rqb import project first (OpenAPI or running server)
  2. If stubs are produced, reads handler source to enrich field shapes
  3. If nothing is detected, finds route files and reads full type definitions
  4. Creates specs via rqb_author MCP tool (validates before writing, never overwrites)
  5. Runs rqb validate api-docs/ then rqb index

​
Enrich mode

What makes it intelligent: The agent uses a bounded evidence ladder — reads the spec, inspects the matching handler and referenced DTO/schema files, optionally executes the live dev endpoint, then stops and asks for an example if the shape is unknown. It never guesses. What the agent does:
  1. Reads the spec and its route handler
  2. Runs rqb_exec with infer_expected: true if the server is up — uses the live response
  3. Writes real field values to ## Expected response
  4. Adds ## Assertions: at minimum status and one body.<key>: exists
  5. Adds ## Tests: happy path + auth failure + one validation error

​
Flow mode

What makes it intelligent: Before writing a single line, the agent reasons about data dependencies — which step produces authToken? Which downstream steps need it? What should be asserted at each step to make the flow meaningful, not just a sequence of “status 200” checks? What the agent does when building:
  1. Reads existing specs to understand what data each endpoint returns
  2. Maps the capture/inject chain before writing
  3. Identifies missing specs (offers to create them)
  4. Writes the pipeline file with meaningful assertions at each step
  5. Validates with rqb validate
What the agent does when running:
  • Executes rqb_flow MCP tool
  • Reports each step’s status, captured values (secrets masked), and first failure with diagnosis

​
/rqb-debug

When to use: An endpoint is returning an unexpected result, a spec diff is failing, or a pipeline is breaking at a specific step.

​
Single endpoint

What the agent does:
  1. Locates the spec via rqb_search MCP or rg
  2. Validates the spec structure
  3. Dry-runs to check what’s being sent (baseUrl, auth, path params)
  4. Executes and interprets the result:

​
Pipeline

What the agent does:
  1. Reads all step files — checks order, capture expressions, inject names, referenced specs
  2. Runs the full flow via rqb_flow MCP
  3. Identifies the first failing step
  4. Debugs that step in isolation with captured values from prior steps injected as --var

​
Terminal commands — use these directly

​
Supported agents