OmX$design技能实战指南用仓库级 DESIGN.md 建立产品与 UI 决策的唯一事实源【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex本指南围绕 oh-my-codexOmX仓库中的skills/design/SKILL.md展开系统讲解$design这一仓库级设计工作流如何通过本地证据发现、最小化上下文访谈、以及一份可持续维护的DESIGN.md契约让产品目标、用户、信息架构、视觉语言、组件、无障碍与交互状态等设计决策沉淀为仓库中的唯一事实源。读完本文你将掌握$design的完整五步工作流、DESIGN.md的 13 个必备章节清单、与$visual-ralph的职责边界以及如何在实现阶段应用与交接该契约。一、$design是什么一份被维护的设计简报而非像素比对循环skills/design/SKILL.md开篇就界定了$design的本质Use$designto discover product and UI evidence, close only design-critical context gaps, and create or refresh the repositorys durableDESIGN.mdcontract. It is a maintained design brief, not a pixel-matching loop or one-off critique.翻译过来即$design用于发现产品与 UI 证据、只补齐设计关键性的上下文缺口并创建或刷新仓库中可持续维护的DESIGN.md契约。它是一个长期维护的设计简报而不是一次性评审也不是逐像素比对实现循环。从仓库源码看$design是 OmX 钩子系统中的一等工作流在 src/hooks/keyword-registry.ts 中$design被注册为优先级 6 的关键字路由到design技能并附带指引 Activate canonical DESIGN.md design-source-of-truth workflow。这意味着用户显式输入$design ...时钩子会将其激活为规范化设计工作流而不是普通的自然语言提示。该技能在docs/release-notes-0.17.0.md中被正式确立为 canonical design workflow同时弃用了旧的frontend-ui-ux快捷方式。何时使用、何时不用依据skills/design/SKILL.md的 Use when 小节以下场景适合调用$design产品、UX、前端或设计系统决策需要一个仓库本地的事实源source of truth一个功能在进入$ralph、设计者通道或实现之前需要一份设计简报design brief现有 UI、资源assets、截图或约束条件需要一个可落地的设计摘要。同时文档明确划定了禁止使用的边界视觉参考实现匹配应使用$visual-ralph、单纯的截图比对以及没有用户可见设计影响的纯后端/基础设施工作。与$visual-ralph的职责划分这是$design契约中最关键的一条边界原文表述为$designowns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions inDESIGN.md.$visual-ralphowns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run$designfirst when both are needed;DESIGN.mdsupports but does not replace the visual verdict target.即$design在DESIGN.md中负责产品目标、用户、信息架构、视觉语言、组件、无障碍、约束与未决问题$visual-ralph负责针对已批准的视觉参考或线上 URL 基线做实现、量化判定与像素差异证据。当两者都需要时先跑$designDESIGN.md支持但不取代视觉判定目标。这一划分在测试中得到了强制校验见 src/hooks/tests/design-skill.test.ts测试断言$design拥有产品目标/用户/信息架构/视觉语言/组件/无障碍/约束/未决问题而$visual-ralph拥有针对已批准视觉参考或线上 URL 基线的实现并明确DESIGN.md只是支持性上下文。二、五步工作流从证据发现到契约应用skills/design/SKILL.md的 Workflow 小节给出了完整的五步流程。每一步都有明确的对象与产出下面结合仓库实现逐条展开。步骤 1发现本地证据Discover local evidence第一步是盘点仓库中已经存在的设计证据原文列出的检查对象包括现有的DESIGN.md设计/UX/前端相关文档README、规格specs、issue路由、页面、布局、组件、story主题theme与 token 文件资源assets、截图/模型图mockupsStorybook 或 Playwright 基线无障碍/响应式/i18n/平台约束。关键要求是Separate observations from inferences; note absent evidence——把观察observations与推断inferences区分开并明确记录哪些证据是缺失的。这是为了保证DESIGN.md中每个结论都有据可查避免把猜测写成事实。步骤 2只访谈缺失的上下文Interview only missing context第二步只针对仓库无法自行解决的缺口提问原文档列举的访谈对象包括用户与任务users/jobs目标与非目标goals/non-goals品牌个性与被禁止的美学brand personality and forbidden aesthetics主流程primary flows无障碍/设备/浏览器目标不可用的资源或参考。一个重要的工程原则是如果答案无法获得就把明确的假设assumptions和未决问题open questions记录下来而不是阻塞流程。这保证了$design在信息不完整时仍能产出可行动的契约。步骤 3创建或刷新DESIGN.mdCreate or refresh DESIGN.md第三步是核心产出。原文档要求保留有用内容、移除矛盾、标记未知项、保持决策可执行并且根目录的DESIGN.md必须包含以下全部章节章节必备内容## Source of truth状态Draft | Active | Needs refresh、日期、产品表面、已评审证据## Brand个性personality、信任信号trust signals、避免项avoid## Product goals目标、非目标、成功信号## Personas and jobs主要用户画像、用户任务、使用场景## Information architecture导航、路由/界面、内容层级## Design principles原则与权衡tradeoffs## Visual language颜色、字体、间距、形状/层级、动效、图像/图标## Components现有/新组件、变体/状态、token 归属## Accessibility目标标准、键盘/焦点、对比度、语义、减少动效/感官问题## Responsive behavior断点/设备、布局适配、触摸/悬停差异## Interaction states加载、空、错误、成功、禁用、离线/慢网络如适用## Content voice语气、术语、微文案规则## Open questions[ ]问题、负责人、影响这套章节清单不是装饰性的而是被单元测试硬性锁定的契约见 src/hooks/tests/design-skill.test.ts测试逐一断言SKILL.md中必须出现上述 13 个## 章节源自 issue 2277 的设计检查清单。也就是说如果未来有人试图从 SKILL 中删减章节CI 测试会直接失败。步骤 4应用契约Apply the contract第四步规定在做出 UI 决策之前引用DESIGN.md中相关的章节复用文档化的组件与 token当实现过程中暴露出现有文档无法覆盖的矛盾时更新文件或新增一个 open question严禁发明一套并行的设计系统层Do not invent a parallel design-system layer。这一条与 OmX 总体的工程纪律一脉相承——在 templates/AGENTS.md 的 Anti-slop workflow 中同样强调prefer reuse plus boundary repair over new layers即优先复用与边界修复而不是新加层级。步骤 5交接Handoff第五步规定交接方式分两种情况常规前端工作提供相关章节、仓库证据与验收标准acceptance criteria视觉参考/图片/线上 URL 匹配类工作以已批准的基线交接给$visual-ralph并明确DESIGN.md仅作为支持性上下文。后者在 skills/visual-ralph/SKILL.md 中对应完整的量化闭环描述/URL - 批准参考 - $ralph 实现 - Visual Ralph 判定 像素差异 - 可复用设计系统其中每次编辑前都必须运行视觉判定score 90才允许继续像素差异仅作为次要证据定位热点。这正是DESIGN.md支持但不取代视觉判定目标的落地实现。三、证据与完成条件什么时候才算真正完成skills/design/SKILL.md末尾的 Evidence and completion 定义了严格的完成标准必须全部满足才可声明完成设计文档/资源/组件/截图已被检查或明确记录为缺失inspected or noted absent缺失的上下文已被回答、假设或列入未决问题answered, assumed, or listed根目录DESIGN.md包含每一个必备章节所有建议都引用DESIGN.md任何 Visual Ralph 交接与设计治理明确分离。这确保了$design的输出不是一次性的评论而是一份可被后续实现、评审、新成员入职反复引用的活文档。四、在 OmX 运行时中的实际路由与回归保障$design并非一个孤立文档它在 OmX 的钩子与测试体系中有完整的运行时支撑关键字路由src/hooks/keyword-registry.ts#L41将$design映射到design技能优先级 6。同时旧技能$frontend-ui-ux被标记为 removed/sunset见 src/hooks/keyword-detector.ts任何映射到已移除技能的候选 token 都会产生removedMatches条目并在 src/hooks/keyword-detector.ts 中转换为transition_error提示用户改用$design。契约回归测试src/hooks/__tests__/design-skill.test.ts覆盖四类断言——① 定义了规范化DESIGN.md事实源工作流② 要求 issue 2277 的 13 个检查清单章节③ 将设计治理与 Visual Ralph 匹配分离④ 显式路由$design并将$frontend-ui-ux视为 sunset stub其消息包含 use$design 指引。插件镜像仓库在 plugins/oh-my-codex/skills/design/SKILL.md 维护了同一份 SKILL 的插件镜像供插件模式下的技能市场发现使用对应docs/release-notes-0.17.0.md中插件模式技能市场曝光的能力。发布历史CHANGELOG.md明确记载 Canonical design workflow —DESIGN.mdand mirrored$designskill guidance now define the design workflow;frontend-ui-uxis deprecated见 CHANGELOG.md 0.17.0 条目。五、共享不变量所有技能的公共底盘skills/design/SKILL.md明确声明操作、委派、状态、钩子、团队、取消与验证的共享不变量位于 templates/AGENTS.md$design遵循该源头而不是在其内部重复这些规则。这意味着在使用$design时以下公共约束同时生效默认直连work directly任务已明确范围时单个 agent 直接完成并验证不强行委派先验证再宣称完成verify before claiming completion最小验证循环 define claim - run smallest validation - read output - report with evidence反注水纪律anti-slop优先删除与复用不新增并行抽象层不引入未请求的依赖状态与钩子边界钩子拥有技能激活与工作流状态持久化.omx/state/下技能不得重复或篡改钩子持有的状态。六、实操建议把$design用起来综合原文档与仓库实现一份可直接落地的使用路径如下触发工作流在 Codex 会话中显式调用$design 任务例如$design refresh our design docs——钩子会通过关键字注册表激活design技能测试中detectPrimaryKeyword($design refresh our design docs)返回技能design见 src/hooks/tests/design-skill.test.ts。发现证据按步骤 1 的清单盘点仓库区分观察与推断记录缺失证据。最小访谈只问仓库无法回答的设计关键缺口无答案时记录假设与 open questions不阻塞。刷新契约确保根目录DESIGN.md包含全部 13 个必备章节状态字段在Draft | Active | Needs refresh三态中选择。应用与交接实现阶段引用DESIGN.md、复用既有组件/token遇到矛盾就更新文件或加 open question涉及视觉匹配的工作按既定基线交接给$visual-ralph并由其执行score 90的量化判定与像素差异证据闭环。值得一提的是OmX 自身就是把$design当dogfood使用的——仓库在docs/architecture/cli-first-mcp-taxonomy.md、docs/STATE_MODEL.md等文档中持续沉淀架构决策契约这与$design所倡导的设计决策以仓库内文档为唯一事实源的理念完全同构。对于任何需要长期演进、多人协作、多 Agent 交接的 UI/UX 工作$design提供的不是一次性的审美评审而是一份会随实现持续更新的设计治理机制。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OmX$design技能实战指南用仓库级 DESIGN.md 建立产品与 UI 决策的唯一事实源【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex本指南围绕 oh-my-codexOmX仓库中的skills/design/SKILL.md展开系统讲解$design这一仓库级设计工作流如何通过本地证据发现、最小化上下文访谈、以及一份可持续维护的DESIGN.md契约让产品目标、用户、信息架构、视觉语言、组件、无障碍与交互状态等设计决策沉淀为仓库中的唯一事实源。读完本文你将掌握$design的完整五步工作流、DESIGN.md的 13 个必备章节清单、与$visual-ralph的职责边界以及如何在实现阶段应用与交接该契约。一、$design是什么一份被维护的设计简报而非像素比对循环skills/design/SKILL.md开篇就界定了$design的本质Use$designto discover product and UI evidence, close only design-critical context gaps, and create or refresh the repositorys durableDESIGN.mdcontract. It is a maintained design brief, not a pixel-matching loop or one-off critique.翻译过来即$design用于发现产品与 UI 证据、只补齐设计关键性的上下文缺口并创建或刷新仓库中可持续维护的DESIGN.md契约。它是一个长期维护的设计简报而不是一次性评审也不是逐像素比对实现循环。从仓库源码看$design是 OmX 钩子系统中的一等工作流在 src/hooks/keyword-registry.ts 中$design被注册为优先级 6 的关键字路由到design技能并附带指引 Activate canonical DESIGN.md design-source-of-truth workflow。这意味着用户显式输入$design ...时钩子会将其激活为规范化设计工作流而不是普通的自然语言提示。该技能在docs/release-notes-0.17.0.md中被正式确立为 canonical design workflow同时弃用了旧的frontend-ui-ux快捷方式。何时使用、何时不用依据skills/design/SKILL.md的 Use when 小节以下场景适合调用$design产品、UX、前端或设计系统决策需要一个仓库本地的事实源source of truth一个功能在进入$ralph、设计者通道或实现之前需要一份设计简报design brief现有 UI、资源assets、截图或约束条件需要一个可落地的设计摘要。同时文档明确划定了禁止使用的边界视觉参考实现匹配应使用$visual-ralph、单纯的截图比对以及没有用户可见设计影响的纯后端/基础设施工作。与$visual-ralph的职责划分这是$design契约中最关键的一条边界原文表述为$designowns product goals, users, information architecture, visual language, components, accessibility, constraints, and open questions inDESIGN.md.$visual-ralphowns implementation against an approved visual reference or live-URL baseline, measured verdicts, and pixel-diff evidence. Run$designfirst when both are needed;DESIGN.mdsupports but does not replace the visual verdict target.即$design在DESIGN.md中负责产品目标、用户、信息架构、视觉语言、组件、无障碍、约束与未决问题$visual-ralph负责针对已批准的视觉参考或线上 URL 基线做实现、量化判定与像素差异证据。当两者都需要时先跑$designDESIGN.md支持但不取代视觉判定目标。这一划分在测试中得到了强制校验见 src/hooks/tests/design-skill.test.ts测试断言$design拥有产品目标/用户/信息架构/视觉语言/组件/无障碍/约束/未决问题而$visual-ralph拥有针对已批准视觉参考或线上 URL 基线的实现并明确DESIGN.md只是支持性上下文。二、五步工作流从证据发现到契约应用skills/design/SKILL.md的 Workflow 小节给出了完整的五步流程。每一步都有明确的对象与产出下面结合仓库实现逐条展开。步骤 1发现本地证据Discover local evidence第一步是盘点仓库中已经存在的设计证据原文列出的检查对象包括现有的DESIGN.md设计/UX/前端相关文档README、规格specs、issue路由、页面、布局、组件、story主题theme与 token 文件资源assets、截图/模型图mockupsStorybook 或 Playwright 基线无障碍/响应式/i18n/平台约束。关键要求是Separate observations from inferences; note absent evidence——把观察observations与推断inferences区分开并明确记录哪些证据是缺失的。这是为了保证DESIGN.md中每个结论都有据可查避免把猜测写成事实。步骤 2只访谈缺失的上下文Interview only missing context第二步只针对仓库无法自行解决的缺口提问原文档列举的访谈对象包括用户与任务users/jobs目标与非目标goals/non-goals品牌个性与被禁止的美学brand personality and forbidden aesthetics主流程primary flows无障碍/设备/浏览器目标不可用的资源或参考。一个重要的工程原则是如果答案无法获得就把明确的假设assumptions和未决问题open questions记录下来而不是阻塞流程。这保证了$design在信息不完整时仍能产出可行动的契约。步骤 3创建或刷新DESIGN.mdCreate or refresh DESIGN.md第三步是核心产出。原文档要求保留有用内容、移除矛盾、标记未知项、保持决策可执行并且根目录的DESIGN.md必须包含以下全部章节章节必备内容## Source of truth状态Draft | Active | Needs refresh、日期、产品表面、已评审证据## Brand个性personality、信任信号trust signals、避免项avoid## Product goals目标、非目标、成功信号## Personas and jobs主要用户画像、用户任务、使用场景## Information architecture导航、路由/界面、内容层级## Design principles原则与权衡tradeoffs## Visual language颜色、字体、间距、形状/层级、动效、图像/图标## Components现有/新组件、变体/状态、token 归属## Accessibility目标标准、键盘/焦点、对比度、语义、减少动效/感官问题## Responsive behavior断点/设备、布局适配、触摸/悬停差异## Interaction states加载、空、错误、成功、禁用、离线/慢网络如适用## Content voice语气、术语、微文案规则## Open questions[ ]问题、负责人、影响这套章节清单不是装饰性的而是被单元测试硬性锁定的契约见 src/hooks/tests/design-skill.test.ts测试逐一断言SKILL.md中必须出现上述 13 个## 章节源自 issue 2277 的设计检查清单。也就是说如果未来有人试图从 SKILL 中删减章节CI 测试会直接失败。步骤 4应用契约Apply the contract第四步规定在做出 UI 决策之前引用DESIGN.md中相关的章节复用文档化的组件与 token当实现过程中暴露出现有文档无法覆盖的矛盾时更新文件或新增一个 open question严禁发明一套并行的设计系统层Do not invent a parallel design-system layer。这一条与 OmX 总体的工程纪律一脉相承——在 templates/AGENTS.md 的 Anti-slop workflow 中同样强调prefer reuse plus boundary repair over new layers即优先复用与边界修复而不是新加层级。步骤 5交接Handoff第五步规定交接方式分两种情况常规前端工作提供相关章节、仓库证据与验收标准acceptance criteria视觉参考/图片/线上 URL 匹配类工作以已批准的基线交接给$visual-ralph并明确DESIGN.md仅作为支持性上下文。后者在 skills/visual-ralph/SKILL.md 中对应完整的量化闭环描述/URL - 批准参考 - $ralph 实现 - Visual Ralph 判定 像素差异 - 可复用设计系统其中每次编辑前都必须运行视觉判定score 90才允许继续像素差异仅作为次要证据定位热点。这正是DESIGN.md支持但不取代视觉判定目标的落地实现。三、证据与完成条件什么时候才算真正完成skills/design/SKILL.md末尾的 Evidence and completion 定义了严格的完成标准必须全部满足才可声明完成设计文档/资源/组件/截图已被检查或明确记录为缺失inspected or noted absent缺失的上下文已被回答、假设或列入未决问题answered, assumed, or listed根目录DESIGN.md包含每一个必备章节所有建议都引用DESIGN.md任何 Visual Ralph 交接与设计治理明确分离。这确保了$design的输出不是一次性的评论而是一份可被后续实现、评审、新成员入职反复引用的活文档。四、在 OmX 运行时中的实际路由与回归保障$design并非一个孤立文档它在 OmX 的钩子与测试体系中有完整的运行时支撑关键字路由src/hooks/keyword-registry.ts#L41将$design映射到design技能优先级 6。同时旧技能$frontend-ui-ux被标记为 removed/sunset见 src/hooks/keyword-detector.ts任何映射到已移除技能的候选 token 都会产生removedMatches条目并在 src/hooks/keyword-detector.ts 中转换为transition_error提示用户改用$design。契约回归测试src/hooks/__tests__/design-skill.test.ts覆盖四类断言——① 定义了规范化DESIGN.md事实源工作流② 要求 issue 2277 的 13 个检查清单章节③ 将设计治理与 Visual Ralph 匹配分离④ 显式路由$design并将$frontend-ui-ux视为 sunset stub其消息包含 use$design 指引。插件镜像仓库在 plugins/oh-my-codex/skills/design/SKILL.md 维护了同一份 SKILL 的插件镜像供插件模式下的技能市场发现使用对应docs/release-notes-0.17.0.md中插件模式技能市场曝光的能力。发布历史CHANGELOG.md明确记载 Canonical design workflow —DESIGN.mdand mirrored$designskill guidance now define the design workflow;frontend-ui-uxis deprecated见 CHANGELOG.md 0.17.0 条目。五、共享不变量所有技能的公共底盘skills/design/SKILL.md明确声明操作、委派、状态、钩子、团队、取消与验证的共享不变量位于 templates/AGENTS.md$design遵循该源头而不是在其内部重复这些规则。这意味着在使用$design时以下公共约束同时生效默认直连work directly任务已明确范围时单个 agent 直接完成并验证不强行委派先验证再宣称完成verify before claiming completion最小验证循环 define claim - run smallest validation - read output - report with evidence反注水纪律anti-slop优先删除与复用不新增并行抽象层不引入未请求的依赖状态与钩子边界钩子拥有技能激活与工作流状态持久化.omx/state/下技能不得重复或篡改钩子持有的状态。六、实操建议把$design用起来综合原文档与仓库实现一份可直接落地的使用路径如下触发工作流在 Codex 会话中显式调用$design 任务例如$design refresh our design docs——钩子会通过关键字注册表激活design技能测试中detectPrimaryKeyword($design refresh our design docs)返回技能design见 src/hooks/tests/design-skill.test.ts。发现证据按步骤 1 的清单盘点仓库区分观察与推断记录缺失证据。最小访谈只问仓库无法回答的设计关键缺口无答案时记录假设与 open questions不阻塞。刷新契约确保根目录DESIGN.md包含全部 13 个必备章节状态字段在Draft | Active | Needs refresh三态中选择。应用与交接实现阶段引用DESIGN.md、复用既有组件/token遇到矛盾就更新文件或加 open question涉及视觉匹配的工作按既定基线交接给$visual-ralph并由其执行score 90的量化判定与像素差异证据闭环。值得一提的是OmX 自身就是把$design当dogfood使用的——仓库在docs/architecture/cli-first-mcp-taxonomy.md、docs/STATE_MODEL.md等文档中持续沉淀架构决策契约这与$design所倡导的设计决策以仓库内文档为唯一事实源的理念完全同构。对于任何需要长期演进、多人协作、多 Agent 交接的 UI/UX 工作$design提供的不是一次性的审美评审而是一份会随实现持续更新的设计治理机制。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
