using-design-skills

using-design-skills

你要决定任务需要哪些设计技能、按什么顺序使用，以及由谁执行每个阶段，然后委派给相应技能。成员名单、角色表和执行者详情见 references/design-roles.md——在组合工作流时阅读；切勿凭记忆决定路由。

绕过

• 仅后端／非 UI 工作 · 一行 CSS 或文案微调（直接处理；最多查阅 DESIGN.md）· 用户为单个技能规模的任务指定了一个成员技能 → 直接处理。
• 循环式非设计工作（审计、规划→构建）→ using-workflows。

触发条件

任何价值体现为视觉效果或界面形态的交付物：页面、屏幕、HTML 报告／图表／计划、工件、仪表板、动画、模型图、模块／API 接口设计。

问题——按顺序组合工作流

Q1 基础交付物——谁负责输出？ 图表 → 所有图表均由 diagram-design 负责（统一样式、mermaid、draw.io、PNG-SVG 导出）· 报告或计划页面 → 在 artifacts-rules 下构建一个独立 HTML 文件 · Web／移动端 → 目标技术栈 · 工件 → 工件文件 · 指标、KPI、状态或任何大规模扫描比较内容 → 工件类型 Dashboard · 动画、讲解或演示视频、演练、动态图形 → 工件类型 Motion（两者都需要：先使用 Artifact quickstart，然后由对应类型的说明负责结构）· 数据文件 → data-report · 模块／API／领域 → Pipeline D · token 工作 → DESIGN.md 本身 · 仅模型图 → 静态 HTML 模型图，不进行构建循环 · “这样能行吗？” → prototype，单独使用，不进行循环。 没有 Artifact 工具（Codex、Cursor、agy）→ 上述每条 Artifact 路径都改为在 artifacts-rules 下创建一个独立 HTML 文件；在报告中说明。

Q2 变体。 现有界面 → 先审计（权威技能在重建前评审当前渲染效果）。新建 → 直接构建。

Q3 正交专项技能（叠加使用）。 数据文件中的图表 → data-report；页面或 Dashboard 中的图表 → dataviz。Artifact → artifact-design。这两者随运行环境提供，而非随 lock 提供；发布前必须使用 artifact-design；若本轮无法解析，则明确说明跳过其中任一项。UI 动效或手势 → apple-design（它也会约束 Motion 工件；工件类型仍是负责人）。约束集内联加载。

Q4 每个阶段的执行者——参见 references/design-roles.md 中的执行者表。方向设计在 INLINE 中运行；非简单构建 → 使用 agent-tmux claude 持久工作进程；每次评审 → 使用全新的一次性执行者，且绝不能由作者评审（有头与无头模式：参见 using-tmux-agent-tools §QUESTIONS；是否需要新的评审者：参见 judgment-rubrics §2）。

Q5 验证者。 涉及渲染 → 使用下方的视觉质量循环（完整的 Gate 0 截图证据；对于 Motion，提供开始、中间和结束帧）。仅修改 DESIGN.md → 仅文档证据（文件哈希／提交、token 完整性、对比度计算）。Pipeline D → 非视觉循环：由全新的评审者依据 codebase-design 深度标准评估设计比较，结论仍为 PASS/BLOCK。prototype → 无。

选择——先发现当前状态，再分配角色

1. jq -r '.skills|keys[]' ~/.agents/.skill-lock.json 是已安装的技能名单；要与本轮当前可用技能列表交叉核对，因为未加载的已安装目录不可调用。成员若启用了 disable-model-invocation: true（检查 head -8），则通过内联阅读其 SKILL.md 来使用，绝不能通过 Skill() 调用。
2. 视觉工作流只能有一个方向权威技能（Pipeline D／原型／微小调整则为零个）。绝不能叠加两个——它们会互相冲突。未知技能绝不能自动升任权威技能。
3. 先前的成员技能若缺失或不可调用 → 在计划中说明缺失情况和替代方案；若某角色无人可用 → 明确说明降级处理。绝不能默默替换。
4. 每个选定技能都必须在其阶段开始前阅读 SKILL.md。

DEFER — 跨阶段约定

