product-design

产品设计

确定界面应实现什么，再决定由谁构建和验证：选择合适的交互方式，明确范围和后果，并覆盖顺利路径之外的现实情况。

• **是：**决策层。从简报、规格说明、模型图、意图或现有 UI 出发：选择交互方式和控件，明确每项操作的对象、范围和后果，确定可逆性及其所需的防护措施，列举所有可达状态，设定韧性预期，并要求将无障碍性视为任务完成条件。它负责做出决策，然后将构建、验证和措辞工作分派出去。
• 不是：
  • 判断某项功能是否值得投入或是否适合产品：这超出范围；应将其表述为一个待解决的产品问题。
  • 构建或设计 UI 样式、视觉方向、调色板、字体：使用 ui-design。
  • 审核已构建的结果（渲染质量、无障碍标记、键盘操作、布局、性能、React 或 Next 代码层面的 UX，并给出是否发布的结论）：使用 ui-design 审核模式。
  • 文案措辞、说服性表达或去除 AI 腔：使用 ghostwriter。
  • 动效、手势物理效果或深度排版：使用 ui-animation、typography-audit。
  • 判断智能体功能是否值得信任：使用 ax-audit。

路由边界

product-design 负责操作语义、范围、可逆性和有争议的状态选择。ui-design 负责构建这些状态并设计其样式。ui-animation 负责时序、手势和经过测量的动效。常规情况下缺少加载或错误状态，应由 UI 构建环节处理；如果要用手势替代控件，则必须先做出产品决策，并提供无障碍替代方案，然后再确定其物理效果。

请求模式

行动前，先根据用户使用的动词和提供的材料确定一种模式，然后加载该模式的参考资料。所有模式都会加载 references/rules.md：每项发现都必须引用其中的规则 ID，而且在查阅规则注册表之前，不能断定某项决策没有规则约束。

模式	用户提出以下请求时选择	加载（以及 references/rules.md）
shape（默认）	“设计……的流程”、“这里该用什么控件”、“这应该如何运作”、“这是合适的模式吗”、尚未确定 UI 的简报	references/product-judgment.md、references/surfaces.md
spec	“为正确的交互编写规格说明”、“定义预期状态”、在构建前或构建期间应用判断	references/product-judgment.md、references/surfaces.md、references/naming-and-copy.md；将构建工作分派给 ui-design
review	“检查此流程的产品正确性”、“这个 UX 决策有什么问题”、“这是合适的交互吗”	references/interface-quality.md
action	“此操作应该影响什么”、“此操作应该可以撤销吗”、“我们需要确认对话框吗”，或可逆性尚未确定	references/naming-and-copy.md；将最终措辞交由 ghostwriter 处理
harden	“让它更有韧性”、“这里会出什么问题”、错误、权限、离线、过期和破坏性操作路径	references/surfaces.md、references/interface-quality.md、references/product-judgment.md

审核模式针对的是流程，而不是材料。“审核此组件”、“检查我的 UI”和“对这个页面进行设计 QA”指向已构建的标记，应使用 ui-design 审核模式。本技能的审核会判断流程背后的决策是否正确，并止步于决策层面。

模式可以串联：shape 接续 spec；review 接续 harden。当意图不明确时，使用动词所支持的最窄模式。URL、截图、路由或组件可用于确定范围，但不代表授权修改。

某项标准应由使用项目的 linter 强制执行，而非纳入此技能，这属于 codebase-architecture 的执行分级范畴。用户任务期间不会加载 evals/evals.json；它是任何修改此技能者使用的回归测试集。

工作流

Product design pass:
- [ ] Step 1: Classify the request into one mode
- [ ] Step 2: Locate authority (user constraints, project design system, AGENTS.md)
- [ ] Step 3: Load rules.md plus that mode's reference files
- [ ] Step 4: Write the internal brief (shape, spec, harden); stop and ask if job, outcome, or consequence is unfillable
- [ ] Step 5: Name object, scope, consequence, and reversibility for each action in scope (spec, action, review)
- [ ] Step 6: Enumerate reachable states and check coverage (shape, spec, harden)
- [ ] Step 7: Emit output with a rule ID or labeled coverage gap per finding or decision; route follow-on work to siblings
- [ ] Step 8: List unresolved product decisions

步骤 5 和 6 受模式范围限制，因为它们的引用依据是：纯 action 阶段没有可供枚举的状态矩阵，而 shape 阶段还没有可供命名的已构建操作。

输出长度应取决于实际工作，而非模板。一个已确定的决策只需简短回答；某个阶段不需要的部分就直接省略，不要为了填充而保留。

决策依据

冲突时按以下顺序处理，优先级从高到低：

1. 用户的明确目标和约束。
2. 经核实的用户与产品证据，以及系统的实际行为。
3. 项目规范性指导：AGENTS.md 或 CLAUDE.md、项目的设计系统、路由到的同级技能。
4. 同级技能的职责归属：进行路由，不要重复实现。
5. 本技能的标准（如下）。
6. 通用界面与平台规范（WCAG 2.2、NN/g、Apple HIG、Material、GOV.UK）；references/rules.md 会按规则引用这些规范。

当请求涉及多个职责方时，指出负责的技能并移交。

产品设计标准

五大支柱，每项均列出其在 references/rules.md 中的规则 ID，以及详细说明该项的参考资料。

