agentic-design-system

Agentic Design System

ADS 是视觉与前端工作的统一入口。使用一个循环：

understand → choose → work → prove → decide

仅涉及文案或机械操作的小改动应保持简单：保留选定的方向并检查受影响的结果，不必重新编写简报、研究、制作多个变体、生成评估报告或完整截图矩阵。非视觉工作无需使用 ADS。辅助工具用于支持这个循环，不会另行创建流程或预算。

从此技能目录解析路径。<skills-root> 是它的父目录。已安装的版本不包含 create-design-workflow.md。可选的源代码维护工作流需要使用源代码检出版本。

对于安装审查或项目默认设置变更，请阅读信任与自定义：执行影响、可选遥测、审美偏好覆盖和来源信息。这不是每项任务都要增加的阶段。

理解

对于重要工作，根据请求和当前产品资料整理一份简短的内部简报：

• 用户任务与成功标准： 用户需要理解、决定或执行什么；预期的阅读／操作顺序。
• 确切界面与基线： 要更改的现有路由、组件、文档或产物，以及必须保留的内容；在相关时查看其当前源代码和渲染基线。扩展后端并不意味着可以替换选定的前端。
• 参考与方向： 要借鉴哪些特性、排除哪些内容，以及期望的还原度。指出缺陷的截图是证据，不会自动构成新的艺术方向。
• 输出与覆盖范围： 请求的格式、有意义的状态、目标浏览器／断点，以及如何以可用形式将结果交付给用户。

使用任务现有的简报或笔记；如需更完整的交接，可选用结果模板。复用已有答案。只有在存在无法通过现有信息确定、且会影响结果的重要未决选择时，才提出问题。已获授权的构建／修复请求允许进行范围明确且可逆的本地实现；不要再次询问相同的写入权限。外部写入、部署、安装、花费和破坏性操作仍需各自的授权。

阅读相关的 DESIGN.md、指南、设计令牌、组件以及已接受／否决的决策。保留未知的 DESIGN.md 部分；若前置内容与正文冲突，以前置内容中的令牌为准，除非当前用户或主要来源予以更正。解决实质性冲突，不要用邻近的替代方案敷衍。只有在现有产品语言无法满足需求时，才使用预设。

对于生成或重要审查，请阅读 Foundation v2：utility 是产品／运营工作的默认选项；expressive 仅适用于营销、编辑、发布或明确要求品牌表达的范围。不要把朴素的实用界面改造成创意作品。已确认的 never 违规会阻止给出就绪结论；仅用于报告的候选项需要实际确认。合同中的数值评分标准只是可选的诊断参考，不是审美认证或发布认证。

选择

根据用户意图进行分流：探索真正尚未解决的方向，构建已获授权的变更，或审查，但不默认包含修复。只启用任务所需的负责人：

• design-review 负责产品/任务契合度、信息架构、参考资料还原度和视觉判断。
• ux-baseline-check 负责适用状态和可复用组件契约。
• ui-polish-pass 负责工艺、几何、文本/数据/表单机制和基础组件。
• Ember 默认读取重要设计交接的证据。 它不是构建者、独立审查者或品味评判者。

仅在符合相应需求时加载专门能力：

• 有期望的视觉目标：../visual-reference-calibration/SKILL.md。记录借用的层次、 排除项和还原度；如有帮助，可使用参考资料收集。
• 存在选项或尚未确定的方向：../design-variations/SKILL.md。需要做选择时，提供具体建议 以及可供审查的备选方案或目标；获批后不要再凭空创造选项。
• 对符合条件的营销/编辑/发布工作明确要求个性或惊喜感：../whimsical-design/SKILL.md。
• 明确要求沉浸感/氛围：../world-build/SKILL.md。
• 动效或交互体验：../web-animation-design/SKILL.md 和 design-review 动效参考资料。
• 面向 Agent 的公共接口：../agent-friendly-design/SKILL.md，仅用于所需的 语义或机器可读行为，不要自动扩展可抓取性/API。
• 深入的移动端判断：移动端审查。
• 需要高判断力、且适合由获授权的独立评审者审查的工作： 对抗式审查。确认运行环境可用； 同一 Agent 重新阅读不属于独立审查。

