Back to Details

genui

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Genui — sketch UIs in conversation

Genui — 以对话方式绘制UI

Generate 
.openui
files in 
docs/prototype/
for the developer to render live in the Genui VS Code extension. Throwaway by design — the answer to "what should this look like" is what matters, not the sketch.
For how to author OpenUI Lang syntax, read the bundled openui-lang reference (positional-arg rules, component signatures, validator script). This skill is about when/where/why — not syntax.
在
docs/prototype/
目录中生成
.openui
文件，供开发者在Genui VS Code扩展中实时渲染。设计为一次性使用——重要的是“这个应该是什么样子”的答案，而非草图本身。
关于如何编写OpenUI Lang语法，请阅读附带的openui-lang参考文档（位置参数规则、组件签名、验证脚本）。本技能关注的是何时/何地/为何使用——而非语法细节。

When to invoke

何时调用

Trigger phrases (from the user, in conversation):
  • "sketch a [page / screen / layout]"
  • "mock up a [thing]"
  • "let me see a few options for X"
  • "draft a UI for X"
  • "genui this"
  • "prototype this design"
  • "what should this look like"
Do not invoke for: state-machine sanity checks, business-logic exploration, terminal apps.
对话中用户的触发短语：
  • "sketch a [page / screen / layout]"（绘制一个[页面/界面/布局]）
  • "mock up a [thing]"（制作一个[事物]的原型）
  • "let me see a few options for X"（让我看看X的几种选项）
  • "draft a UI for X"（为X草拟一个UI）
  • "genui this"
  • "prototype this design"（为这个设计制作原型）
  • "what should this look like"（这个应该是什么样子）
请勿调用的场景：状态机合理性检查、业务逻辑探索、终端应用。

The 6-step workflow

六步工作流程

1. State the question — one line

1. 陈述问题——一行内容

What design is being prototyped? Write it as the first comment in the 
.openui
file:
openui
undefined
正在制作原型的是什么设计？将其作为
.openui
文件的第一行注释：
openui
undefined

PROTOTYPE — A settings page with notification toggles, plan selector, and account deletion

PROTOTYPE — A settings page with notification toggles, plan selector, and account deletion

Generated: 2026-05-16

Generated: 2026-05-16

Status: open

Status: open


These `#`-prefixed lines are comments and stripped by the parser. They survive the file so a casual reader knows what's being explored and why.

If the question isn't crisp, ask. A vague question produces a vague sketch.

这些以`#`开头的行是注释，会被解析器移除。它们保留在文件中是为了让普通读者了解正在探索的内容及其原因。

如果问题不清晰，请询问用户。模糊的问题会产生模糊的草图。

2. Decide: single design or variants?

2. 决定：单一设计还是变体？

Default: single design. Generate one file.
Variants (2-3, max 3): only when the user explicitly wants to compare. Triggers: "show me a few options", "different layouts", "I want to choose between approaches".
When generating variants, hold them to: structurally different, not colour tweaks. Different layouts, different information hierarchy, different primary affordance. Three slightly-tweaked card grids isn't a variant set, it's wallpaper. If two drafts come out similar, redo one with a "do not reuse this pattern" constraint.
默认：单一设计。生成一个文件。
变体（2-3个，最多3个）：仅当用户明确想要对比时使用。触发词：“show me a few options”（给我看几个选项）、“different layouts”（不同布局）、“I want to choose between approaches”（我想在几种方案中选择）。
生成变体时，要确保它们结构上完全不同，而非仅仅调整颜色。不同的布局、不同的信息层级、不同的主要交互方式。三个略有调整的卡片网格不是变体集，只是重复内容。如果两个草稿相似，请重新制作其中一个，并遵循“不要重复此模式”的约束。

3. Pick location and filename

3. 选择位置和文件名

Folder: 
docs/prototype/
at the workspace root. Create if missing.
Filenames (kebab-case slug):
  • Single: 
    docs/prototype/<slug>.openui
    — e.g. 
    settings-page.openui
  • Variants: 
    docs/prototype/<slug>-a.openui
    , 
    -b.openui
    , 
    -c.openui
