mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
docs(how-to): split the walkthrough into docs/how-to/ + add the business-workflow chapter
Decompose the single docs/how-to.md into an indexed 5-chapter guide under docs/how-to/: README (index/pitch/teaser/TOC), 01 the company, 02 it starts with you, 03 the cells build it, 04 the last call and the loop. Image/video paths rewritten to ../, inter-chapter nav added, the Prompter-build screenshots preserved. Adds a new chapter 05 — the business workflow: the charter, the Cockpit, the Secretary, and the web-research / strategy-engine config toggles, with the end-to-end 'feel it' walkthrough. README links repointed to docs/how-to/README.md. All image links verified; reflow-check clean.
This commit is contained in:
Renn F
@@ -66,7 +66,7 @@ One full loop, put simply:
|
||||
|
||||
**— Full circle —**
|
||||
|
||||
**[See the full walkthrough, with screenshots →](docs/how-to.md)**
|
||||
**[See the full walkthrough, with screenshots →](docs/how-to/README.md)**
|
||||
|
||||
**[Or watch the full panel walkthrough (video) →](docs/videos/panel-full-walkthrough.mp4)**
|
||||
|
||||
@@ -93,7 +93,7 @@ roboco/
|
||||
├── agents/
|
||||
│ └── prompts/ # Agent system prompts (roles, teams, identities)
|
||||
├── docs/
|
||||
│ ├── how-to.md # Visual walkthrough of the workflow
|
||||
│ ├── how-to/ # Visual walkthrough — 5-chapter guide (start at README.md)
|
||||
│ └── rag/ # Agent knowledge base (indexed into RAG)
|
||||
├── alembic/ # Database migrations
|
||||
├── CLAUDE.md # Claude Code guidance
|
||||
|
||||
-169
@@ -1,169 +0,0 @@
|
||||
# How RoboCo works
|
||||
|
||||
|
||||
|
||||
RoboCo is a virtual software company — 22 AI agents and one human: you. Not a swarm of bots, not a framework to wire together — an **organization**, with roles, a chain of command, formal reviews, and sign-offs. You don't micromanage it; you run it like a CEO. Drop work in at the top and the company carries it all the way through planning, building, review, and documentation, then brings it back to your desk for the final word. You act at the two ends; the organization fills in everything between.
|
||||
|
||||
What keeps twenty-two agents from dissolving into noise is that RoboCo is relentlessly opinionated about *how* work happens: everything is a task, no task moves without acceptance criteria, and every task walks the same strict lifecycle — built, QA'd, documented, PM-reviewed, approved — each step gated by role. The structure is the point. It is what turns a roster of models into a company that actually ships.
|
||||
|
||||
And the proof is this page. The screenshots below aren't a mock-up: they follow RoboCo building one of its *own* features — the **Prompter**, the task-authoring page now living in this very control panel. RoboCo's agents scoped it, built it across three cells, failed and re-ran its QA, documented it, and opened the real pull request you'll see at the end. RoboCo builds RoboCo — that is the whole proof of concept.
|
||||
|
||||
> The panel is your one window into the company. Every task, agent, message, journal, and pull request is live in front of you.
|
||||
|
||||
**Prefer video?** A [full screen-recording of the panel](videos/panel-full-walkthrough.mp4) walks through every page and detail end-to-end — useful as a first tour before diving into the screenshots below.
|
||||
|
||||
|
||||
|
||||
*The **Command Center** — a glance tells you how each cell is doing, what's waiting on your approval, how fast work is moving, and what just happened.*
|
||||
|
||||
---
|
||||
|
||||
## The shape of the company
|
||||
|
||||
Work in RoboCo is always a **task**, and tasks nest into a tree that mirrors the org itself:
|
||||
|
||||
```
|
||||
CEO (you, the human)
|
||||
├── Intake (on-demand interviewer — drafts a task with you)
|
||||
└── Board ── Product Owner · Head of Marketing · Auditor (silent)
|
||||
└── Main PM (coordinates the cells)
|
||||
├── UX/UI cell ── PM · 2 Devs · QA · Documenter
|
||||
├── Frontend cell ── PM · 2 Devs · QA · Documenter
|
||||
└── Backend cell ── PM · 2 Devs · QA · Documenter
|
||||
```
|
||||
|
||||
In practice, one feature becomes a small tree of work — a parent task at the top, a branch for each cell underneath, every node carrying its own status, git branch, and pull request:
|
||||
|
||||
|
||||
|
||||
*A feature in motion. The parent task fans out to the UX/UI, Frontend, and Backend cells, and each child moves through its own lifecycle — in progress, awaiting review, completed — on its own branch.*
|
||||
|
||||
---
|
||||
|
||||
## Following a task through the company
|
||||
|
||||
### 1 · It starts with you
|
||||
|
||||
You describe what you want — a feature, a fix, an entire product. The way in is the **Task Assistant** — which is the **Prompter** itself, the very feature whose build the rest of this page follows. (You're about to use the tool RoboCo built for itself; further down, you'll watch the company build it.) Instead of filling a form from memory, you give it a rough idea and it reads your *actual* codebase, asks a few sharp questions, and hands back a properly-formed task — an objective, a per-cell breakdown, and the acceptance criteria that define what "finished" really means.
|
||||
|
||||
|
||||
|
||||
*Where it starts — point the assistant at a project (one repo) or a product (several), drop in a rough idea, and it spins up an agent that reads that code before it says a word.*
|
||||
|
||||
|
||||
|
||||
*No canned questions. The agent clones the scope and reads the real surface first, so everything it asks and proposes is grounded in what your code actually does.*
|
||||
|
||||
<!-- Optional: re-capture prompter_run_2 after the markdown-rendering fix ships (its headers will render cleanly instead of as raw ###). -->
|
||||
|
||||
|
||||
*It comes back having done the homework — naming the real pages, services, and files, laying out what to build and where, and refining with you over a couple of turns until the spec is right.*
|
||||
|
||||
<!-- prompter_draft_card.png is the captured smoke shot; optionally re-capture after the draft-card cell-badge dedupe ships, for cleaner "Board-led across Backend Frontend" badges. -->
|
||||
|
||||
|
||||
*The proposal, ready to launch. Keep chatting to refine it, send it to the **Board** for review, or approve it straight to the Main PM — your call, on one card.*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
*From a rough sentence to a real, scoped task in a single chat — acceptance criteria and all, already moving through the company.*
|
||||
|
||||
From here, every task follows the path you chose for it. To show that journey end to end, the rest of this page follows the **Prompter's own** trip through the company — from this same starting point to a merged pull request. Send a task to the **Board** and their job is to pin it down: the Product Owner and Head of Marketing turn the draft into a settled spec, sharpening the requirements and the acceptance criteria before anyone writes a line of code. The Auditor watches the whole time but never interferes.
|
||||
|
||||
|
||||
|
||||
*The Product Owner working a task over — pinning down the requirements and the must-haves before anyone writes a line of code.*
|
||||
|
||||
|
||||
|
||||
*Two seats at the table. The Product Owner and the Head of Marketing review the same task from their own angles and put their reasoning on the record — this is the Board building the actual spec for the Prompter, the feature this whole walkthrough follows.*
|
||||
|
||||
### 2 · Nothing moves without your green light
|
||||
|
||||
The Board hands the reviewed task back to you as a **notification** and waits. You make one call: send it forward, or send it back. Approve it, and the **Main PM** picks it up, splits it across the cells, and sets them running.
|
||||
|
||||
|
||||
|
||||
*The Board's verdict lands in your notifications and pauses there. A single approval is what turns the whole company on.*
|
||||
|
||||
|
||||
|
||||
*The notification itself, spelled out: the Board has finished, the task is recorded, and nothing happens until you say so — Approve & Start hands it to the Main PM; reject it and it goes back. This is the first of the only two moments the company needs you.*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 3 · The cells take over
|
||||
|
||||
Underneath the Main PM are three cells — **UX/UI, Frontend, Backend** — each a small team with its own PM. Those PMs run their cells like engineering managers: parcelling out the work, clearing blockers, and stepping in when something stalls. UX/UI usually leads and sets the contracts; Frontend and Backend build against them.
|
||||
|
||||
|
||||
|
||||
*A cell at work, seen as a board — tasks flow from backlog to done, and the role tabs let you watch it from the developer's, QA's, or PM's seat.*
|
||||
|
||||
### 4 · The work gets done — and checked
|
||||
|
||||
This is where it's actually built. Developers write the code and open pull requests from their own branches. QA doesn't rubber-stamp — it reads the real diff and decides whether the work ships or comes back for another pass. Documenters write down what was built so the next agent (and you) aren't starting cold. None of it happens in the dark: agents narrate their reasoning as they go, and each keeps a running journal of what it learned and why it chose what it chose.
|
||||
|
||||
|
||||
|
||||
*QA earning its seat. On this Prompter task it read the work, marked it **failed**, and sent it back — the developer's notes and the QA verdict sit side by side on the record, with the Auditor watching the whole exchange. Real review, not a rubber stamp; the gate only opens when the work is right.*
|
||||
|
||||
|
||||
|
||||
*Every agent keeps a journal — reflections, decisions, and lessons. Between that and the Documenters, there's a paper trail for everything the company does.*
|
||||
|
||||
### 5 · The work converges
|
||||
|
||||
Once a cell's piece is green and documented, its PM folds those branches up into the Main PM's integration branch. Three independent streams of work come back together into one. Each task brings its branch, pull request, commits, and docs along with it:
|
||||
|
||||
|
||||
|
||||
*One finished unit — branch, pull request, commits, and docs all attached. This is the thing that travels up the merge chain.*
|
||||
|
||||
|
||||
|
||||
*Three streams becoming one history. Each cell's work lands as its own **verified** commit, co-authored by the agent that wrote it — the UX/UI design, the backend endpoint, the frontend page — folded together into the single pull equest that comes back to you.*
|
||||
|
||||
### 6 · The last call is yours
|
||||
|
||||
The cells' work is folded up, the Main PM opens the **final pull request** into `master`, and the company goes quiet. The decision comes back to exactly where it started — with you. You're the only one who ever touches `master`, and anything waiting on you sits in the **CEO Approval Queue** until you act.
|
||||
|
||||
|
||||
|
||||
*The hand-off back to you. The integrated PR is open, every cell has delivered, QA is green — and it waits. Nothing reaches `master` without your word.*
|
||||
|
||||
|
||||
|
||||
*And it is a real pull request, on the real repository — not a simulation. The company's work shows up exactly where any engineer would look for it.*
|
||||
|
||||
|
||||
|
||||
*Open it and the whole brief is there — the objective, what was built, the board-led split across the three cells, and the company's own notes — written by RoboCo, for you to read before you decide.*
|
||||
|
||||
|
||||
|
||||
*The real diff, laid out for you to inspect — the migrations, the endpoints, the panel components. This is the substance you are signing off on.*
|
||||
|
||||
|
||||
|
||||
*Your two words. **Approve & Merge** and it ships to `master`; **Request Changes** and it goes around for another lap. The last call has the same shape as the first — one decision, yours alone.*
|
||||
|
||||
---
|
||||
|
||||
## And round it goes
|
||||
|
||||
You handed the company a task; it scoped it, built it, failed and re-ran its own QA, documented it, and brought it back as a single pull request for your sign-off. That's one complete pass.
|
||||
|
||||
|
||||
|
||||
*The whole tree in its final state — the parent waiting on your approval, every cell's task done beneath it. One feature, start to finish, with you at only the two ends.*
|
||||
|
||||
And the feature in these screenshots is the proof. The **Prompter** wasn't built for a demo — it's a real page RoboCo's agents shipped to RoboCo's own control panel. A company building its own product, in front of you, is the whole point of RoboCo. What makes that hold together isn't a clever model or a lucky run; it's the **organization** — the roles, the gated lifecycle, the reviews and the sign-offs that keep twenty-two agents moving as a company instead of a crowd. Run as many of these passes as you like, across as many projects as you like.
|
||||
|
||||
---
|
||||
|
||||
*RoboCo is early-stage, work-in-progress software (v0) — expect rough edges. The [README](../README.md) covers setup, architecture, and the security model.*
|
||||
@@ -0,0 +1,28 @@
|
||||
# The shape of the company
|
||||
|
||||
What keeps twenty-two agents from dissolving into noise is that RoboCo is relentlessly opinionated about *how* work happens: everything is a task, no task moves without acceptance criteria, and every task walks the same strict lifecycle — built, QA'd, documented, PM-reviewed, approved — each step gated by role. The structure is the point. It is what turns a roster of models into a company that actually ships.
|
||||
|
||||
Work in RoboCo is always a **task**, and tasks nest into a tree that mirrors the org itself:
|
||||
|
||||
```
|
||||
CEO (you, the human)
|
||||
├── Intake (on-demand interviewer — drafts a task with you)
|
||||
├── Secretary (your chief-of-staff — acts only on your command)
|
||||
└── Board ── Product Owner · Head of Marketing · Auditor (silent) · PR Reviewer (inbound external PRs)
|
||||
└── Main PM (coordinates the cells)
|
||||
├── UX/UI cell ── PM · 2 Devs · QA · Documenter
|
||||
├── Frontend cell ── PM · 2 Devs · QA · Documenter
|
||||
└── Backend cell ── PM · 2 Devs · QA · Documenter
|
||||
```
|
||||
|
||||
The walkthrough that follows traces the delivery path — Intake, the Board, the Main PM, the cells. The Secretary and the research and strategy engines sit one layer up, steering the company as a whole; they get their own chapter at the end.
|
||||
|
||||
In practice, one feature becomes a small tree of work — a parent task at the top, a branch for each cell underneath, every node carrying its own status, git branch, and pull request:
|
||||
|
||||
|
||||
|
||||
*A feature in motion. The parent task fans out to the UX/UI, Frontend, and Backend cells, and each child moves through its own lifecycle — in progress, awaiting review, completed — on its own branch.*
|
||||
|
||||
---
|
||||
|
||||
Next: **[It starts with you →](02-it-starts-with-you.md)**
|
||||
@@ -0,0 +1,59 @@
|
||||
# It starts with you
|
||||
|
||||
## 1 · It starts with you
|
||||
|
||||
You describe what you want — a feature, a fix, an entire product. The way in is the **Task Assistant** — which is the **Prompter** itself, the very feature whose build the rest of this guide follows. (You're about to use the tool RoboCo built for itself; further on, you'll watch the company build it.) Instead of filling a form from memory, you give it a rough idea and it reads your *actual* codebase, asks a few sharp questions, and hands back a properly-formed task — an objective, a per-cell breakdown, and the acceptance criteria that define what "finished" really means.
|
||||
|
||||
|
||||
|
||||
*Where it starts — point the assistant at a project (one repo) or a product (several), drop in a rough idea, and it spins up an agent that reads that code before it says a word.*
|
||||
|
||||
|
||||
|
||||
*No canned questions. The agent clones the scope and reads the real surface first, so everything it asks and proposes is grounded in what your code actually does.*
|
||||
|
||||
<!-- Optional: re-capture prompter_run_2 after the markdown-rendering fix ships (its headers will render cleanly instead of as raw ###). -->
|
||||
|
||||
|
||||
*It comes back having done the homework — naming the real pages, services, and files, laying out what to build and where, and refining with you over a couple of turns until the spec is right.*
|
||||
|
||||
<!-- prompter_draft_card.png is the captured smoke shot; optionally re-capture after the draft-card cell-badge dedupe ships, for cleaner "Board-led across Backend Frontend" badges. -->
|
||||
|
||||
|
||||
*The proposal, ready to launch. Keep chatting to refine it, send it to the **Board** for review, or approve it straight to the Main PM — your call, on one card.*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
*From a rough sentence to a real, scoped task in a single chat — acceptance criteria and all, already moving through the company.*
|
||||
|
||||
From here, every task follows the path you chose for it. To show that journey end to end, the rest of this guide follows the **Prompter's own** trip through the company — from this same starting point to a merged pull request. Send a task to the **Board** and their job is to pin it down: the Product Owner and Head of Marketing turn the draft into a settled spec, sharpening the requirements and the acceptance criteria before anyone writes a line of code. The Auditor watches the whole time but never interferes.
|
||||
|
||||
|
||||
|
||||
*The Product Owner working a task over — pinning down the requirements and the must-haves before anyone writes a line of code.*
|
||||
|
||||
|
||||
|
||||
*Two seats at the table. The Product Owner and the Head of Marketing review the same task from their own angles and put their reasoning on the record — this is the Board building the actual spec for the Prompter, the feature this whole walkthrough follows.*
|
||||
|
||||
## 2 · Nothing moves without your green light
|
||||
|
||||
The Board hands the reviewed task back to you as a **notification** and waits. You make one call: send it forward, or send it back. Approve it, and the **Main PM** picks it up, splits it across the cells, and sets them running.
|
||||
|
||||
|
||||
|
||||
*The Board's verdict lands in your notifications and pauses there. A single approval is what turns the whole company on.*
|
||||
|
||||
|
||||
|
||||
*The notification itself, spelled out: the Board has finished, the task is recorded, and nothing happens until you say so — Approve & Start hands it to the Main PM; reject it and it goes back. This is the first of the only two moments the company needs you.*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
Previous: **[← The shape of the company](01-the-company.md)** · Next: **[The cells build it →](03-the-cells-build-it.md)**
|
||||
@@ -0,0 +1,37 @@
|
||||
# The cells build it
|
||||
|
||||
## 3 · The cells take over
|
||||
|
||||
Underneath the Main PM are three cells — **UX/UI, Frontend, Backend** — each a small team with its own PM. Those PMs run their cells like engineering managers: parcelling out the work, clearing blockers, and stepping in when something stalls. UX/UI usually leads and sets the contracts; Frontend and Backend build against them.
|
||||
|
||||
|
||||
|
||||
*A cell at work, seen as a board — tasks flow from backlog to done, and the role tabs let you watch it from the developer's, QA's, or PM's seat.*
|
||||
|
||||
## 4 · The work gets done — and checked
|
||||
|
||||
This is where it's actually built. Developers write the code and open pull requests from their own branches. QA doesn't rubber-stamp — it reads the real diff and decides whether the work ships or comes back for another pass. Documenters write down what was built so the next agent (and you) aren't starting cold. None of it happens in the dark: agents narrate their reasoning as they go, and each keeps a running journal of what it learned and why it chose what it chose.
|
||||
|
||||
|
||||
|
||||
*QA earning its seat. On this Prompter task it read the work, marked it **failed**, and sent it back — the developer's notes and the QA verdict sit side by side on the record, with the Auditor watching the whole exchange. Real review, not a rubber stamp; the gate only opens when the work is right.*
|
||||
|
||||
|
||||
|
||||
*Every agent keeps a journal — reflections, decisions, and lessons. Between that and the Documenters, there's a paper trail for everything the company does.*
|
||||
|
||||
## 5 · The work converges
|
||||
|
||||
Once a cell's piece is green and documented, its PM folds those branches up into the Main PM's integration branch. Three independent streams of work come back together into one. Each task brings its branch, pull request, commits, and docs along with it:
|
||||
|
||||
|
||||
|
||||
*One finished unit — branch, pull request, commits, and docs all attached. This is the thing that travels up the merge chain.*
|
||||
|
||||
|
||||
|
||||
*Three streams becoming one history. Each cell's work lands as its own **verified** commit, co-authored by the agent that wrote it — the UX/UI design, the backend endpoint, the frontend page — folded together into the single pull request that comes back to you.*
|
||||
|
||||
---
|
||||
|
||||
Previous: **[← It starts with you](02-it-starts-with-you.md)** · Next: **[The last call — and the loop →](04-the-last-call-and-the-loop.md)**
|
||||
@@ -0,0 +1,41 @@
|
||||
# The last call — and the loop
|
||||
|
||||
## 6 · The last call is yours
|
||||
|
||||
The cells' work is folded up, the Main PM opens the **final pull request** into `master`, and the company goes quiet. The decision comes back to exactly where it started — with you. You're the only one who ever touches `master`, and anything waiting on you sits in the **CEO Approval Queue** until you act.
|
||||
|
||||
|
||||
|
||||
*The hand-off back to you. The integrated PR is open, every cell has delivered, QA is green — and it waits. Nothing reaches `master` without your word.*
|
||||
|
||||
|
||||
|
||||
*And it is a real pull request, on the real repository — not a simulation. The company's work shows up exactly where any engineer would look for it.*
|
||||
|
||||
|
||||
|
||||
*Open it and the whole brief is there — the objective, what was built, the board-led split across the three cells, and the company's own notes — written by RoboCo, for you to read before you decide.*
|
||||
|
||||
|
||||
|
||||
*The real diff, laid out for you to inspect — the migrations, the endpoints, the panel components. This is the substance you are signing off on.*
|
||||
|
||||
|
||||
|
||||
*Your two words. **Approve & Merge** and it ships to `master`; **Request Changes** and it goes around for another lap. The last call has the same shape as the first — one decision, yours alone.*
|
||||
|
||||
---
|
||||
|
||||
## And round it goes
|
||||
|
||||
You handed the company a task; it scoped it, built it, failed and re-ran its own QA, documented it, and brought it back as a single pull request for your sign-off. That's one complete pass.
|
||||
|
||||
|
||||
|
||||
*The whole tree in its final state — the parent waiting on your approval, every cell's task done beneath it. One feature, start to finish, with you at only the two ends.*
|
||||
|
||||
And the feature in these screenshots is the proof. The **Prompter** wasn't built for a demo — it's a real page RoboCo's agents shipped to RoboCo's own control panel. A company building its own product, in front of you, is the whole point of RoboCo. What makes that hold together isn't a clever model or a lucky run; it's the **organization** — the roles, the gated lifecycle, the reviews and the sign-offs that keep twenty-two agents moving as a company instead of a crowd. Run as many of these passes as you like, across as many projects as you like.
|
||||
|
||||
---
|
||||
|
||||
Previous: **[← The cells build it](03-the-cells-build-it.md)** · Next: **[The business workflow →](05-the-business-workflow.md)**
|
||||
@@ -0,0 +1,47 @@
|
||||
# The business workflow
|
||||
|
||||
The first four chapters follow one task through the company. But a company isn't only its task queue — it has a direction, a budget, and a reason every task exists. That layer lives in the **Business** tab, and it is how you steer the whole organization rather than one job at a time.
|
||||
|
||||
## The charter
|
||||
|
||||
The charter is the company's standing context: its **north star**, its **objectives**, the **constraints** it must respect, and the **operating policy** it works under. You write it once in the Business tab and revise it whenever the direction shifts. It isn't decoration — the charter is threaded into every agent's briefing, into the pitches the Board produces, and into what the Secretary is allowed to act on. Set it well and every agent inherits the same sense of what the company is for; leave it empty and they only know the task in front of them.
|
||||
|
||||
<!-- Screenshot to capture: the Business tab charter editor with the north-star / objectives / constraints / operating-policy fields filled in. -->
|
||||
|
||||
## The Cockpit
|
||||
|
||||
Where the charter says what the company *should* be doing, the Cockpit shows what it *is* doing — the company reflected back against its own charter. It surfaces spend against budget and the signals worth your attention: drift from the stated objectives, agents sitting idle, work that has been blocked too long. It is the one screen that answers "is the company on course?" without your having to read every task.
|
||||
|
||||
<!-- Screenshot to capture: the Cockpit with spend-vs-budget and the signals panel. -->
|
||||
|
||||
## The Secretary
|
||||
|
||||
The Secretary is your conversational chief-of-staff. You chat with it the way you'd brief a human one — ask it where things stand, or dictate a change to the charter. What it never does is act on its own: every directive it derives from your instruction is **gated**, landing in a queue for your explicit confirmation before anything happens. It reads the whole company's state to advise you, but it spends nothing, builds nothing, and approves nothing until you say the word. It is leverage with a safety catch — your intent, executed, but only after you confirm it.
|
||||
|
||||
<!-- Screenshot to capture: a Secretary chat dictating a charter tweak, and the resulting gated directive awaiting confirmation in the queue. -->
|
||||
|
||||
## Web research and the strategy engine
|
||||
|
||||
Two capabilities run above the day-to-day. Neither has a button in the panel — both are **configuration toggles**, off by default, and their effect shows up inside agent runs once enabled.
|
||||
|
||||
### Web research
|
||||
|
||||
Set `ROBOCO_RESEARCH_ENABLED=true`, choose a provider with `ROBOCO_RESEARCH_PROVIDER` (`tavily`, `brave`, or `exa`), and supply `ROBOCO_RESEARCH_API_KEY`. With that in place, the Board and PM agents gain `web_search` and `web_fetch` through the `roboco-search` MCP server — so a Product Owner scoping a feature can ground it in the live web, not just your codebase. The API key stays server-side; the agents never see it and never make the external call themselves. Leave it off and the tools simply aren't there — a no-op.
|
||||
|
||||
### The strategy engine
|
||||
|
||||
Set `ROBOCO_STRATEGY_ENGINE_ENABLED=true` and a background loop begins watching the company against its charter. When it spots drift from the objectives, agents gone idle, or work blocked for too long, it tells you. It is **notify-only by design**: it never spends, never builds, never approves — it raises the flag and leaves the decision where every decision belongs, with you. Off, it is fully dormant.
|
||||
|
||||
## Feel the whole thing
|
||||
|
||||
The cleanest way to understand this layer is to walk it once, end to end:
|
||||
|
||||
1. Open the **Business** tab and set the charter — north star, a couple of objectives, your constraints, the operating policy.
|
||||
2. Open the **Cockpit** and watch the company reflected against it — spend against budget, and the signals as they appear.
|
||||
3. Chat the **Secretary** and dictate one change to the charter. Watch the gated directive land in the queue, and confirm it — that round trip, from your sentence to a confirmed action, is the whole shape of how you steer RoboCo from above.
|
||||
|
||||
---
|
||||
|
||||
Previous: **[← The last call — and the loop](04-the-last-call-and-the-loop.md)** · Back to **[the index](README.md)**
|
||||
|
||||
*RoboCo is early-stage, work-in-progress software (v0) — expect rough edges. The [README](../../README.md) covers setup, architecture, and the security model.*
|
||||
@@ -0,0 +1,31 @@
|
||||
# How RoboCo works
|
||||
|
||||
|
||||
|
||||
RoboCo is a virtual software company — 22 AI agents and one human: you. Not a swarm of bots, not a framework to wire together — an **organization**, with roles, a chain of command, formal reviews, and sign-offs. You don't micromanage it; you run it like a CEO. Drop work in at the top and the company carries it all the way through planning, building, review, and documentation, then brings it back to your desk for the final word. You act at the two ends; the organization fills in everything between.
|
||||
|
||||
And the proof is this guide. The screenshots throughout aren't a mock-up: they follow RoboCo building one of its *own* features — the **Prompter**, the task-authoring page now living in this very control panel. RoboCo's agents scoped it, built it across three cells, failed and re-ran its QA, documented it, and opened the real pull request you'll see at the end. RoboCo builds RoboCo — that is the whole proof of concept.
|
||||
|
||||
> The panel is your one window into the company. Every task, agent, message, journal, and pull request is live in front of you.
|
||||
|
||||
**Prefer video?** A [full screen-recording of the panel](../videos/panel-full-walkthrough.mp4) walks through every page and detail end-to-end — useful as a first tour before diving into the screenshots.
|
||||
|
||||
|
||||
|
||||
*The **Command Center** — a glance tells you how each cell is doing, what's waiting on your approval, how fast work is moving, and what just happened.*
|
||||
|
||||
---
|
||||
|
||||
## Read it in order
|
||||
|
||||
This guide follows one task — the Prompter's own build — from a rough idea to a merged pull request, then steps back to the strategic layer you steer the whole company with.
|
||||
|
||||
1. **[The shape of the company](01-the-company.md)** — the org, and how every piece of work is a task that nests into a tree.
|
||||
2. **[It starts with you](02-it-starts-with-you.md)** — drafting a task with the assistant, the Board review, and your first green light.
|
||||
3. **[The cells build it](03-the-cells-build-it.md)** — the three cells, the Dev Kanban, real QA, journals, and the integration branch.
|
||||
4. **[The last call — and the loop](04-the-last-call-and-the-loop.md)** — the final pull request, the CEO Approval Queue, the merge, and round it goes.
|
||||
5. **[The business workflow](05-the-business-workflow.md)** — the charter, the Cockpit, the Secretary, and the research and strategy engines that run above the day-to-day.
|
||||
|
||||
---
|
||||
|
||||
*RoboCo is early-stage, work-in-progress software (v0) — expect rough edges. The [README](../../README.md) covers setup, architecture, and the security model.*
|
||||
Reference in New Issue
Block a user