• DESIGN.md：由方向阶段编写（直接读取/写入——已移除 design-md helper skill）；所有后续阶段和每个工作者提示词都会读取它。工作者没有聊天记忆——绝不要只在聊天中传达方向。
• 调度：通过 tmux 调度的任务经由 using-tmux-agent-tools 路由；工作者提示词来自 delegation-templates；层级遵循 ~/.agents/rules/model-dispatch.md §4–§5，评审者独立性遵循 §6。扇出/对话需要用户明确授权。
• 循环拓扑（固定）：BUILDER 是持久工作者——BLOCK 发现会返回给同一个 builder（工作者复用协议）。每个 REVIEWER 都是全新的一次性工作者，绝不能是 builder，也绝不复用。
• 工作者提示词补充内容："DESIGN CONTEXT: read {repo}/DESIGN.md first; conform to its tokens. SKILL: read and follow {member-SKILL.md} first."
• 图示默认规范（这些默认设置会覆盖成员的主动选择门槛，但不会覆盖其机制）：故事本身就是方向的图示——数据流、架构、依赖关系、部署——默认采用动态效果。请求 diagram-design 模式 loop，并使用 Flow-token 原语（一个 aria-hidden token，循环周期 ≥3s，无播放控件）；仅当路径顺序承载含义时，才升级为 reveal + Path 绘制；仅用于教学时才升级为 step。其他所有图示类型（ER、象限图、条形图、维恩图）默认设为 none——没有可供指示的流动，动态效果就只是装饰。静态优先约定不放宽：关闭 JS 时，以及在减少动态效果模式、打印和所有导出中，都必须能看到带有完整标签的图示。
• 格式：优先使用 HTML。 每个图示和视觉交付物都必须是独立的 .html；svg/png 必须从中导出，绝不手工编写。Markdown（mermaid 代码围栏）只有在用户提出要求，或使用方工具只能处理文本时才可用——绝不能由 Agent 自行猜测“读者大概看不到图像”。

质量闭环——任何流程都不能止步于“构建完成”

**关卡 0，默认失败关闭：**审核者记录构建标识（哈希/提交）， 产物路径/URL、截图路径、视口，以及是否为完整页面/未裁剪。 响应式交付物必须包含桌面端和移动端。证据缺失、过时或被裁剪 → UNCONFIRMED → 总体结果为 BLOCK；绝不能仅凭代码审核判定 PASS。 （仅文档交付物除外：如果交付物只有 DESIGN.md，则记录文件 哈希/提交；一旦有任何渲染结果，就恢复完整要求。）

**质量标准：**获奖级——足以赢得 Awwwards、Webby Awards 或 FWA 奖项的作品。“正确且整洁”并非标准。

审核顺序（人类始终最后）：

1. 内部：构建者先对照标准自行检查渲染结果，然后使用 advisor 或一次性 opus/sonnet 至多进行 3 轮评审。每轮之间修复问题。若某轮没有发现能推动作品 接近标准的问题，就停止。
2. 外部（可选，视难度而定）：对于高难度工作——新的视觉方向、 复杂交互或动态效果，或高风险事项——或内部评审意见分歧时，增加一位新的 CLI 审核者 （consensus-gate、args.cli）。简单工作则跳过。请在报告中说明增加 或跳过的原因。
3. 用户：最后查看关卡 0 的证据包。 每轮都必须发现与标准的差距，否则就停止。绝不能只为 证明进行过审核而增加评审轮次。

**评分标准，按优先级排列：**1. 「THE SLOP TEST」——权威方的审核标准， 按上述质量标准评判；泛化的渐变主视觉区/表情符号项目符号/ 千篇一律的卡片网格 = BLOCK，无论内容是否正确；渲染结果整洁但未达到获奖水准，也同样如此。2. 文案规范——没有填充内容， 层级清晰易读。 3. 符合 DESIGN.md 要求。4. 当前阶段冻结的 ACCEPTANCE 标准。

**何种情况算作 BLOCK：**仅限上述评分标准中的项目或冻结的 ACCEPTANCE 标准。无任何 ACCEPTANCE 条目明确要求的无障碍优化（点击区域、对比度、aria 名称、焦点环、 跳过链接）属于 NOTE——列出即可，不要因此判定为 BLOCK，也不要为此开启修复轮次。仅返回 NOTEs 的审核者应返回 VERDICT: PASS。

**报告约定：**每项标注 PASS / FAIL / UNCONFIRMED，并附一行理由； 发现项标记为 persistent/new/regression/evidence-gap；所有阻塞项必须在同一轮 全部列出；最终一行必须原样为 VERDICT: PASS 或 VERDICT: BLOCK， 并在报告中逐字引用。报告缺少 VERDICT: 行属于该审核者的格式缺陷：再次要求同一审核者只补上这一行——绝不能另启一位审核者来获取该行。

**评审轮次：**BLOCK → 同一位持续负责的构建者修复 → 新审核者 重新审核。修复轮次最多两轮，然后按原因处理：同根因失败

• 方向错误信号（judgment-rubrics.md §4）→ 返回方向制定阶段 · 证据缺口 → 修复证据路径，重新审核 · 新问题/回归问题 → 分别分流处理 · 否则 → 停止并向用户说明失败经过。 PASS → 将最终 token 写入 DESIGN.md，并附上证据包提交报告。 “已构建并审核：PASS”才算完成声明；仅说“已构建”不算。

**润色/Operate 模式——先设人工检查点：**首次渲染的构建结果必须先交给用户 （URL/截图，桌面端 + 移动端），然后才能启动任何审核者。方向由用户决定；审核者只检查 用户已接受的方向。只进行一轮审核，不进行循环评审。

NOT-FOUND

所需角色没有已安装的成员 → 明确说明流程降级以及跳过了什么——绝不能伪造阶段。成员约定：各技能自己的 SKILL.md · 名册/角色/执行者：references/design-roles.md · 工作者机制：tmux-agent-tools · 提示词：delegation-templates。