If re-prototyping the same area in a new session, version it: 
settings-page-v2.openui
. Don't overwrite previous prototypes silently.
文件夹：工作区根目录下的
docs/prototype/
。如果不存在则创建。
文件名（短横线分隔的小写格式）：
  • 单一设计：
    docs/prototype/<slug>.openui
    ——例如
    settings-page.openui
  • 变体：
    docs/prototype/<slug>-a.openui
    、
    -b.openui
    、
    -c.openui
如果在新会话中重新制作同一区域的原型，请添加版本号：
settings-page-v2.openui
。不要静默覆盖之前的原型。

4. Generate

4. 生成文件

Use the 
openui-lang
REFERENCE.md for correct component signatures. Validate before handing off:
bash
node .claude/skills/genui/openui-lang/scripts/validate.mjs docs/prototype/<slug>.openui
The validator catches parse-level errors only. Component prop-schema errors only surface in the renderer (red error banner in the Genui preview). Treat that banner as ground truth.
使用
openui-lang
的REFERENCE.md确保组件签名正确。交付前验证：
bash
node .claude/skills/genui/openui-lang/scripts/validate.mjs docs/prototype/<slug>.openui
验证器仅捕获解析层面的错误。组件属性 schema 错误仅会在渲染器中显示（Genui预览中的红色错误横幅）。将该横幅视为真实错误依据。

5. Hand off to the developer

5. 交付给开发者

Tell the user, in one sentence:
"Created 
docs/prototype/settings-page.openui
. Open it from the Explorer and run Genui: Open Preview (
Cmd+Shift+P
→ Genui)."
For variants: list all paths and suggest opening them side-by-side. The Genui extension keys panels by URI, so each file gets its own preview tab.
If the preview shows a red error banner, paste the error text — the user reports it back and you fix the 
.openui
file. The watcher re-renders on save automatically; the developer doesn't need to reload.
用一句话告知用户：
"已创建
docs/prototype/settings-page.openui
。从资源管理器中打开它，运行Genui: Open Preview（
Cmd+Shift+P
→ Genui）。"
如果是变体：列出所有路径并建议并排打开。Genui扩展会根据URI区分面板，因此每个文件都会有自己的预览标签页。
如果预览显示红色错误横幅，请粘贴错误文本——用户反馈后你需要修复
.openui
文件。监视器会在保存时自动重新渲染，开发者无需重新加载。

6. Capture the answer and clean up

6. 记录结果并清理

A prototype that lingers is a prototype that lies. Pick exactly one outcome:
A — Answer absorbed into real code. The design choice gets implemented as a real component / page / flow. Delete the 
.openui
file. The commit message references the prototype: "feat: settings page (from 
docs/prototype/settings-page.openui
)".
B — Exploration closed, nothing changed. Delete the 
.openui
file. No record needed.
C — Exploration produced learning worth keeping. Write a short 
docs/prototype/NOTES.md
(5-15 lines):
markdown
undefined
留存的原型会产生误导。选择以下其中一种结果：
A — 结果融入实际代码。设计选择被实现为真实的组件/页面/流程。删除
.openui
文件。提交信息中引用该原型："feat: settings page (from 
docs/prototype/settings-page.openui
)"。
B — 探索结束，无任何变更。删除
.openui
文件。无需记录。
C — 探索产生了值得保留的经验。编写简短的
docs/prototype/NOTES.md
（5-15行）：
markdown
undefined

settings-page (2026-05-16)

settings-page (2026-05-16)

Question: Three layouts for the settings page. Outcome: Variant B (sidebar nav) won. Picked because the deeper integration list needs vertical real estate. ADR-0017 covers the decision. Files were: settings-page-{a,b,c}.openui — all deleted post-decision.

Then delete the `.openui` files. The learning is the artifact, not the sketch.
问题： 设置页面的三种布局。 结果： 变体B（侧边栏导航）胜出。选择它的原因是深度集成列表需要垂直空间。ADR-0017记录了该决策。 相关文件： settings-page-{a,b,c}.openui —— 决策后已全部删除。

