Stop babysitting AI coding work. OpenVibeCoding is the command tower for AI engineering. AI coding does not lack models. It lacks a command tower. It helps teams plan / delegate / track / resume / prove long-running work across Codex and Claude Code by turning PM request -> Workflow Case -> Proof & Replay into one governed command-tower loop.
Current boundary: OpenVibeCoding is a repo-backed operator control plane, not a hosted product, and the shipped MCP surface remains read-only.
Official distribution today is the public repo, the Pages front door, one proven workflow baseline, the repo-local read-only MCP server, and local starter or bundle material. The thin client and contract packages are publish-ready but not published yet, while the shared package stays workspace-only, so no public package release, hosted operator, Docker image, or public write-capable MCP is live today.
After those two doors, go deeper through agent starter kits, read-only MCP, integrations, skills, AI + MCP + API surfaces, or the ecosystem map.
The public story should stay simple: one request enters, one Workflow Case becomes visible, and one Proof & Replay surface stays inspectable before you trust the result.
This tracked storyboard is the shareable first-loop asset: it shows the same public path the README, Pages, and release notes are promising.
Public repo, public Pages front door, proof-first docs, one read-only MCP surface, the legacy-branded live PyPI package plus Official MCP Registry entry for that runtime, and the live ClawHub skill are the official distribution core today.
Codex and Claude Code starter kits plus the local bundle examples are still adoption helpers, not automatic first-party listings.
MCP.so still has an open public submission receipt, while the previous OpenHands/extensions submission is closed without a live listing.
Hosted operator service, write-capable MCP, Docker distribution, and standalone npm releases still sit outside the current official promise.
Need the exact shipped/starter/internal/deferred ledger instead of the short version? Open the distribution status.
Write the right worker brief, scope, constraints, and deliverables instead of hoping one giant prompt will keep a long task on track.
Keep the right material in the right head: Workflow Cases, role bindings, queue posture, and handoff context stay explicit instead of rotting inside one session.
Move work through contracts, approvals, runtime bindings, and proof surfaces so the system can keep operating safely instead of gambling on model behavior.
Not today. OpenVibeCoding is the current repo and product surface. Codex now has official plugin surfaces and OpenClaw has official plugin and skills surfaces, but the current public story still ships workflow-aligned integrations, repo-owned skills, read-only MCP, and local bundle examples rather than a published listing.
OpenVibeCoding's current public MCP contract is read-only, and write-capable mutation remains outside the public promise.
OpenClaw stays in the adjacent coding-agent layer. New teams should use the compatibility matrix, integration guide, and repo-owned skills path before implying a shipped native plugin.
Start with the compatibility matrix if the main question is which adoption path fits your stack. Then choose read-only MCP, skills, builders, or the first success path based on the real job.
New here? Keep the first decision simple: start with one proven workflow, choose the right adoption path, then open deeper protocol or builder pages only after the job is clear.
Start here if you want the shortest honest story: one public baseline, one proof pack, and one share-ready Workflow Case recap before you read internals.
Start here if your real question is “I use Codex, Claude Code, OpenClaw, skills, or builders. Which OpenVibeCoding surface should I open first?”
Start here once the boundary is clear and you need read-only MCP, OpenAPI, contract-facing types, or the thin builder surfaces.
Open read-only MCP · Open API quickstart · Open builder quickstart
Need exact starter files? Open agent starter kits. Need the truthful Codex / Claude Code / OpenClaw map? Open integrations. Need repo-owned playbooks? Open skills quickstart. Need the broader market framing? Open the ecosystem map.
Watch governed agents, MCP tools, queue state, and live operator signals from one surface.
Keep the request, queue, verdict, linked runs, and operating context attached to one case record.
Inspect failures, compare reruns, and keep the execution chain auditable before you trust the outcome.
Read-only MCP and the AI operator brief sit on top of this spine as inspection layers, not as second execution truths.
The shortest honest start is still repo-local. The host-compatible path stays:
npm run bootstrap:hostOPENVIBECODING_HOST_COMPAT=1 bash scripts/test_quick.sh --no-relatednpm run devThis local full-stack path boots the orchestrator API on localhost together with the dashboard, so the browser can exercise the operator loop without relying on a browser-side bearer token.
In practice, a clean first pass should take about 5-10 minutes and end with four visible signals: one request created from PM, one case visible in Command Tower, one Workflow Case you can confirm, and one Proof & Replay surface you can inspect before trusting the result.
If the API is already running in another terminal, you can still use npm run dashboard:dev
for dashboard-only iteration on the web shell.
Official first public path: start with news_digest if you want the smallest release-proven
proof loop. Treat topic_brief as a public showcase expansion, and treat
page_brief as a tracked browser-backed proof expansion that still is not the official
first public baseline or equally release-proven with news_digest.
Best for the fastest proof-oriented first run with one topic, a few domains, and a short time window.
Proof state: official public baseline.
Best for a bounded topic brief when you want search-backed evidence without broadening scope.
Proof state: public showcase, not yet equally release-proven.
Best for a single URL with browser-backed evidence and a read-only workflow case wrapper.
Proof state: tracked browser-backed public proof bundle; not the official first public baseline.
See the full proof pack, benchmark summary, and share-ready Workflow Case recap in the first proven workflow guide.