分流参考包含专门能力的详细信息，不是第二个入口。 对于文档、演示文稿或图像，使用相应的原生制品能力；共享简报不会强制要求这些输出经过 Web 实现或 Web 状态清单。

工作

在预期的产品和输出格式中构建。保留有用的控件、内容、设计令牌和交互模型。将结构、状态覆盖和工艺作为一个连贯流程完成，而不是分成三个串行环节。复用现有基础组件；在大量扩展组件前先定义组件契约；如果复用是预期结果的一部分，则验证实际使用方。

按以下顺序审查；修复较早环节的问题后，再润色较后的环节：

1. 产品、界面和用户任务是否正确。
2. 信息/操作结构是否易于理解，包括证据检查和返回上下文。
3. 是否忠实于简报/参考资料，并采用明确的视觉方向。
4. 工艺和组件是否一致。
5. 行为、适用状态、目标界面和交付是否可用。

保留已有的有效部分。技术实现摘要不能代替产品对用户的答复。对于审查，除非已获授权修复，否则只报告发现的问题，不做编辑。

验证

使用能够证实声明的证据。源码检查仅供参考。将实际浏览器中的重要视觉变化与匹配的基线／参考截图进行检查；如适用，还要在目标桌面端和移动端／WebKit 环境中测试交互。截图无法证明动画、键盘处理或返回先前上下文的能力。缺少必要访问权限时，结果应标记为未验证。

design-review 负责捕获说明，以及已确立的门槛与仅用于报告的度量之间的区别。选择与任务相关的源码检查和状态，而不是使用通用矩阵。即使源码扫描器通过，必要的无障碍、状态、布局或交互检查失败，仍会阻止给出就绪结论。将诊断信息与未经修改的主要捕获结果分开。

对于已更改的权限、只读、禁用、离线或破坏性状态，请验证其附近的每项操作在标签、强调方式、原生启用状态、语义和辅助文本方面都一致。在不受影响的状态中保留有效操作。此相邻操作检查由 UX 基线负责，也会在一项实质性的独立审查中检查。如需记录精确位置、严重性以及问题与修复之间的可追溯性，请使用结构化发现。

对于实质性工作，可选用决策溯源记录重要的源码到决策链接。它不会增加模型调用，也不会将小改动变成可追溯的运行。

做出判断

对于实质性的设计交接，使用 Ember 阅读此循环中已收集的证据，并提供简洁的 Ember 审查：检查了什么、哪些内容未通过或仍未验证，以及哪些内容仍需用户判断。遵循其简短交接；这是结果的一部分，而不是第二次审查或执行循环。只有在实际审查证据后，才能使用此标题。如果没有进行审查，请明确说明，不要使用 Ember 标签。除非用户明确要求，否则不对微小的文案或机械性改动采用此包装。

返回结果、证据以及实际尚待做出的决策。使用一个范围明确的结论：ready、needs repair 或 blocked；说明产物是本地候选版本、已安装、已交付还是已发布。Ready 仅指有证据支持的任务／版本，不代表审美认可或发布许可。交付可用的附件，或已获授权且可访问的审查界面；机器本地路径、截图文件夹或 localhost 都是内部证据，不属于远程交付。

ADS、Ember 和专家共用一份任务预算：一轮实现／审查，外加最多一轮修复，除非用户另行提供预算。修复后重新捕获受影响的证据。切换技能、审查者、审美方向或运行器都不会重置预算。达到预算上限时，保留候选版本和未解决的问题；诊断失败的假设，并报告具体阻碍或待定决策。不要自动重建、转向其他方案或开启另一轮审查。

保留反馈前，先对其分类：明确的偏好归入现有偏好负责人；项目决策归入项目上下文；反复出现且可测量的缺陷归入基础组件／测试；一次性修正归入任务本身。只有在确有必要且权限允许时，才更新负责该事项的说明。已接受示例必须有真实的人工认可；修订后的截图不会自动成为正面示例。不要在每次构建后都附加一条通用经验。