Documentation
Everything Orgabot does, written down: how to install it, how the mission terminal works, what a capability pack actually is, how governance and approvals gate real work, and where the product is headed next. Search below, or browse by section.
Start here
A local-first control plane for an organization of AI and human workers. One instruction becomes a governed, verified, delivered mission.
Clone, install the framework, link the skills, authenticate your tools, and run the doctor check, then stand up an organization and map your first project.
The happy path from a registered project to a delivered draft pull request, plus what to do when the mission holds instead of shipping.
The vocabulary (mission, transcript, worktree, task DAG, gate, reviewer, draft PR, audit log, autonomy, approval) and how each shows up in practice.
Update the framework in place, keeping projects, organizations, connectors, credentials, missions, schedules, and audit history, then verify each surface.
Using Orgabot
The localhost ops dashboard is the day-to-day surface for missions, repositories, issues, the inbox, analytics, and budgets, plus its long-running gotchas.
Type or dictate a mission, watch it stream, steer it mid-run, and interrupt it with Escape, all in one interactive session that ends in a clear outcome.
Mission variants, routing and decomposition, the worker that runs them, observation and control commands, and the recovery paths when one dies.
How a change becomes a merged pull request: the independent review loop, PR-state classification, CI and conflict remediation, and the merge path's rules.
The command-line surface, grouped by task: projects, missions, shipping, organizations, roles, connectors, context, budgets, and recovery.
The catchup command and the dashboard's "Since you were gone" panel show what happened while you were away and where to continue, from existing records.
Launch the native shell, map its commands to the CLI, and read its honest limits on session handoff, keyboard controls, and what survives a crash.
The organization
The org chart is the routing layer: organizations, departments, roles, actors, templates, and the rule that an org-owned mission is owned by a role.
A capability pack is the job training you install into a role: knowledge, procedures, and declared tool needs. A pack never grants access by itself.
How a role reaches an outside service: GitHub Apps with short-lived tokens, adopted MCP servers, brokered tool runs, and where a permission gets clamped.
Approval queues and role inboxes, the autonomy envelope a CISO agent triages inside, the tamper-evident ledger, and the security properties behind them.
Live Context, context sources, memorialization before execution, git-backed organization memory, and the output sinks work is delivered through.
USD spend budgets over real accrued cost, quota tracking for subscription executors, the status-bar meter, and the fallback ladder when a pool runs dry.
Watch a Firebase project's App Hosting rollouts and builds so a failed rollout becomes a dashboard incident instead of waiting in the Firebase console.
Connect a repository as a governed skill source, admit its content under an owner approval pinned to a commit, and sync the same skills to every machine.
A department charter is a versioned blueprint plus your overlay: how to preview, propose, review, and roll back a change, and the two changes refused.
How a department publishes a typed service others can request, what a request and a response must carry, and why a service contract grants nothing.
How payments, journals, credits, and expenses are approved and executed, why controls re-run at execution, and why unconfirmed means reconcile, not retry.
Reference
Where the product is: the delivered programs, the ones still in flight, what is honestly not built yet, and what is deliberately off the critical path.
The repository's four independent subprojects, the framework source map, the two seams that must stay swappable, and the commands that gate a change.
The load-bearing safety and correctness properties. Each was written after something broke silently, and no change may weaken any of them.
Real failure modes: holds, wedged missions, stale dashboards, missing worktree dependencies, rate limits, and telling a broken base from a broken change.
How these pages are built and checked, the front-matter contract and markdown subset, and the rule that a system change carries its doc update with it.
A mission executes a workflow rather than being one: stages, gates, environments, and events as inspectable data, with policy deciding what none may omit.
What the first beta does not do yet, stated plainly, so you find out here rather than halfway through a mission.
Choose where each capability runs (local, a cloud provider, or a supported hybrid) and see the resolved answer, its provenance, and the custody boundaries.