Design Harness
运行一个可恢复的 Web 用户界面工作流。让用户保持对意图的控制，并将设计生产与审查分离。
启动与恢复
将 <skill-dir> 解析为包含此 SKILL.md 的目录；不要假定当前工作目录包含捆绑的脚本。
- 在提问之前，运行
node <skill-dir>/scripts/preflight.mjs --root <project>。读取其能力报告；不要安装任何东西。将缺失的文件系统路径视为建议性：检查主机已加载的技能/插件清单，然后再声明 Impeccable 或 Jakub 不可用。 - 运行
node <skill-dir>/scripts/state.mjs init --root <project>。这会安全地升级旧版状态，因为init是一个可变命令。如果状态已存在，则运行只读的status命令并在其nextPhase处恢复；切勿重新启动已完成的阶段。在检查或升级旧版运行而不重新初始化时，使用明确的migrate。 - 仅读取当前阶段所需的参考资料：
- 发现/确认：references/interview.md
- 上下文/方向：references/context-contract.md
- 构建/工具选择：references/routing.md
- 可选来源选择：references/optional-tool-registry.json，仅在激活条件被确认后
- 审查/QA/交接：references/review-and-qa.md
- 在每个阶段完成后，使用
node <skill-dir>/scripts/state.mjs advance <phase> --root <project>推进状态。对于human-feedback，还需传递--outcome used或--outcome not-used。对于feedback-fixes，传递--outcome applied或--outcome not-applicable。
使用以下固定的单调序列：
preflight → discovery → confirmation → context → direction → build → internal-review → human-feedback → feedback-fixes → independent-review → fixes → qa → handoff → complete
仅将机器状态存储在 .design-harness/state.json 中；报告和截图属于 .design-harness/reports/。切勿存储完整的聊天记录、令牌、cookie、凭据或不相关的环境数据。
执行审批门控
自适应地进行访谈，并将答案总结在一张简洁的确认卡中。包括产品、受众、主要目标、内容、页面/界面、期望和不期望的品质、正面和负面参考、约束、动效、必需状态、技术栈、委托、AI 特定状态、WebGL 容忍度、外部来源政策以及任何付费许可边界。仅询问缺失或重要的细节。
在用户明确批准确认卡之前，不要编写、编辑或生成 UI 生产代码。预检、提问、只读检查以及聊天内的确认卡草稿或提议的意图内容是被允许的。在批准之前，不要创建或修改项目意图 .md 文件。
如果参考资料缺失，将描述性词语视为足够。推导出两到三个带有具体权衡的命名方向，并让用户选择。仅在可视化工具存在且用户会受益时生成视觉看板；切勿将看板设为先决条件。
创建已批准的上下文
确认后，根据用户答案或用户明确批准的提议填充以下文件：
PRODUCT.md，包含已批准的brand或product注册表REFERENCES.mdDESIGN.mdACCEPTANCE.md- 至少一个
.impeccable/surfaces/<slug>.md
从 PRODUCT、references、design、acceptance 和 surface 模板复制结构。仅在用户批准其内容后，才将每个意图文件标记为已批准。在构建前运行 node <skill-dir>/scripts/validate-context.mjs --root <project>。
保持 DESIGN.md 的 H2 部分完全按照以下顺序各出现一次：Overview、Colors、Typography、Elevation、Components、Do’s and Don’ts。
将 PRODUCT.md 和 DESIGN.md 视为批准后受保护的文件。对于任何后续更改，显示提议的差异，请求明确批准，然后应用。切勿静默地合理化偏差。
在 REFERENCES.md 中记录每个已批准的外部组件、配方、效果或反馈集成，包括其确切来源、所选项目、可用的固定版本或提交、访问日期、预期用途、当前许可/条款结果、适应性以及必需的回退。“使用外部库”不是对特定来源的批准。
通过 Impeccable 构建
使已安装的 Impeccable 技能及其已批准的上下文成为本次运行的唯一设计和生产权威。加载其技能和相关领域参考资料，然后为其提供已批准的意图文件和界面。不要让它重复发现或重新解释已批准的意图。让 Impeccable 生成或刷新 .impeccable/design.json；切勿手动编辑该 sidecar，并且在没有受保护的差异和批准流程的情况下，切勿接受由此产生的 PRODUCT.md 或 DESIGN.md 更改。
不要在同一生产运行中加载任何其他广泛的品味或设计系统技能。仅根据 references/routing.md 路由狭窄的辅助工具。除非已批准的上下文授权更改，否则保留现有的组件库和技术栈。切勿自动安装或自动复制可选的注册表条目；解释确切的有界用途并首先获得批准。
在构建后运行 Impeccable 的自我审查并记录发现；这是 internal-review，而不是独立审查。一旦用户界面足够稳定以供检查，进入 human-feedback：在有用时提供已批准的 Agentation 检查点，或记录 Not used 并附带 --outcome not-used 并推进。保持 Agentation 开发专用和手动/本地模式；MCP、webhooks 和自主解决需要单独的明确批准。在 feedback-fixes 中，仅应用已裁决的用户注释并记录 --outcome applied；当反馈被跳过时，记录 Not applicable 并附带 --outcome not-applicable 并推进而不进行编辑。在独立审查之前解决用户注释。
分离审查、修复和 QA
对于 independent-review，使用 Jakub 当前的 better-interface 技能及其六个领域技能启动一个新的只读子代理/上下文。为其提供截图、相关的实现文件、组件库约束以及已批准的意图文档。在构建后请求全面审查。审查者必须仅报告发现，且不得编辑或静默地重新设计。
在根上下文中，根据 PRODUCT.md、DESIGN.md、界面规范、验收标准和组件库对每个发现进行裁决。记录接受/拒绝/推迟及理由。通过生产权威单独应用已接受的修复，然后请求对变更区域进行一次集中的快速只读审查。
遵循 references/review-and-qa.md。运行 Impeccable 检测器、Playwright 截图（移动/平板/桌面）、axe 和 Lighthouse。涵盖代表性路由以及适用的加载、空、错误、长文本、悬停、焦点和减少动效状态。对于可选来源，还需运行其注册表门控：语义/静态回退、无 WebGL 行为、已批准的浏览器、移动 CPU/GPU 或捆绑包预算，以及适当时从生产中排除开发工具。将不受支持或未执行的状态标记为 Not reviewed；切勿将其报告为已通过。
对于具有有意义文档滚动动效的界面，或为视频/演示准备就绪，在专用本地端口上启动新的生产构建，并在调整脚手架配置后，运行 node <skill-dir>/scripts/verify-motion.mjs --root <project> --base-url <url> --routes /,<other-routes> --config .design-harness/qa/motion.config.json。验证器默认测试移动、平板和桌面，在每个新上下文中隔离每个路由，要求成功的路由响应、配置的内容根、预期的观察到的 URL/重定向链以及可测量的文档滚动，并且不模拟应用程序请求或允许重定向，除非显式项目配置声明每个例外。保留其 schema-version 4 的 Playwright/浏览器来源以及截图/模拟哈希与交接。将首帧/启动探测和帧间距阈值仅视为该机器和浏览器的证据，绝不作为通用的 60 FPS 保证。
使用 node <skill-dir>/scripts/scaffold-qa.mjs --root <project> 预览通用 QA 脚手架，并在确认卡授权 QA 计划后添加 --apply。仅在现有文件将被替换时再次询问。它从不安装依赖项。
交接
仅当已批准的验收标准通过且没有阻塞性发现或无法解释的 QA 缺口时，才声明状态 Ready；否则声明 Not ready。列出已更改的文件、截图、审查发现及处理情况、自动化检查及结果、不受支持的状态、剩余的缺口，以及每个实际使用的外部来源及其固定来源和许可结果。推进 handoff，然后仅在工作流真正完成时运行 node <skill-dir>/scripts/state.mjs complete --root <project>。