Communitygithub.com

r3xsean/设计流程

用于设计、重新设计或打磨产品UI时;在截图的设计评审中运行;或记录用户对设计的反应时使用。

设计流程 是什么?

该技能为AI代理设计产品UI提供了一套完整、严谨的文档驱动型工作流程。它明确了“用户决定方向,模型评判执行”的核心原则,强调任何评分或模型共识都不能替代用户对设计方向的决策。技能定义了`docs/design/`目录下的四个核心文件:`product-brief.md`(产品事实)、`DESIGN.md`(用户决策与反应日志)、`harness.md`(运行与捕获规范)和`run.md`(单次运行记录),并提供了模板。工作流涵盖从项目初始化(Bootstrap)、探索、细化、设计评审到最终发布的完整阶段,支持通过“设计评审委员会”进行多模型交叉审稿,并严格遵守用户决策,甚至通过“保留测试”确保设计方案的无偏差性。该技能兼容Cursor、Claude Code、Codex、Windsurf等多平台,通过文件约定和引用文档自动执行各阶段任务。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/r3xsean/r3xstack/tree/HEAD/skills/design-process

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

设计流程 是做什么的?

用户决定方向与品味。模型评判执行:任务能否完成、数据是否真实、是否有任何破坏、隐藏或误导行为。分数、评审委员会或模型共识绝不能用于选择方向、合并方向或推翻已记录的决定。

如果项目有自己的设计技能,请遵循该技能;它可能会将你送回本流程的某个阶段。

项目文件

位于 docs/design/ 目录下,除非项目的 AGENTS.md 为这些文件指定了其他位置:

  • product-brief.md:产品事实。谁在使用它,每个界面必须允许用户做什么(主导问题及其模式:操作、阅读或说服)、数据和状态、文案及信任边界。如果项目已有 PRODUCT.md,则产品简报链接到该文件,而非重复内容。
  • DESIGN.md:用户的决策、例外、已批准的参考截图以及反应日志。已记录的决定优先于你的偏好。若未记录任何决定,则外观为开放状态;当前 UI 是证据,而非决定。
  • harness.md:屏幕和原型的运行及捕获方式:命令、场景、视口、竞品应用、捕获文件的存放位置。
  • runs/<YYYY-MM-DD-name>/run.md:单次运行的问题、已修复和待解决的问题、已知限制、评审委员会成员与目标、立场关键点、结果。

上述四个文件的模板均位于 templates/ 目录。若前三个文件中缺少任何一个,请先进行引导。每次运行(包括跳过了引导步骤的运行)都需创建自己的 run.md。捕获文件、清单、发现日志和变体表单应放入 harness.md 指定的 gitignored 文件夹中。评审委员会材料包应放在代码仓库之外,即位于会话的暂存盘或临时文件夹中。

项目的自身规则优先于本技能:例如其 AGENTS.md 中关于依赖项、开发服务器以及提交内容的规则。当运行需要某些被规则禁止或保留以供讨论的内容时,请在操作前询问用户。

流程

  • 全新 UI: 引导 → 探索 → 用户挑选 → 细化 → 评审委员会 → 批准参考 → 保留测试 → 通过项目的发布路径交付。
  • 现有 UI: 引导 → 评审委员会 → 批准 → 交付。当用户希望先看到可见的改动时,在评审委员会之前先进行细化。

根据请求命名的阶段进入流程;对于狭小的调整,直接从细化阶段进入。

阶段首先阅读
引导references/bootstrap.md,然后阅读 references/harness-contract.md 了解运行所需的每个能力
探索references/explore.md
细化references/refine.md,以及首次 UI 编辑前阅读 references/craft.md
评审委员会references/council.md
使用其他设计技能调用前阅读 references/integrations.md

评审委员会成员。 若运行将进入评审委员会阶段,请在开始时询问用户委员会由谁组成(每位成员的模型及其推理努力程度),除非用户已指定成员。建议来自不同供应商的成员。将成员记录在 run.md 中,并在整个运行中严格使用这些成员。如果某成员不可用,请如实告知;切勿替换。

批准参考截图。 只有用户的话语能批准一个屏幕;评分永远不能替代。将屏幕的捕获文件复制到 docs/design/references/,并在 DESIGN.md 的“参考截图”下列出它们,说明每张截图是哪个屏幕的参考。

保留测试。 在第一个参考截图获得批准后,由一个全新的代理根据本技能、项目文件及 harness 文档设计一个尚未被设计过的界面,并列出所有它不得不猜测的点。向用户展示结果。将每个猜测点修复到本应回答该问题的文件中,或将其记录在 run.md 中作为待解决问题。当用户已做出反应且每个猜测点都已修复或记录时,即完成。

记录反应

每当用户对设计做出反应时,无论处于哪个阶段:

  1. 在 DESIGN.md 的反应日志中为每个反应添加一行:日期(UTC)、界面和视口、对应的设计和捕获运行、用户的原文引用(需加引号)、类型、范围、状态设为 observed。
    • 类型: like(保留它)、dislike(更改它)或 defect(任务失败或发生故障;同时将其添加到发现日志中)。一个反应可以喜欢某一部分而讨厌另一部分;需分别指明各部分。尚未构建的功能不算反应:请将其列为 run.md 中的已知限制。
    • 范围 为用户所述的范围:此元素、此界面类型或全站范围。若用户未指定范围,则默认为元素级。切勿自行扩大范围。
    • 你为响应反应所做的更改应记录在发现日志中,而非该行中。
  2. 当用户以通用方式陈述某一反应时,将其提升为决策。当相同反应在第二个界面上再次出现时,询问该反应是否具有通用性,仅在用户确认后才提升。将该行标记为 promoted 并附上链接。
  3. 当某个反应与已有决策矛盾时,询问哪个优先,然后编辑或移除旧决策,并将失败的行标记为 superseded。

在以下情况时完成:每个反应都有一行记录,且每次提升都引用了用户的通用陈述或他们确认的“是”。

隐私

捕获应使用测试数据、种子数据或演示账户,绝不可使用用户自己的账户或真实人员的记录。任何显示个人数据或成人内容的信息不得放入评审委员会材料包、参考截图或提交中。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

相关技能