用途
product-design 是产品设计流程中的“决策层”。它回答的是“界面应该做什么”，而不是“界面长什么样”。输入可以是需求简报、规格说明、设计稿、意图描述或现有 UI；输出是交互选择、操作语义、状态覆盖与韧性要求，并把后续的构建、验证和文案工作路由给相应的兄弟技能。
主要能力
该技能围绕五大支柱展开：
- 正确的交互：根据选择的形态挑选控件，保持选项可见且可逆，优先使用内联展开而非模态框，每个手势都要有控件替代方案，选择最小且连贯的干预方式。
- 操作命名与后果：命名操作的对象、范围与后果；先确定可逆性，再决定模式；不可逆操作需要复核、勾选或具名确认；只有在诚实的前提下才提供撤销。
- 状态覆盖：设计每一个可达状态，而不仅是数据填充状态。空状态要指明对象与首个操作；错误状态要解释并提供恢复路径；计时器在丢弃前要发出警告。
- 韧性：溢出、极端数据、本地化与 RTL、离线、网络失败都是需要设计的状态，每次数据获取都要落到某个状态中。
- 无障碍即任务完成：每个控件都有名称；主流程可用键盘完成并有可见焦点；已输入内容不重复要求输入；认证允许辅助工具；状态与后果可被理解，而不仅是被标注。
使用方式
技能根据用户的动词与产物解析出五种模式之一，然后加载对应参考文件（references/rules.md 在所有模式下都会加载）：
- shape（默认）：用于“设计这个流程”“这里该用什么控件”“这应该怎么工作”“这是正确的模式吗”等尚无确定 UI 的简报。
- spec：用于“为正确的交互写规格”“定义预期状态”，在构建前或构建中应用判断，并把构建路由给 ui-design。
- review：用于“审查这个流程的产品正确性”“这个 UX 决策有什么问题”“这是正确的交互吗”。
- action：用于“这个操作应该影响什么”“这个应该可撤销吗”“需要确认对话框吗”，或可逆性尚未确定时。
- harden：用于“让它更健壮”“这里会出什么问题”，以及错误、权限、离线、过期和破坏性路径。
工作流程为：分类请求模式 → 定位权威依据（用户约束、项目设计系统、AGENTS.md）→ 加载规则与模式参考文件 → 撰写内部简报 → 命名对象、范围、后果与可逆性 → 枚举可达状态并检查覆盖 → 输出带规则 ID 或标注覆盖缺口的结论 → 列出未解决的产品决策。输出长度随工作而定，不需要的章节可以省略。
适用场景
适合在产品交互决策阶段使用，例如确定某个操作是否可撤销、是否需要确认对话框、某个手势是否需要控件替代、某个流程有哪些可达状态、如何让流程更健壮等。也适合在构建前或构建中为交互写规格，或对已有流程做产品正确性审查。
限制
该技能不判断某个功能是否值得投入或是否符合产品方向，这属于开放的产品问题。它不构建或美化 UI、不做视觉方向、配色与字体，这些属于 ui-design。它不审计已构建结果（渲染质量、无障碍标记、键盘、布局、性能、React 或 Next 代码级 UX），这些属于 ui-design 的 Audit 模式。它不负责文案措辞、说服力或去除 AI 腔，这些属于 ghostwriter。它不负责动效、手势物理或深度排版，这些属于 ui-animation 与 typography-audit。它也不判断智能体功能是否赢得信任，这属于 ax-audit。review 模式针对的是流程而非产物，“审计这个组件”“检查我的 UI”“对这个页面做设计 QA”指向已构建标记，属于 ui-design 的 Audit 模式。