开发AI智能体用的设计工具，并整理好命令和检查

## 把设计命令归入一个技能，每个命令只对应一份资料 保持面向用户的命令界面紧凑，同时将每个匹配的命令路由到目标明确的参考资料。整合可以减少菜单干扰，并让共享设计准则更易维护。 ### 命令架构 - 除非确实需要独立的生命周期，否则应优先使用一个带子命令、可由用户调用的设计技能，而不是许多独立技能。 - 只维护一张路由表，将每条命令映射到对应的参考文件。 - 将命令说明、参数提示、类别和关系保存在权威元数据中，供构建流程和快捷方式生成器使用。 - 从一个来源生成各提供方专用的技能文件，不要分别编辑每份提供方副本。 - 轻量快捷方式只能作为指向规范命令的重定向。 - 将共享准则放入公共来源，将命令专属决策放入相关参考资料；链接共享指南，不要重复其内容。 ### 上下文路由 - 选择设计定位或平台规则手册之前，先读取项目上下文。 - 明确的项目字段优先，其次使用任务和界面线索，最后使用已有文档说明的默认值。 - 遇到无法识别的上下文值时发出警告，不要悄悄应用无关的规则手册。 - 当命令的平台行为存在显著差异时，加载变体参考资料而不是默认文件。 ## 先确定是品牌用还是应用界面用，再加上Web或各操作系统的规则 将设计目的和交付平台视为相互独立的轴。设计定位定义体验目标，平台定义交互惯例和实现约束。 ### 设计定位 - 当设计本身就是产品时使用品牌设计定位，例如营销、活动、作品集、编辑体验和独特的公共界面。 - 依据多种视觉路线中的独特性评判品牌作品，不要强制采用某一种流行风格。 - 当设计服务于应用程序、仪表板、管理界面或工具时，使用产品设计定位。 - 依据熟练使用后形成的熟悉感、信任感，以及资深用户操作的流畅性评判产品作品。 - 尽早确认设计定位，因为它会改变后续设计决策。 ### 平台 - 区分响应式Web、单一原生平台和自适应跨平台交付。 - 将原生平台指南叠加在已选设计定位上，不要把平台当作设计目的的替代品。 - 对自适应产品同时应用两套原生规则手册，并按操作系统调整；所有平台采用同一种视觉处理并不属于自适应。 - 即使源文件使用类似Web的扩展名，原生项目也应禁用浏览器覆盖层、HTML检测器和实时Web钩子。 - 将无障碍验证放在专用审计路径中。如果通用无障碍提醒会生成安全但设计不足的作品，就不要在创意生成期间反复插入这些提醒。 ## 遵守颜色规则和公开文案的禁用表达清单 视觉令牌、布局代码、编辑语气和已发布内容需要明确的负责人和自动检查，但这些机制不能取代人的设计判断。 ### 视觉基础 - 优先使用小型且易于检查的样式架构，其中包含一个入口、共享令牌和目标明确的局部文件。 - 始终一致地使用语义颜色令牌：正文使用对比度最高的墨色，只在字号足以支撑时使用较柔和的深色，次要标签使用弱化色调。 - 当视觉体系定义了带色调的两个极值时，避免使用纯黑和纯白。 - 将实现规则放在其所管控的界面附近，并在支持时保留热重载行为。 ### 编辑纪律 - 更改公共文案、教程、文档或营销页面之前，先阅读项目的编辑简报。 - 对过度使用的短语、标点和类似AI生成文本的模式执行已有文档说明的拒绝列表。 - 不要用拼写花招规避文本验证器。如果禁用术语具有必要的技术含义，应提出修改风格指南。 - 审查正则表达式无法判断的结构问题，包括空洞的确定语气、重复节奏、自动三项列举和公式化的对比转折。 - 将每个编辑条目放在一棵内容树中，由构建工具和渲染框架共同使用。 - 为命令说明提供简短标签，并设置使用场景、流程、具体示例和真实陷阱等部分。 ## 不把自动生成的文件混进日常的设计修改 分离创作来源、生成的分发内容、本地状态和发布输出，避免普通设计工作产生嘈杂或误导性的产物。 ### 源码优先构建 - 常规开发使用源码优先构建；需要同步受跟踪的提供方分发内容时，使用独立的发布构建。 - 将生成的提供方目录视为分发产物而非创作界面，即使为了安装而有意提交这些目录也是如此。 - 除非任务属于发布、生成输出同步或构建系统变更，否则不要在功能变更中包含生成的排列组合。 - 源码变更后，通过批准的工作流程重新生成受跟踪的输出；当清单、元数据或生成的前置元数据发生偏移时，使验证失败。 - 即使本地状态文件位于受跟踪的分发目录中，也要忽略它们。 - 当内容加载器或命令元数据不支持热重载时，重新启动开发服务器；不要把刷新浏览器误认为重新加载了构建时数据。 ### 已发布资源 - 根据权威元数据生成社交卡片及类似资源，避免可见数量和标签发生偏移。 - 需要清晰文字时，以较高分辨率渲染后再缩小。 - 视觉上发生变化的资源需要使缓存失效时，在同一变更中更新文件名及其所有引用。 - 通过平台预期的构建验证部署路由、重写、静态资源和服务器函数。 - 只有在新部署上线后，才预热外部预览缓存。 ## 未经许可不向外部项目提交内容，付费测试单独运行 设计工具可以自动化实现，但没有明确授权时，不得越过由人负责的贡献边界。 ### 贡献权限 - 遵循仓库先建issue或先获批准的贡献政策。 - 除非获得授权的维护者已提出要求或明确批准，否则不得创建外部issue或拉取请求。 - 政策要求时，在提交、变更说明、评论和issue正文中披露AI协助。 - 如果没有授权的AI智能体仍被要求发布，应停止外部操作，改为准备本地交接通知。 - 普通贡献中不要包含生成的发布产物或无关的同步变更。 ### 测试选择 - 将快速、确定性的单元测试和fixture测试保留在默认测试套件中。 - 将浏览器驱动的完整周期测试、依赖项安装、实时开发服务器和付费模型调用放在明确选择加入的命令之后。 - 仅在更改昂贵实时测试所覆盖的集成路径时运行这些测试，不要将其设为不受限制的默认行为。 - 让测试智能体可通过狭窄接口替换，并用确定性的替代实现覆盖广泛的fixture场景。 - 进行行为评估时，应断言工具调用轨迹，而不是润色后的自由形式回答。 - 当跨提供方路由是被测行为时，运行多个模型系列；缺少凭据时应干净地跳过。 - 除非有意接受成本和波动性，否则不要在持续集成中运行付费评估套件。 ## 新增命令时同步更新所有清单，发布新版本单独进行 命令和独立分发的组件需要同步元数据，但功能开发与发布工作应保持分离。 ### 添加或更改命令 - 同时添加命令参考资料、路由器条目、菜单条目、有效命令列表、元数据、类别、关系和可视化映射。 - 更新用户可见的每一个命令数量，并让构建流程从路由器推导和验证机器可读的数量。 - 将可选的编辑内容与自动触发说明分开：前者面向读者编写，后者用于命令匹配。 - 平台专属命令存在显著差异时，添加经过路由的变体，并将共享操作系统细节保留在平台参考资料中。 ### 版本与发布政策 - 普通功能变更中不要提升版本，也不要添加发布说明。 - 对独立分发的组件分别进行版本管理，只更新发生变更的组件。 - 发布时，更新权威清单和同步镜像，添加用户可见的说明，运行发布构建，然后使用组件专属前缀创建标签。 - 发布前预览发布自动化流程。 - 当工作树存在未提交变更、分支未同步、标签已存在、说明缺失，或重新生成产生未提交偏移时，拒绝发布。 - 变更日志条目应简洁并面向用户；省略内部重构、工具细节和生成输出同步。 ## 先写会失败的测试，再添加新的设计检查 当一个设计检测器供CLI、浏览器覆盖层、扩展和网站使用时，其规则引擎必须只有一个来源，并且必须重新构建和验证每个派生使用方。 ### 规则开发顺序 1. 添加包含唯一标识示例的fixture，其中至少有四个应标记的案例和五种误报形式。 2. 测试DOM没有布局引擎时，使用明确的尺寸。 3. 实现规则之前添加有针对性的测试，并观察它失败。 4. 添加规则元数据和一个纯检查函数；该函数不访问DOM，并返回稳定的标识符和代码片段。 5. 分别实现浏览器适配器和测试DOM适配器，然后将两者接入每一个相关遍历循环。 6. 重新构建生成的每个检测器使用方，并运行完整测试套件。 7. 在浏览器中验证fixture和具有代表性的真实页面，以发现适配器不一致和误报。 ### fixture与评估纪律 - 在代码片段中使用稳定的引用文本或其他确定性标识符，使测试能够提取匹配案例。 - 不要依赖DOM模拟器中的布局几何信息；应解析明确的样式。 - 当浏览器和模拟器行为不同时，为背景、渐变和颜色规范化使用共享辅助工具。 - 衡量效果时，比较同一简报在使用和不使用设计系统时产生的设计输出。 - 将评估基础设施放在独立工作区中，并提供自己的操作说明。 - 评估扫描前构建最新设计源码；每当顶层指南标题发生变化时，更新相应的内联技能章节筛选器。