然后删除`.openui`文件。值得保留的是经验，而非草图。

File-header convention

文件头约定

Every 
.openui
generated by this skill starts with:
openui
undefined
本技能生成的每个
.openui
文件都以以下内容开头：
openui
undefined

PROTOTYPE — <one-line question>

PROTOTYPE — <one-line question>

Generated: <YYYY-MM-DD>

Generated: <YYYY-MM-DD>

Status: open | answered | abandoned

Status: open | answered | abandoned


Status changes through the prototype's life:

- **open** — fresh sketch, no decision yet
- **answered** — design choice made, ready to delete and absorb
- **abandoned** — exploration didn't produce anything, delete without absorbing

状态会随着原型的生命周期变化：

- **open**——新草图，尚未做出决策
- **answered**——已做出设计选择，可删除并融入实际代码
- **abandoned**——探索未产生任何成果，直接删除

Anti-patterns

反模式

  • Don't put 
    .openui
    files in 
    src/
    , 
    app/
    , or the source tree.     Sketches aren't code. 
    docs/prototype/
    is where they belong.
  • Don't generate 5+ variants. 2-3 is the sweet spot. Beyond that, variants stop being radically different.
  • Don't make colour-only variants. "Same layout, different palette" is a tweak, not a prototype.
  • Don't leave prototype files lingering across sessions. If the design was answered, delete. If not, status it as 
    abandoned
    or 
    open
    and revisit explicitly.
  • Don't reuse a slug silently. Re-prototyping the same area? Version it (
    -v2
    ). Old prototypes stay readable in git history.
  • Don't promote the 
    .openui
    directly to production.     The renderer is a preview tool. To ship the design, write the real React (or other framework) component the prototype suggested.
  • 不要将
    .openui
    文件放在
    src/
    、
    app/
    或源码目录中    。草图不是代码。它们属于
    docs/prototype/
    目录。
  • 不要生成5个以上的变体。2-3个是最佳数量。超过这个数量，变体就不再是完全不同的方案。
  • 不要制作仅调整颜色的变体。“布局相同，调色板不同”是微调，不是原型。
  • 不要让原型文件跨会话留存。如果设计已确定，删除文件。如果未确定，将状态标记为
    abandoned
    或
    open
    并明确重新审视。
  • 不要静默重用短横线格式的文件名。重新制作同一区域的原型？添加版本号（
    -v2
    ）。旧原型会在git历史中保持可读。
  • 不要直接将
    .openui
    文件用于生产环境    。渲染器是预览工具。要交付设计，请编写原型所建议的真实React（或其他框架）组件。

What this skill is NOT

本技能不是什么

  • Not the syntax reference — that's the bundled openui-lang.
  • Not a code generator that turns a prototype into React. The developer or another agent does that translation.
  • Not a UI library — 
    @openuidev/react-ui
    is. We just render their components from text.
  • Not for production UI. Always throwaway.
  • 不是语法参考文档——那是附带的openui-lang。
  • 不是将原型转换为React的代码生成器。这项转换工作由开发者或其他代理完成。
  • 不是UI库——
    @openuidev/react-ui
    才是。我们只是通过文本渲染它们的组件。
  • 不是用于生产UI的工具。始终是一次性使用。

See also

另请参阅

  • openui-lang — how to write 
    .openui
    files correctly. Required reading before this skill generates any code.
  • The Genui VS Code extension — open any 
    .openui
    file, run "Genui: Open Preview" to render. Live re-renders on save. Its 
    examples/
    folder has 9 worked fixtures (landing, dashboard, form, settings, onboarding, callouts, accordion FAQ, conditional rendering, hello) to crib from.
  • openui-lang——如何正确编写
    .openui
    文件。在本技能生成任何代码之前，必须阅读此文档。
  • Genui VS Code扩展——打开任何
    .openui
    文件，运行“Genui: Open Preview”进行渲染。保存时自动实时重新渲染。其
    examples/
    文件夹中有9个已完成的示例（登录页、仪表盘、表单、设置页、引导页、提示框、手风琴式FAQ、条件渲染、hello）可供参考。