ProtoBot is an experimental, spec-first software development system. It takes structured requirements and generates working, tested, inspected prototypes for customer demonstrations. It is the second tool in the Hermes pipeline:
flowchart LR
IdeaBot["IdeaBot<br/>(idea)"] --> ProtoBot["ProtoBot<br/>(prototype)"] --> TransferBot["TransferBot<br/>(product transfer)"]
ProtoBot is intended to produce prototypes, not final production products. The implementation is a disposable, regenerable artifact. The durable asset is the specification and the evidence showing how a particular implementation conformed to it.
ProtoBot puts human judgment before implementation and automation after the specification is approved:
- Sketching: A person and an agent define the project's Vision and Architecture, including its observable external interfaces.
- Dimensioning: They turn those interfaces into precise EARS (Easy Approach to Requirements Syntax) requirements. This approved Schematic is the human review boundary.
- Building: Autonomous Workers independently generate tests and implementation from the approved requirements. The test Worker cannot see implementation source, and the implementation Worker cannot see canonical test source.
- Inspecting: Independent Inspectors review the result for security, test completeness, code quality, specification conformance, and mutation survivors. Defects return to Building; undefined behavior blocks the work until the specification is clarified.
The core principles are:
- The specification is the source. People define what the system must do; agents determine how to implement it. Code and tests can be regenerated from the approved specification.
- Observable behavior comes first. Requirements describe stable external behavior and interfaces, not internal modules or implementation choices.
- Verification must be independent. Separating test and code generation helps prevent agents from optimizing for a visible oracle instead of the intended behavior.
- Constraints are structural. Sandboxes, repository projections, tooling, and policy enforce isolation and permissions rather than relying on prompts or agent discipline alone.
- Every component must be evaluable. A known input and measurable output are prerequisites for improving an agent, tool, or workflow stage.
At the system level, the Drafting Table hosts interactive specification work,
ears-manager governs specification artifacts and validation, the Job Site
runs autonomous Building and Inspecting, and a pluggable WMS Adapter tracks
work-item lifecycle. Project content remains in Git; workflow state and
commit-scoped conformance evidence are recorded separately.
ProtoBot is a language-agnostic monorepo. Each independently buildable component owns its native module and toolchain. The current Go components are organized as:
ears-manager/
go.mod
cmd/ears-manager/
internal/{cli,project,records,schema,specvalidation,storage}/
source-control-manager/
go.mod
cmd/source-control-manager/
internal/{cli,mcpserver,scm,gitx,host,ears,render,...}/
internal/golden/ # the golden repository fixture, replayed
internal/testing/ # the gh and ears-manager stubs of the fixture
wms/
go.mod
validation/ # backend-neutral lifecycle evaluator
memory/ # in-memory WMS conformance adapter
Additional WMS backends can use their native layout under the same monorepo,
for example wms/github/ or wms/jira/; other components can use a native
layout such as drafting-table/web/. The root go.work makes local Go
component development convenient without coupling other languages to Go.
The install targets are:
go install github.com/redhat-et/protobot/ears-manager/cmd/ears-manager@latest
go install github.com/redhat-et/protobot/source-control-manager/cmd/source-control-manager@latest
The first command slice provides check, requirement add/list/show/update/
retire, interface add/list/show, artifact get/put, proposed change-set
create/list/show/update/compare, and deterministic impact analysis. Writes
are validated against a candidate specification before an atomic file
transaction is applied; JSON output and exit statuses are deterministic.
change-set show --at FULL-SHA reads a manifest at a named commit. Project
bootstrap, immutable historical --at reads on the other commands, explicit
--against comparisons, and governed Git branch/commit/pull-request
automation remain separate follow-on work.
- ProtoBot project board
- Vision
- Architecture overview
- Architecture interfaces and constraints
ears-managerCLI integration contract- Source Control Manager
- System components
- User interaction flow
- Related work
- Open design questions
- Architecture decisions
ProtoBot is under active design and implementation. The architecture documents describe the current direction and identify decisions that remain open.
ProtoBot is licensed under the Apache License 2.0.