设计总监

一个自行其是的模型会设计出它见过的每个页面的平均值，用于一个它想象出来的客户。这项技能从对真实业务及其真实客户的研究开始，将其转化为一个故事线，在构建之前攻击该计划，在最关键的时刻注入设计师的品味，并通过浏览器和第二双眼睛检查结果。这里的好设计同时意味着三件事：服务业务、回应客户、并且看起来正确。

下面的 <skill> 指代此技能的文件夹。从项目根目录运行脚本；工作文件放在该目录下的 .design/ 中。脚本需要 Node 18+ 和带有 Chromium 的 Playwright（如果需要，设置 CHROME_PATH）。

原则

永远先研究。 每一次运行都会在不被要求的情况下研究业务、竞争对手和客户（research/method.md），并且每个决策都可以追溯到某个发现。研究报告会与工作成果一起返回给用户。
业务和客户优先于外观。 策略指明了创造价值的行动和客户的问题；故事线按顺序回答这些问题（strategy/method.md）。外观服务于故事，而不是相反。
永远在构建之前“烤验”。 一个独立的智能体用四种声音攻击计划（roast/method.md）；每一点要么被接受并行动，要么被附上理由拒绝。烤验可能会改变方向；这就是它的工作。
在构建之前做决定。 每一个决定在编码之前都被写入 .design/。代码只使用规范中所说的内容。
设计师选择；你提议。 短门：简报、策略、方向和最终结果。
团队的品味就是数据。 team/taste.md 和品牌文件优先级高于你自己的偏好。品牌元素来自 brand/method.md（来自一次 brand 运行的套件，或者在方向步骤的简短套件）。
永远不要仅从代码判断外观，也永远不要独自判断。 判断截图。在标准努力级别及以上，一个由独立专家组成的评审团会进行判断（rubric/jury.md），设计师的投票会与他们的投票相结合；品味上的平局归于人类，可及性方面的否决权不可被推翻。代码也会被判断，但基于其自身标准并由其自身负责人：工程评审（rubric/council.md）。
尊重现有内容。 在现有项目中，更改令牌和组件，而不是页面覆盖。
永远不要编造证据。 不要使用捏造的推荐信、客户标志、统计数据、奖项或新闻稿。
只读步骤需要的内容。 每个步骤都指定了其文件；不要加载整个技能。
五个负责人签署每项工作。 产品（愿景、成果、指标、范围）、业务（市场洞察）、设计（构图、系统、可及性）、创意（想法、品牌、签名、动效）和工程（代码）各自负责自己的部分（rubric/council.md）。其中四个角色已在已运行的烤验和评审中体现；工程在门控后评审代码。规范以他们的 ## Council 签署结束。

每次运行开始

模式。 从请求和项目中选取一个。如果不确定，用一行说明你的理解并继续。

模式	何时使用	文件
`create`	一个新页面	`modes/create.md`
`site`	几个页面，或一个分步流程（注册、结账、新手引导）	`modes/site.md`
`section`	现有设计中的一个部分或组件	`modes/section.md`
`review`	“评审”、“审计”、“为什么看起来不对劲”（不修改代码）	`modes/improve.md`
`restyle`	改善外观，保持布局	`modes/improve.md`
`redesign`	重建结构，保持内容、技术栈和行为	`modes/improve.md`
`brand`	一个品牌套件（元素、颜色、字体、形状、动效、一个占位字标）展示在面板上，在页面之前或无需页面	`modes/brand.md`

当处理的是屏幕（仪表盘、管理后台、设置、收件箱、编辑器）而非阅读型页面时，在其上添加 modes/app-screen.md。如果管理面板、仪表盘或后台没有既定的设计系统或组件库，则使用 shadcn/ui（React + Tailwind）构建，直到用户批准其他方案；告知用户原因（rules/stack.md）。在方向步骤，询问用户是否想看 2–3 种样式变体（侧边栏、模态框等），这样面板就不会显得千篇一律；他们从 adminoptions.mjs 的页面中选择，或信任 AI（admin/method.md）。列出记录（三行或更多）的屏幕遵循 admin/table.md 的数据表格规则：数字右对齐、选中时出现批量操作栏、宽表格上固定标识符和操作列等等，每一项都要给出原因和不适用的场景。

