Prompt to workspace. Proof before trust.
Ship React UI into your workspace, with proof and review.
OneClickUI.ai is the front door for OpenUI MCP Studio: an MCP-native UI/UX delivery and review workflow that plans the change, writes real files, and now carries a plugin-grade starter/config/proof package for Codex, Claude Code, and OpenClaw-side packaging work. It still stays narrower and more honest than a generic coding-agent shell.
Why this lands faster for Codex and Claude Code teams
The front door stays intentionally narrow: generated UI should end in inspectable repo state and a real starter/config/proof package, not only model output.
Choose the route that matches how you are evaluating the product.
The front door should feel like a guide, not a brochure. Most newcomers should take the walkthrough first, confirm trust in the proof desk second, and only then drop into the operator desk.
Take the walkthrough when you want the shortest newcomer path through the product story.
Go to /walkthrough if you want the recommended order from storefront to proof, docs, and the operator desk without deciding the route yourself.
Open the evidence desk when trust is your first question.
Go to /proof if you want the shortest route through prompt, changed files, review bundle, acceptance, and operator meaning before you touch the interactive desk.
Open the operator desk when you already think in packets, reviews, and next moves.
Go to /workbench if you want the repo-owned decision surface that separates what the repo proves, what still needs a human call, and what should happen next.
Open the compare surface when you need the sharpest honest split.
Go to /compare if you are sorting OpenUI against hosted builders and broader coding-agent traffic without pretending they all optimize for the same job.
Prompt, output, changed files, review bundle, proof.
The front door should let a stranger understand the workflow in one screen. These are the five beats that make the product feel more trustworthy than a screenshot-only generator.
Pick the route that matches the question in your head.
The front door should feel like a good operator: it helps you ask the right question first, then sends you to the surface that can actually answer it.
I need the 90-second product verdict.
Start here when you want to judge whether this repo is a real prompt-to-workspace UI workflow instead of a generic builder claim.
Pairs the homepage promise with the shortest guided path before you touch the longer README shelf.
I need proof, boundaries, and review language.
Go here when the real question is what changed, what was proved, and which tail still belongs to a human reviewer or operator.
Keeps proof, review bundle, acceptance, and operator-only surfaces in one bounded place.
I need the docs shelf without getting lost.
Use the docs hub when you already trust the shape and now want the README storefront, evaluator checklist, ecosystem ledger, and public bundle routes.
Turns the docs layer into a curated route map instead of a long blob of links.
Start from a brief, not a screenshot wish.
The front door shows the same story the repo actually supports: a UI brief goes into a real workspace-aware delivery flow.
Build a pricing surface with a stronger hero, trust row, feature comparison, and review-ready acceptance notes.Generate React + shadcn output that is meant to be applied.
This is not positioned as a pure hosted builder. The real promise is generated UI that can be shaped for the repo you already own.
apps/web/app/pricing/page.tsx
apps/web/components/generated/PricingCards.tsx
apps/web/components/generated/FeatureComparison.tsxKeep changed files visible before trust goes up.
A reviewer can see which paths changed and where shared components or layout impact starts to matter.
workspace-profile.json
change-plan.json
feature-flow-plan.jsonEnd with review bundle, acceptance, and proof.
The strongest difference from a plain generator is that proof, review, and acceptance stay in the loop instead of being post-hoc guesswork.
feature-flow-review-bundle.md
feature-flow-acceptance-result.json
smoke:e2e / visual:qa / repo:doctorBuilt first for technical evaluators and React + shadcn teams.
This front door should tell different kinds of technical visitors where to go next without making them read the whole warehouse.
Technical evaluators and React + shadcn frontend teams
These users care whether a workflow writes into the repo, exposes reviewable artifacts, and can survive smoke and proof gates.
MCP builders and teams looking beyond Bolt / Lovable / v0 demos
They are likely to care about workspace reality, review surfaces, and a more inspectable path than a hosted generation-only story.
Not the best fit for generic 'just make me an app' traffic
The current product is not a no-code builder, not a generic coding agent, and not a one-click hosted SaaS shell.
Comparing against Bolt, Lovable, and v0 without pretending to be the same thing.
If you mainly want a hosted builder, their official products may fit better. If you want workspace-integrated UI shipping with review and proof, this is where OpenUI is narrower and more honest.
Chat-to-app builder for websites, apps, and prototypes.
better when the team needs workspace-integrated proof, review, and repo-aware delivery surfaces
AI app builder focused on fast app and website creation.
better when the team values review bundle, acceptance thinking, and MCP-native workflow semantics
AI build surface for agents, apps, and websites.
better when the team wants prompt-to-workspace delivery with proof and feature-level package structure
The current builder-facing order is fixed: local stdio MCP first, compatibility bridge second, repo-local workflow readiness third, with plugin-grade package surfaces layered on top.
Builder-facing traffic should be able to answer how to plug in, inspect the compatibility bridge, read the readiness packet, and adapt a starter bundle without mistaking any of them for publication or a hosted-platform promise.
Connect from Codex or Claude Code with the starter bundle
The current integration story starts with the stdio MCP server plus the repo-owned starter bundles, not a hosted API claim. Use the MCP client setup path when you want real prompt-to-workspace delivery.
Audience: builder teams already operating through MCP-aware coding clients
Best for: the shortest honest path from prompt to workspace writes, proof desks, and reviewable React delivery
Read when: Open this when your first question is how to add OpenUI to Codex or Claude Code through the current MCP-native runtime path.
Not for: a hosted builder setup story or a generic agent marketplace pitch
Inspect the compatibility API contract
Use the OpenAPI compatibility document when you need a read-only HTTP projection of the MCP tool surface for review, contract checks, or bridge consumers.
Audience: bridge consumers, reviewers, and contract-minded integrators
Best for: read-only HTTP projection, compatibility review, and consumer-side contract checks
Read when: Open this after the MCP path is clear and the next question becomes adapter shape, compatibility review, or breaking-change inspection.
Not for: treating the compatibility bridge like a canonical hosted API or SDK promise
Prove the package before you widen the claim
Use the raw repo workflow summary, starter proof loop, and the maintainer-ready packet when you need proof of local plus GitHub readiness through repo-local CLI surfaces, without pretending the repo can mutate remote state by itself.
Audience: maintainers and evaluators reading repo-local readiness signals
Best for: workflow packets, proof loops, and troubleshooting that explain repo-local plus GitHub-connected readiness without mutating remote state
Read when: Open this after execution is already clear and you need a read-only maintainer/operator view of readiness, proof, and handoff state.
Not for: pretending the repo can push, approve, or land release traffic by itself
Machine-readable discovery and SEO guardrails
The discovery chain should work for both humans and machines without turning the public surface into a maze.
LLM and agent summary
The shortest English-first front-door summary for Codex, Claude Code, MCP clients, and AI search or index consumers.
Audience: LLM clients, search/index systems, and builders needing the shortest truth layer
Best for: the English-first snapshot of route roles, builder order, and current boundaries
Read when: Open this when an agent or search/index system needs the shortest product and route summary before reading deeper docs.
Not for: interactive proof, operator work, or long-form command semantics
Builder JSON snapshot
Machine-readable routes, bindings, AI capability lanes, i18n posture, and honest product boundaries for builder-facing consumers.
Audience: builder tooling, agents, and contract-aware integrators
Best for: routes, bindings, audience fit, i18n posture, and boundary metadata in one machine-readable payload
Read when: Open this after the product sentence is clear and you need a structured discovery contract for tooling or integration work.
Not for: inventing a new runtime or claiming the repo already exposes a hosted builder control plane
Web manifest
Install and discovery metadata that helps browsers and evaluators understand the public front door without scraping the whole repo.
Audience: browsers, install surfaces, and crawler-adjacent discovery consumers
Best for: front-door route shortcuts and install/discovery metadata that point to the same honest product roles
Read when: Open this when you need browser-facing install metadata and route shortcuts, not the full builder or proof explanation.
Not for: turning the app into a deployed canonical hosted truth or replacing the proof desk
Sitemap
Canonical crawl map for the human-facing front-door routes when NEXT_PUBLIC_SITE_URL is configured.
Audience: crawlers and maintainers checking canonical route exposure
Best for: the canonical crawl map for the public front-door routes when NEXT_PUBLIC_SITE_URL is configured
Read when: Open this when you need the crawl map and canonical route exposure, not the longer product narrative.
Not for: expressing product boundaries in detail or replacing route-role metadata
Robots policy
Crawl policy that stays aligned with sitemap exposure and NEXT_PUBLIC_SITE_URL-driven indexability.
Audience: crawlers and maintainers checking whether indexing should be enabled
Best for: the explicit crawl policy that pairs with sitemap exposure and canonical site gating
Read when: Open this when you need to confirm whether the front door is currently indexable, not when you need the longer product narrative.
Not for: explaining route roles, builder order, or replacing the proof and docs surfaces
Public pages stay English-first, with en-US metadata and one canonical language path instead of scattered mixed-language literals.
When the app is running, `/llms.txt`, `/api/frontdoor`, `/manifest.webmanifest`, `/sitemap.xml`, and `/robots.txt` should be read as one discovery chain instead of isolated routes.
Homepage, Social Preview, published release assets, and Discussions seeding still remain operator-managed public surfaces.
The repo still refuses fake hosted, write-anywhere API, or generic assistant claims. That honesty is part of the discoverability story, not a weakness.
What makes the front door feel sharper
These are the practical reasons this product reads like a tool, not like a vague builder promise.
Workspace integration first
The product is most honest when it talks about writing into a real workspace, not about replacing your entire engineering stack.
Proof before trust
Smoke, review, acceptance, and proof language stay visible so the homepage matches the product's actual operating model.
MCP-native workflow
This is built around an MCP server and repo-integrated delivery path, which makes it more relevant for builders and evaluators than a pure chat demo.
Feature-level delivery is getting thicker
Feature flow now keeps route-level artifacts and a feature-level review package, which is a more honest story than 'one-click page magic'.
Builder-ready compatibility layer
The repo already exposes a primary MCP tool surface, a compatibility OpenAPI bridge, and a repo-local workflow CLI for builder-facing review, without pretending that a hosted platform or write-anywhere API already exists.
Built for MCP, Codex, and Claude Code first. Compared to broader coding-agent traffic second.
This is where the AI heat has to stay honest. The product earns the MCP, Codex, and Claude Code language because the repo already ships a local stdio MCP tool surface and a plugin-grade package bundle around it. OpenClaw is now public-ready at the repo-owned artifact layer, but not a front-door category claim.
MCP
MCP is not decorative wording here. The repository ships a local stdio MCP server and keeps that protocol as the real tool surface.
Codex
Codex is a natural client fit when the goal is prompt-to-workspace React UI delivery with proof, review, and acceptance kept visible.
Claude Code
Claude Code fits the same stdio MCP path for teams that want model-assisted UI shipping without flattening the workflow into a generic assistant story.
OpenHands
Submitted through OpenHands PR #161, but the current GitHub state is still OPEN / REVIEW_REQUIRED / BLOCKED, so it remains comparison context rather than an accepted install shelf.
OpenCode
Relevant as open coding-agent ecosystem traffic, but not the primary category claim for this repository.
OpenClaw
OpenClaw is still not the front-door category claim, but the repo now ships a listed-live ClawHub-backed starter bundle whose current moderation label still reads suspicious.llm_suspicious.
The useful AI story here is workflow copilot, risk explanation, and next-step guidance.
Keep the AI story scoped to the lanes the repo can actually own today.
Workflow copilot
AI helps scan the workspace, plan the change, and keep the route-level blast radius legible before trust goes up.
Risk and approval explainer
Acceptance packs and review bundles summarize what passed automatically, what still needs a human, and why the workflow is refusing fake certainty.
Operator next-step assistant
Repo workflow summary and readiness packets turn local plus GitHub state into the next recommended action instead of leaving maintainers to infer it from raw CLI noise.
Pick the path that matches how deep you want to go.
The front door should not force one journey. It should route a newcomer to the right depth quickly.
What the front door will not pretend
Progressive disclosure only works when the front door stays honest about what it is not.