Design Is 设计审计
依据 Dieter Rams 十项原则审计设计，产出分数、裁决，并生成可直接执行的 /make-plan 提示。
技能本身是纯审计流程，不执行外部命令，不写入系统配置，产出仅为 markdown 文件，权限需求合理。但技能未明确声明数据流（如哪些信息被记录）、用户确认机制（产出文件前是否需确认）及回滚方式（覆盖文件如何处理），且有依赖 agent-browser 等外部工具的提及但未提供安全边界。发布者身份未验证，但信任维度不受此直接扣分。扣分原因：缺少明确的数据流披露、用户确认和回滚策略。
技能有详细的流程、模板和失败模式防范，但依赖多个子代理和外部技能（agent-browser、/make-plan、/do），这些依赖的可用性未验证。无测试覆盖该技能本身，且静态审查无法验证实际运行。扣分原因：依赖外部未验证组件，无实际测试证据。
适用场景清晰（设计审计），有明确的不适用场景（常规UI代码审查、纯文案编辑等），触发条件（用户说特定短语）明确。但环境适配不足：技能为英文，无中文支持；依赖的 agent-browser 等可能在大陆网络不可达；且未明确对非 Web 设计（如移动端）的适用边界。扣分原因：中文支持缺失及对海外服务的依赖未披露。
文档结构良好，有分层（Do not use for、Phases、输出工件等），包含示例模板和已知限制（如子代理禁止评分），许可证和版本信息在仓库中明确。但技能自身版本号缺失，变更日志未提供，维护责任未明确（仅有仓库作者信息）。扣分原因：技能缺少版本号和变更日志。
核心任务（审计并生成计划）在文档中定义清晰，流程完整，理论上能产出直接可用的 /make-plan 提示。但静态审查无法验证输出质量，且依赖多个子代理和外部工具，实际效果不确定。扣分原因：缺乏实际运行验证，输出有效性仅基于文档推断。
仓库有 CI 工作流和大量测试文件，但测试主要针对仓库主功能（claude-mem），未发现针对该技能的测试。技能文件本身包含一些可审计的规则和模板，但无第三方执行证据。扣分原因：无针对技能本身的测试或执行证据。
- 技能依赖外部服务（如 agent-browser）可能在大陆不可达，需提前确认可用性或提供替代方案。
- 技能为英文，无中文版本，中文用户使用门槛较高。
- 技能的产出会覆盖或创建文件，但未明确用户确认机制和回滚策略，使用前需手动备份。
- 发布者身份未验证，下载和部署前应核实来源安全性。
这个 Skill 能做什么，适合哪些场景？
Design Is 是一个编排器型技能，用于对照 Dieter Rams 的十项原则审计设计。它通过并行子代理收集结构化、视觉、文案、重量和可访问性证据，然后由主协调器为每项原则打分（0–3 分），根据总分和关键原则的得分给出 NEW、REFINE 或 REDESIGN 的裁决，最后生成一份自带上下文的 /make-plan 提示，供后续会话执行。该技能要求用户指定审计对象（URL、仓库路径、Figma 框架等），并强调证据引证而非主观偏好。它不生成实现代码，而是以可执行计划交付。
该技能执行以下操作：首先在 Phase 0 中锁定审计范围并写入 00-scope.md；在 Phase 1 中并行部署四个（或五个）子代理收集证据——结构（交互元素数量、嵌套深度、重复模式等）、视觉（间距、字号、颜色数量、对比度、状态清单）、文案与诚实性（所有用户可见字符串、夸大措辞、黑暗模式）、重量与摩擦（JS 字节数、请求数、空闲动画等），可选的可访问性子代理；然后主协调器在 Phase 2 中依据严格锚点对十项原则中的每一项打分（0–3），并写入 02-scorecard.md；在 Phase 3 中根据分数规则产生裁决并写入 03-verdict.md；最后在 Phase 4 中生成 04-handoff-prompt.md，包含一个完整填充的 /make-plan 提示，该提示引用了裁决和最高杠杆的改进点。
- 设计师或产品经理在发布新 UI 或组件前，希望依据 Dieter Rams 原则进行快速审计，并获得可执行的改进计划。
- 开发者在重构界面时，面临 REFINE 还是 REDESIGN 的抉择，需要基于证据的分数和明确建议。
- 架构师在评估现有设计是否满足功能性和诚实性原则时，特别是当用户报告某些操作令人困惑或不透明时。
- 团队在计划新功能时，需要预先定义设计目标（如有用性、可理解性、克制），并确定交付物和反模式。
这个 Skill 有哪些优点和局限？
- 提供严格的、基于证据的框架，评分锚点和裁决规则明确，降低主观性。
- 强制要求为每个分数引用来源（file:line），并防止仅凭印象或代码库规模作出裁决。
- 通过内置的 /make-plan 提示，审计结果可直接执行，而非停留在理论层面。
- 明确区分协调器职责（评分、裁决）与子代理职责（收集证据），避免角色混淆。
- 依赖外部浏览器（agent-browser）进行视觉证据收集，若目标无运行实例，则推断事实可能不完整。
- 要求用户提供清晰的范围，否则可能审计错误表面；Phase 0 未妥善执行会导致浪费。
- 对“创新性”和“持久性”的评分依赖于协调者的主观判断，且缺乏客观衡量工具。
- 没有可自动化验证流程的测试套件；证据质量取决于子代理和协调者的遵循度。
- 仅提供 /make-plan 提示，不生成实现代码，需要额外步骤来实际实施。
如何安装这个 Skill？
该技能位于 monorepo 中，路径为 plugin/skills/design-is/SKILL.md。安装整个仓库集合时，将 plugin/skills/design-is 文件夹复制到你的 Claude 技能目录（例如 ~/.claude/skills/），或使用仓库 README 中的 /plugin marketplace add thedotmack/claude-mem 和 /plugin install claude-mem 命令；不过，这些市场命令安装的是 claude-mem 整个插件集，并非单独安装此技能。
如何使用这个 Skill？
触发技能：在 Claude Code 会话中，说出诸如“审计这个设计”或“根据 Rams 原则检查这个 UI”的短语。首先，Phase 0 要求你指定审计对象（URL、仓库路径或 Figma 框架）、主要用户和主要任务，并选择是否需要运行可选的可访问性检查。然后，该技能会创建 DESIGN-IS-YYYY-MM-DD/ 目录，包含输出工件（00-scope.md、01-evidence.md、02-scorecard.md、03-verdict.md、04-handoff-prompt.md），最后提供一个可复制的 /make-plan 提示。如果你引用尚不存在的设计，请指明这一点；该技能将直接跳到 NEW 设计裁决。