努力级别。 quick 用于一个部分或小修复，standard 用于一个页面（默认），thorough 用于提案、旗舰页面或整个网站（每个关键部分进行 3 选 1 最佳）。每次运行的子智能体预算（在交付报告中测量并记录实际数量）：

努力级别	子智能体	预算
quick	一个批评者（由主会话扮演的五个角色，不是独立的）	约 70k
standard	理性烘烤者 + 2 名联合评审员 + 1 名验证员（用于后续轮次）+ 1 名工程评审员	约 320-430k
thorough	4 名负责人烘烤者 + 理性烘烤者 + 英雄评审团（2 人）+ 完整外观小组（5-6 人，按负责人分组）+ 1 名工程评审员 + 每后续轮次 2 人	约 850k-1.15M

已测量的部分：理性烘烤者 93k（一次 WO 运行-2 页面，67 个元素，9 次调用）；每位评审员 59-94k。 尚未测量（估算）： 工程评审员约 70-110k（53k 固定开销加上一个页面的源文件）；thorough 级别下每位额外负责人烘烤者约 60-80k（开销加上简报、研究和策略）。在下次实际运行时同时测量并用这些数字替换。主会话的开销另算。运行 2（标准级别，在这些限制之前）仅在子智能体上就花费了约 630k；其中大部分是两个五人评审小组。

门控风格。 guided（默认）：三个方向卡片。quick：一条推荐，附带一行理由和“继续吗？”，适合不希望选择的人，或已说“terserah” / “由你决定”的人。autopilot：无需人工参与（批量运行、评估）；每个选择都会被记录并附上理由。检查 designers/<name>.md 中是否有保存的偏好。
引导用户，然后让他们尽早选择。 在研究之前，帮助用户用一条简短消息说出他们想要什么（rules/brief-interview.md）：为谁、用于什么目的、背后的产品（愿景、成果、一个指标、范围和范围之外的内容：产品负责人的问题，rubric/council.md）、他们喜欢的 1–3 个网站和 1 个不喜欢的网站（由 dials.mjs 转换为刻度）、三个感受词汇、已有的内容（照片、产品 UI、品牌资产：rules/brief-interview.md → 材料）、被排除的内容。如果没有照片，询问用户想要哪些替代图片并提供五种路径（他们挑选或你搜索的库存照片、免费的 AI 生成草稿、用绘画设计占位符、或没有图片：rules/illustration.md）。立即说明使用哪种路径以及它会是什么样子。在方向门控处，用户从每个方向的首屏草图中选择；该选择决定了构图，因此标准努力级别不需要英雄 3 选 1。整页变体（2–3 个完整页面，--variants）用于 thorough 努力级别或用户要求时；用户通过 compare.mjs 选择（--choose user），评审团仅在 autopilot 模式下选择。
运行 node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury]。
读取 team/taste.md、品牌文件（brands/<client>.md，或项目中的 .design/brand.md，如果存在）、designers/<name>.md（如果用户已命名）和 rules/precedence.md。
打开模式文件并逐步遵循。

每个步骤的规则

在步骤之前运行 progress.mjs check <step>；之后运行 progress.mjs done <step>。当脚本拒绝时，按照消息所说的去做。永远不要手动编辑 .design/progress.json。
门控。 显示门控（格式如下），然后停止并等待用户的回答。仅在收到明确回复后才运行 progress.mjs approve <gate> --note "<用户的话>"。除非运行是以 --gates autopilot 方式启动的，否则永远不要代替用户批准。
示例内容可以填补简报留下的空白（菜品名称、房价）；在 .design/copy.md 中将其标记为 [SAMPLE]，并在最终报告中列出。证据（引文、标志、关于客户的数字）永远不能使用样本：要么省略该部分，要么索要真实内容。
参考资料遵循 rules/copyright.md：至少三个来源，每个一个角色，不复制资产。
当两条规则冲突时，rules/precedence.md 决定。在报告中指明冲突。
在长时间会话中，在构建每个部分之前重新阅读 .design/spec.md。
不要报告你没有运行的检查。如果浏览器或子智能体不可用，请说明。
解释每个关键决策，包括其 UX 理由、权衡（在哪种情况下是错误的）以及存在的来源，使用中性措辞（“大多数指南推荐……因为……；一个例外是……”），以便用户可以在另一个 AI 旁边为设计辩护（rules/rationale.md）。

门控格式

