specify

Specify — 为构建阶段打包设计

概述

此技能为负责构建的人员打包一份已获批准的设计：工程团队或编码 Agent。交接内容就是项目自身的产出物。设计简报说明产品的用途；线框图说明每个屏幕包含什么；用户旅程、信息架构和蓝图说明屏幕如何连接，以及背后运行着什么；状态清单、无障碍文档和衡量框架说明设计在非理想路径下如何表现，以及如何评估其成效。这些产出物不会被重新描述。此技能会在它们前面写一页内容，说明产品是什么、包中包含什么、各部分如何配合，以及哪些事项留给构建者处理。

不涉及视觉设计：除用户旅程中的交互规范所述内容外，交付包不包含颜色、字体、间距或动效。技术栈由构建者选择。

---

技能系列

如果项目制作了以下产出物，它们就会随项目一起纳入交付包：

• /strategize：设计简报。始终纳入交付包；入口页的第一段取自该简报。
• /wireframe：全页线框图，以及存在时的原型视图。始终纳入交付包；用户旅程中提及的每个屏幕都必须有对应线框图。
• /journey：用户旅程图及其交互规范。
• /organize：信息架构。
• /blueprint：服务蓝图。
• /fortify：状态清单和边缘案例目录。
• /include：屏幕阅读器流程文档、键盘导航图和修复计划。
• /measure：衡量框架。
• /articulate：文案集；当线框图之外还有文案时使用（例如错误消息清单、语气框架）。
• /transpose 和 /localize：平台适配规范、跨设备用户旅程图、市场需求矩阵和文化适配简报；适用于项目拓展到新平台或新市场的情况。
• /evaluate：其发现必须在打包前处理完毕；未解决的关键发现意味着设计尚未准备就绪。
• /present：演示文稿。本技能不会制作演示文稿；如果构建需要向相关人员进行审批，就将交付包作为素材交给 /present。
• /philosopher：一种跨领域的认知模式。当就绪状态屡次不达标且无人能说清原因时，或各部分的配合图显示设计掩盖了衔接问题时，使用此技能。

---

就绪条件

只有满足以下所有条件时，才能打包：

• 设计简报已完成并获批准。
• 线框图已达到全页阶段，或已有原型视图，并且已获批准。只有缩略图的构想板尚未就绪。
• 如果存在用户旅程，其中提及的每个屏幕都有线框图。
• 评估中没有未解决的关键发现。
• 在宿主应用中，审批以宿主应用的状态为准；其他情况下，以设计师在对话中的确认作为依据。

如果条件未满足，用一两句话说明缺少什么，并提出解决该问题的步骤：将设计简报交给 /strategize，将缺失的屏幕交给 /wireframe，将未解决的关键发现交给负责修复它的技能。条件满足前，绝不要提议打包。

---

道德检查

打包前，根据 Intent 反模式目录检查设计：预先勾选同意框、确认羞辱、伪造紧迫感、选项不对称、成瘾机制，以及其他反模式。检查结果作为一条记录写入决策日志：列出可能适用于此设计的每种模式，并用设计术语说明设计如何处理它；不要写目录代码，也不要声称设计已通过审核。不会有单独的道德检查材料随包交付；日志会随包交给构建者，让其知道同意框是有意保持未勾选状态的。

如果设计无法从用户角度为某种模式提供合理解释，就不能打包。与设计师沟通此事，并将设计退回负责该屏幕的技能。

软件包中包含的内容

始终包含：

• 设计简报。
• 全页面层级的线框图，以及在存在原型视图时包含该视图。

如果项目制作了以下内容，则应包含在软件包中；判断规则是：凡是项目制作且说明了要构建什么的内容，都属于软件包：

• 服务蓝图。
• 用户旅程图。
• 信息架构。
• 状态清单和边缘案例目录。
• 屏幕阅读器流程文档、键盘导航地图和修复计划。
• 衡量框架。
• 文案稿（如果线框图承载的内容之外还有文案）。
• 平台适配规范和跨设备旅程图、市场需求矩阵以及文化适配简报。
• 决策日志，其中包含伦理审查结果。

绝不包含：视觉设计。除旅程的交互规范所述内容外，不包含颜色、字体、间距或动效。技术栈由构建者选择。

文案和标签置于线框图中，按规则，线框图承载真实内容；除非 /articulate 制作了自己的文件，否则其工作无需单独成文。

---

入口页面

此技能编写的唯一内容。放在软件包目录根目录下的 README.md，以便编码 Agent 首先阅读。标题写明产品和变更。

# [Product and change]

[One paragraph: the product, the change, who it is for, from the brief.]

## Contents

| Artifact | Path | What it holds |
|---|---|---|
| Brief | ../brief-<topic>.md | … |

## How the pieces fit

| Screen | Wireframe | Journey step | IA node | Blueprint touchpoint | States | Copy |
|---|---|---|---|---|---|---|

## Left to the builder

- Visual design: color, type, spacing, motion beyond the journey's interaction specification
- Technology
- [anything the design leaves open on purpose]

