interface-craft

界面设计

使用此技能，让 UI 显得精心设计，而不让润色沦为装饰。

确定模式

• 构建：实现 UI 时添加恰当的设计细节。
• 润色：直接改进现有 UI，并说明影响最大的改动。
• 审查：未经要求不要编辑；提供简洁的发现，并附上文件和行号作为依据。

如果用户意图不明确，针对现有代码默认采用审查模式，针对新 UI 默认采用构建模式。

工作流

1. 确定界面类型：表单、按钮、导航、加载状态、空状态、内容展示、动效或平台外壳。
2. 阅读 references/interface-craft-rules.md，并仅加载相关章节。
3. 提出任何细节之前，先执行克制原则检查。
4. 在构建／润色模式下，在同类界面中实现最小且一致的改进。
5. 在审查模式下，按影响大小排列少数关键发现，覆盖所有要求的状态，然后给出最小化的实施计划。

防护原则

如果以下任一问题的答案是否定的，就跳过该细节：

• 它能帮助用户完成或理解任务吗？
• 它能保留键盘、屏幕阅读器、触控和减少动态效果偏好下的体验吗？
• 它符合产品现有的设计体系吗？
• 交互越频繁，效果是否越克制？
• 能否用可观察的方式描述这项改进？

输出格式

P0 — path/to/File.tsx:42 — ic-form-1
Issue: Label is visually present but not programmatically associated with the input.
Fix: connect label and input with htmlFor/id or wrap the input in the label.

Implementation plan:
1. Fix P0 accessibility and state blockers first.
2. Add loading/error/success/focus/reduced-motion tests or stories.
3. Apply the same pattern to sibling controls only after the first surface is verified.

审查发现应聚焦关键信息。优先提出 3 到 6 项重要改进，而非 20 条外观上的细枝末节。对于结账／支付界面，如果提示中涉及相关状态，需明确说明禁用、加载、重复提交、错误、成功、焦点、移动端触控目标和减少动态效果等状态。

不适用场景

• 如果请求的内容不是界面的构建／润色／审查，就不要用此技能来创造品牌形象、提取完整的设计体系，或认证正式的无障碍合规性。
• 如果没有查看相关代码、截图或交互状态，就不要提出文件级别的发现；应说明证据缺口，并给出检查计划。