Skill idea: generate Storybook-organized components from an OD artifact — does this fit?

[abhid-007]

Hi — wanted to gauge interest and fit before writing any code, per CONTRIBUTING.md.

The gap I keep hitting

OD is great at producing a rendered artifact (HTML prototype, page, deck). What I keep wanting on top of that, for real frontend work, is the next step: turning that artifact into a set of actual UI components organized as Storybook stories — componentized source files plus *.stories.tsx with args/controls bound to the active design system's tokens. Today that step is manual.

Proposed shape — a functional skill

Based on specs/current/skills-and-design-templates.md, this reads as a functional skill (od.mode: utility) rather than a design template: its job is to do work on user input (an existing artifact or a prompt), not render an artifact itself.

Rough sketch of what skills/storybook-components/ would do:

1. Take an OD artifact (or a fresh prompt) plus the active design system.
2. Drive the agent to detect component boundaries, infer props from variants, and map design-system tokens to story args.
3. Emit a small tree of component files + CSF 3 stories + a minimal .storybook/ scaffold if one isn't present.
4. Validate by compiling the generated stories and headlessly mounting them, retrying on failure so the output is something a developer can actually pnpm storybook against — not just text that looks right.

The interesting (and risky) part is step 4 — the validation loop is what separates "looks plausible" from "works". Without it the skill would be a toy.

v0 scope I'd propose

To keep it shippable as "one folder, ~2 files plus the validation harness":

• React + CSF 3 only. Vue/Svelte/styled-components can come later.
• Consumes one active design system from design-systems/ — does not invent tokens.
• One sample artifact + one design system as the eval case; the PR shows the generated Storybook running.

Questions before I start

1. Does a storybook-components skill fit OD's direction, or is "componentize an artifact" intentionally out of scope?
2. Is od.mode: utility the right classification, or should it be something new?
3. Any prior art / abandoned attempts I should read before reinventing?
4. Is the validation harness (spawning a Storybook build to verify generated output) acceptable inside a skill, or does that belong in the daemon?

Happy to iterate on the shape based on feedback before writing anything. Thanks for building OD — the skills surface is a really clean place to extend from.

---

以下中文版本由 AI 根据上方英文原文翻译生成,如有表述不当之处欢迎指正。

中文 (简体)

你好 — 在动手写代码之前,想先按照 CONTRIBUTING.md 的建议,征询一下大家对这个想法的兴趣与契合度。

我反复遇到的缺口

OD 在生成渲染产物方面表现很好(HTML 原型、页面、Deck)。但在真实的前端开发中,我反复想要的是它的下一步:把这些产物转化为一组真正以 Storybook 方式组织的 UI 组件 — 也就是组件化的源码文件,加上 *.stories.tsx,其 args/controls 绑定到当前设计系统的 token。目前这一步只能手工完成。

形态设想 — 一个功能型 skill

参照 specs/current/skills-and-design-templates.md,这更像是一个功能型 skill(od.mode: utility),而非 design template:它的职责是对用户输入做处理(已有产物或一段 prompt),而不是去渲染一个产物。

skills/storybook-components/ 大致会做这些事:

1. 接收一个 OD 产物(或一段新的 prompt),以及当前的设计系统。
2. 驱动 agent 识别组件边界,根据 variants 推断 props,并将设计系统的 token 映射到 story 的 args 上。
3. 产出一棵小型的组件文件树 + CSF 3 stories + 在缺失时附带一个最小的 .storybook/ 脚手架。
4. 通过编译生成的 stories 并在无头环境中挂载来进行校验,失败时重试,以确保产物是开发者真正可以 pnpm storybook 跑起来的东西 — 而不仅仅是"看起来对"的文本。

最关键也最有风险的部分是第 4 步 — 这一校验闭环是"看起来可信"与"真的能用"之间的分水岭。没有它,这个 skill 就只是个玩具。

v0 建议范围

为了让它符合"一个文件夹、约 2 个文件,再加上校验脚手架"的尺寸:

• 仅支持 React + CSF 3。Vue/Svelte/styled-components 可以后续再加。
• 仅消费 design-systems/ 下当前激活的一套设计系统 — 不自行编造 token。
• 选一个示例产物 + 一套设计系统作为 eval 用例;PR 中展示生成出的 Storybook 真正运行起来的效果。

在开始之前的几个问题

1. storybook-components 这个 skill 是否契合 OD 的方向?或者"把产物组件化"是有意排除在外的?
2. od.mode: utility 是合适的分类吗,还是应该新增一种?
3. 是否有相关的前期尝试或已搁置的方案,我开工前应当先读一读以免重复造轮子?
4. 把校验脚手架(启动一次 Storybook 构建来验证生成结果)放在 skill 内部是否可接受,还是更适合放在 daemon 里?

很乐意根据反馈先把形态打磨好再动手。感谢各位把 OD 做出来 — skills 这层是一个非常清爽的扩展面。