• 恰当的交互。 根据选项的形态选择控件；让选项始终可见且可撤销；优先采用行内展开而非模态框；每种手势都应有对应的控件操作方式；选择最小且完整的干预方案。rule/control-matches-cardinality、rule/navigation-vs-action、rule/inline-before-modal、rule/no-nested-modals、rule/gesture-has-control-alternative、rule/smallest-intervention。详细说明：references/product-judgment.md。
• 操作命名与后果。 明确操作对象、范围和后果；先确定是否可撤销，再选择模式；不可逆操作应提供审核、检查或明确说明的确认步骤；仅在确实可行时提供撤销。rule/name-object-scope-consequence、rule/destructive-names-action、rule/destructive-proportional、rule/irreversible-action-safeguard、rule/undo-only-when-honest、rule/preserve-user-input。详细说明：references/naming-and-copy.md。
• 状态覆盖。 设计每种可达状态，而不只是内容已填充的状态：空状态应说明对象并提供首个操作；错误状态应解释问题并提供恢复方式；计时器应在丢弃内容前发出警告。rule/cover-reachable-states、rule/empty-state-action、rule/error-states-recovery、rule/loading-stable-labels、rule/time-limit-adjustable。详细说明：references/surfaces.md。
• 韧性。 溢出、极端数据、本地化与 RTL、离线和网络故障都应作为设计状态处理；每次获取数据都应进入其中一种状态。与 rule/cover-reachable-states 共用规则：这是将同一要求应用于不利输入。详细说明：references/surfaces.md > 韧性。构建后的 UI 是否实际呈现这些状态，由 ui-design 的 Audit 模式检查。
• 以完成任务为目标的无障碍设计。 每个控件都有名称；主要流程可通过键盘完成，并提供可见焦点；用户已输入的内容无需重复输入；身份验证允许用户寻求协助；状态与后果应清晰易懂，而不仅仅是贴上标签。rule/accessible-name-required、rule/keyboard-complete-flow、rule/no-custom-focus-bypass、rule/no-redundant-entry、rule/auth-allows-assistance。详细说明：references/interface-quality.md。标记和目标尺寸检查应路由至 ui-design 的 Audit 模式。

评审输出

在评审和加固模式下，首先按对用户的影响（P0 到 P3）排序列出发现项；每项均应包含位置、验证状态、规则 ID、对用户的影响，以及由负责该项的技能提供的最小具体修复方案。发现项应聚焦决策层面；逐行代码或框架层面的修复属于 ui-design 的 Audit 模式输出。评分标准与发现项格式：references/interface-quality.md > 严重性评分标准。

易踩坑

• 对可撤销的操作（归档、从列表中移除、取消订阅）弹出确认对话框，会让用户养成直接点击确认的习惯，因此到了真正重要的确认——永久删除时，他们也会条件反射般地点击确认。这就是 NN/g 提出的“狼来了”效应。直接执行操作并提供撤销选项（rule/destructive-proportional）。
• 把撤销提示作为唯一的恢复途径：它大约 5 秒后就会消失，而对象也已不复存在。要么让对象仍可恢复（回收站、归档），要么让操作不可逆并设置防护措施。否则就不要称之为撤销（rule/undo-only-when-honest，WCAG 2.2.1）。
• 仅支持滑动删除或拖动排序，没有等效的按钮或菜单选项，既直接违反 WCAG 2.5.1 和 2.5.7，也会让其他所有人都无从发现这些操作。在将手势交给 ui-animation 处理物理效果之前，先明确替代方案（rule/gesture-has-control-alternative）。
• 使用 3 个固定宽度英文标签的分段控件：W3C 指出，翻译后，长度不足 10 个字符的字符串会增长 200% 到 300%，因此“Day / Week / Month”翻译成德语后会变成换行或被裁切的一团乱麻。在规范中决定好换行或堆叠行为。
• 将“尚无项目，请创建项目”空状态复用于筛选结果为空的列表。由于用户搜索的项目其实还在筛选条件之外，他们会创建重复项目。3 种空状态，3 种设计（references/surfaces.md）。
• 结账或注册流程要求用户再次填写两步前已经输入过的信息（例如，填写完收货地址后又要填写账单地址，创建账户后又要填写电子邮箱），这违反 WCAG 3.3.7，也会导致移动端用户在这一步离开（rule/no-redundant-entry）。
• 给出逐行修复建议（一个属性、一个 hook、一个 className），而不是做出决策。这样的建议缺少可验证它的渲染检查，而且原本应由它体现的产品决策也没有明确说明。将其交给 ui-design 审核模式处理。
• 引用听起来合理但实际并不存在的规则 ID（rule/clear-labels）。该引用无法解析，因此无法将此发现与 ui-design 审核结果去重，也无法追溯到规则。请记录为覆盖缺口。

相关技能

• ui-design：视觉方向，以及将已确定的交互构建成代码；其审核模式会检查已构建结果、渲染质量和无障碍标记，并给出是否可发布的结论。
• ghostwriter：为名称、错误提示、空状态和加载状态撰写准确文案，并依据此技能在 references/rules.md 中维护的文案规则 ID 进行编写。
• ui-animation：两个状态之间的过渡（时长、缓动、弹簧、手势物理效果）。此技能会确定手势是否取代控件，以及替代方案是什么；该技能负责实现动画效果。
• ax-audit：已构建的 Agentic 功能是否值得信任；此技能会决定它首先应执行什么操作。
• typography-audit：深入排查排版问题。