## Open questions

- [a plain question] (the artifact that holds the detail)

内容简介。 用一段话说明产品、变更及其目标用户，内容取自简报。

目录。 列出每项产物、相对于入口页面的路径，以及一句话说明其内容，并按阅读顺序排列：先读简报，再读各类图谱，然后是线框图，接着是加固和需求文档，最后是决策日志。此表是软件包的快照：准确列出此次交接依据的内容。

各部分如何配合。 每个屏幕占一行：线框图页面、对应的旅程步骤、所属的信息架构节点、背后的蓝图触点、绘制的状态，以及文案不在页面中时的存放位置。每行都要说明屏幕的用途。这是编码 Agent 最需要、但任何一项产物都没有提供的地图。

留给构建者的事项。 视觉设计、技术，以及设计有意留待决定的任何事项，逐项列出。不要把设计本该确定的内容留在这里：缺少状态意味着未达到就绪要求，不是构建者的选择。

待解决问题。 列出影响构建的产物中尚未解决的问题；每项都写成简洁的问题，并指向包含详细信息的产物。只列与项目有关的问题。

此页面不设叙述者：不署名，不说明如何整理完成，不声明设计已获批准，也不设所有权信息块。页面绝不添加按屏幕划分的章节；如果某个屏幕需要的内容超过其所在行，应放在线框图或旅程中。

---

格式

在项目中创建名为 handoff 的目录；如果项目有多个交接包，则命名为 handoff-<topic>，并将入口页面放在其中。各项产物留在相关技能写入它们的位置，入口页面通过相对路径引用每项产物。不复制任何内容：通过读取工具制作的副本可能会在达到工具限制后静默截断，而线框图的两份副本也会逐渐不一致。目录表就是快照。将入口页面的路径交给编码 Agent，由其按引用查找内容。

软件包打包后如需更改设计，应在对话中说明，并提出重新打包；重新打包会重写入口页面。不要在旧页面中写入任何内容。在宿主应用中，由宿主决定目录的存放位置，也可以从自身存储中打包被引用的产物。

---

语气与方法

意图优先于罗列。 地图中的每一行都说明屏幕的用途，而不只是它包含什么。“浏览：地图是主页，因为简报将地理位置定为产品的基本单位”是一行；“浏览：一张地图、一个列表、一个标签栏”则是在罗列。

这就是该技能在对话中的表达方式。交付内容没有叙述者：不使用第一人称，没有署名，没有关于文档本身的说明，没有讲述它是如何制作的，也不提设计师或团队；对其中的主张不加标记或图例。内容从第一个章节开始。主张仍须注明来源，可用方括号或脚注，不附图例；团队的任何工作都不会成为句子的主语（例如“简报否决了”“评审发现了”）。请求决定范围：涵盖会影响决策的情况，省略请求未要求的章节，并让每项事实都有一个归属位置，这样一项发现只描述一次，后续章节则用标题指代它。被删减章节独有的事实应移至其归属位置，绝不能丢弃。精简内容时，绝不删除构建者需要设定的值：时间、尺寸、阈值或字符串。每个值只写一次，并记录其原因；交付内容中不得称任何值尚未确定、待议或未经测试；未解决的问题只保留只有设计师才能回答的问题。去掉叙述者不会删减内容：交付前，请检查请求中提到的每个条件是否已在交付内容中作答，或列入未解决问题。决策日志只记录可能被重新审视的决策，每项决策单独一条：以注明日期、说明决策的标题开头，随后依次写明“决定者”“原因”“否决的选项”和“依据”，每项各用一个句子；文件名、格式和单条字符串都不是决策。随交付内容附上的回复只需几句话：文件所在位置、唯一一个回答后即可推进下一步的问题，并提供简短到足以直接选择的选项、设计师最可能推翻的唯一默认值、请求范围内交付内容未涵盖的事项，以及下一步由谁负责。回复绝不复述交付内容、不增加第二个默认值、不指向日志，也不按负责人重新整理发现。使用朴素的陈述句，不要用引入背景的开场白，也不要用引出列表的计数。/articulate 中的写作规则适用于你写的所有内容。

---

范围界限

此技能会：

• 检查是否已准备就绪，并说明缺少什么
• 执行伦理检查并记录结果
• 收集项目资料
• 编写入口页

此技能不会：

• 编写自己的规格说明（交接内容就是这些资料）
• 做出设计决策（这是设计师的工作）
• 编写代码或选择技术
• 定义成功指标（/measure）
• 评估 UX 质量（/evaluate）
• 制作演示文稿（/present）
• 填补设计中的空白（空白意味着未准备就绪或存在未解决的问题）

---

何时使用此技能

在以下情况下触发 Specify：

• “准备交接”或“编写交接内容”：设计已获批准，需要有人来构建
• “为构建打包”
• “编码 Agent 需要什么？”
• “现在可以开始构建了吗？”：检查是否已准备就绪，并说明缺少什么