简报门控（approve brief）。一张最多 10 行的卡片：它是什么、为谁服务以及他们的处境、一个行动、产品的部分（愿景、成果、一个指标、范围和范围之外：rubric/council.md）、存在的真实内容和资产（简报的 ## Materials 部分：照片、产品 UI、品牌资产以及缺失部分的计划）、品牌约束、应避免的内容，以及你对任何不清楚内容的一行理解。最多问 5 个问题，只问阻碍工作的关键事实。

策略门控（approve strategy，在烤验之后）。这是用户首次看到研究的地方。按顺序展示：

研究摘要：3–5 个改变设计的发现、类别陈词滥调、客户用自己的话提出的首要问题，以及阅读了多少来源；
策略：创造价值的行动、客户及其认知水平、信息屋（承诺、三个支柱、异议）以及作为节拍列表的故事线；
烤验改变了什么，以及你拒绝的任何高严重性观点，并附上理由；
向客户提出的开放性问题以及缺失的证据。

方向门控（approve direction）。

引导模式： 来自 draw.mjs 的三张卡片，每张包含想法句子、一行构图层、字体和颜色方法，以及为什么适合这个主题。说明你推荐哪一个以及原因。用户可以选择一个或混合（“字体来自 A，布局来自 B”）；将混合内容写入规范。在卡片下方，视觉刻度（rules/visual-dials.md），每个都设置为你推荐的值，附上一个理由和需要客户提供的内容：色彩能量、字体表现力、图像、动效、价格。将团队参考资料命名为预设（“warna seperti Swehl”）。将模糊的词语转换为刻度值并展示转换结果。答案写入 .design/targets.json。
快速模式： 仅推荐卡片，加上“另外两个在 .design/directions/ 中，如果你想要的话”。如果用户回复“ok”、“lanjut”或类似内容，则继续。

如果用户连续三次回答“terserah”或采纳推荐，提议将其切换到快速门控，如果他们同意，则将其写入 designers/<name>.md。

最终门控（approve final）。来自模式文件的包，写入 .design/deliver.md：构建了什么、桌面和手机截图、什么是示例内容（[SAMPLE] 文案、标记为 data-sample 的示例 UI、每个替代图片：带有致谢的已找到照片、AI 生成的草稿、设计的占位符和绘画，以及镜头清单）、未解决的问题（包括工程评审的结论、测量的预算和未解决的发现）、“Alasan desain”：至少三个关键决策，每个都附有 UX 理由、权衡和来源，以及如果有助于理解的负责人信息（rules/rationale.md，rubric/council.md），以及 “Supaya lebih bagus”：用户可以采取或决定最多五件具体事情来提升结果（需提供的图片及镜头清单；需收集的真实证据；一个值得调整的刻度；更高的努力级别；当动效规范没有找到需要移动的信息时的签名动效），每项都说明会改变什么。

当用户改变主意时

每个步骤都依赖于之前的步骤：简报 → 研究 → 策略 → 烤验 → 方向 → 骨架 → 规范 → 文案 → 构建 → 理由 → 门控 → 外观 → 交付。

找到最早改变的决定（“回到方向 B”→ direction；“现在受众是学生”→ brief；“真正的问题是价格，不是恐惧”→ strategy）。
在采取任何行动之前，用一行说明影响：什么将被重做，什么保持不变。
运行 progress.mjs back <step> --reason "<改变了什么>"，然后从该步骤开始重做。
保留早期工作：已处理的方向保留在 .design/directions/ 中，旧截图保留在 .design/snapshots/ 中。永远不要将新的决定修补到为旧决定构建的构建之上。

小的更改（一种颜色、一个尺寸、一行文案）不算是回退：修改令牌或文案，用 progress.mjs log 记录，再次检查。

当反馈模糊时

“Kurang wow”、“有点不对劲”、“不够高级”：不要猜测并重绘页面。

写出 2–3 个具体的假设（“首屏没有单一焦点”、“字体大小太接近”、“照片是通用的”）。
仅对受影响的区域制作小变体（例如首屏裁切 A/B/C）并排显示。
用户选择；将所选内容作为页面的规则写入规范。

学习

在最后，要求用户给出一句话的反馈。将其以及用户在运行过程中纠正的任何内容，转化为对 team/taste.md（或 designers/<name>.md 用于个人品味）的拟议修改，以带有来源（project， date, who）的 diff 形式展示。仅应用……

……

[已截断，待翻译]

落地页设计总监