Primary agents own the session; subagents handle focused work.
Build and Plan handle everyday implementation and planning. Tester and Developer run persistent testing and repair workflows. General, Explore, and Scout can be invoked as subagents when a task benefits from a narrower investigation.
| Agent | Best for |
|---|---|
| Build | Editing, running tools, and completing implementation |
| Plan | Understanding a project and designing a change before edits |
| Tester | End-to-end coverage, reproducible bugs, notes, and regression PRs |
| Developer | Root-cause fixes, regression verification, and reviewable PRs |
| Explore | Fast codebase search and dependency tracing |
| General / Scout | Delegated research and focused multi-step tasks |
Use Ultra for coordinated, component-first work.
Choose Ultra after X High in the effort selector for a model that supports tools. Ultra creates a shared design brief and a saved dependency plan, then selects a five-to-ten worker limit from the independent tasks in the prompt on v1.18.29 and later. Version 1.18.28 supports up to three workers at once. Useful components run in parallel after their dependencies are verified; agents are not created just to fill the limit. The selected model's supported reasoning settings remain in use.
On v1.18.29 and later, the coordinator records an art direction and inspected references for UI work, then builds and verifies one representative component before other components begin. Fresh desktop and mobile screenshots accompany observed layout, typography, imagery, interaction, and accessibility checks. Integration and independent review follow component verification. Unresolved findings return work for revision; screenshots and a checklist cannot guarantee design quality on their own.
- Open an agent card to inspect its conversation in the desktop app, interactive terminal, or native iPhone or Android app. Team messages and task activity use the same live workspace connection.
- The scheduler blocks unfinished dependencies and overlapping declared editing scopes. These scopes guide actual edits; they are not operating-system sandboxes.
- Handoffs and review evidence are saved locally. After a host restart, interrupted workers are identified so the coordinator can resume deliberately.
- Ultra uses more tokens. It helps organize implementation and review, but the quality of the result still depends on the model and the checks actually performed. Existing permission restrictions remain in force.
Start Ultra from a terminal
brokencode run --variant ultra "Build and verify the feature, polishing each component before integration"Switch deliberately and invoke specialists inline.
- Use Tab to switch the primary agent in the terminal UI.
- Mention a subagent with @ when you want it to investigate a bounded part of the request.
- Describe the outcome and constraints; BrokenCode supplies the current project context.
Review the approach before implementation.
Use /plan followed by your request, or choose Plan from the agent selector. Plan investigates the project with read-only permissions and prepares an approach. Review it before approving implementation or switching to Build.
Plan a change
/plan Add search to the project list and explain the affected files.Take testing and repair from investigation to review.
Start /tester with the product area or journeys you want checked. The agent maps the relevant layers, runs checks, investigates failures, and records reproducible bugs with severity, evidence, and suggested solutions. Use /developer in the same session to carry those findings into root-cause fixes, regression checks, and a draft PR.
- Both slash commands start persistent goals and continue until the requested scope is verified or blocked. They are available in the terminal and desktop on macOS, Windows, and Linux.
- Reports keep coverage, stable bug IDs, reproduction steps, expected and actual results, solutions, changed files, evidence, and limitations. The desktop goal panel shows the saved report.
- Tester can add regression tests and notes. Developer fixes product code and re-tests the original journeys. A developer workflow cannot complete with recorded open bugs or failed checks.
- The agent writes a Markdown report under the project’s report directory or .brokencode/reports. With a configured remote and access, it can open or update a draft PR containing useful changes. It reports missing access and prepares local review material when a PR cannot be created.
- Routine work follows existing permissions without repeated approval. New credentials, consequential actions, and operating-system consent still require the appropriate authorization.
- A testing report describes the exercised scope and evidence. Unavailable platforms and untested areas stay visible; passing checks do not prove the absence of every possible bug.
Test, then repair
/tester Test checkout end to end, including authentication, zero totals, errors, and recovery.
/developerThe agent can create and reuse project tools.
When a repeatable task needs a tool, BrokenCode can write a JavaScript tool, save it under .brokencode/toolbox, test its output, repair it, and call it again. Ask for the outcome you need; the agent uses its toolbox to manage the implementation.
- Saved tools accept structured input and return reusable results.
- Tests can compare actual output with expected values before reuse.
- File, shell, and connected-tool operations retain the existing permission checks.
- Tools run with execution limits and can only use the capabilities made available to the session.
Ask BrokenCode
Build a reusable tool that summarizes our test results, test it against this report, and use it for the next run.Let the agent connect the tools a task needs.
BrokenCode can search its MCP catalog and the official MCP Registry, add a relevant server to brokencode.jsonc in your project, and use its tools immediately in the same conversation. Public documentation servers connect automatically. New executable servers, unknown sources, and account access receive a focused approval or login step.
- Existing connections are reused; disabled servers are not silently enabled.
- Authentication uses the MCP OAuth or token commands, keeping credentials out of project files.
- Connection status is checked before the agent reports success.
- Routine authorized work proceeds automatically. Explicit deny rules and Plan mode remain enforced.
Ask BrokenCode
Find current documentation for this framework. If you need an MCP server, connect it and use it to check the API.Project agents can carry repeatable instructions.
Define agents in brokencode.json or as Markdown files under .brokencode/agents. User-wide definitions live under ~/.config/brokencode/agents.
.brokencode/agents/reviewer.md
---
description: Reviews changes for correctness and regressions
mode: subagent
---
Inspect the requested change, run focused checks, and report actionable findings.