shape

shape skill 概览

shape skill 是做什么的

shape skill 是一套以规划优先为核心的 UX/UI 工作流，用来在写任何代码之前先把功能定义清楚。它不会一上来就直接产出布局或组件，而是先进行结构化的需求发现访谈，再把回答整理成一份设计 brief。正因为如此，当团队大致知道要做什么，但还没有明确用户目标、约束条件、状态设计、边界情况或实现方向时，shape skill 会特别有用。

谁适合安装 shape skill

shape skill 最适合有产品思维的构建者、设计师、前端工程师，以及依赖 AI 协作、希望在原型阶段之前先把关键决策做扎实的团队。尤其是在 shape for UI Design 这类场景里，如果一个功能本身还很模糊——比如新流程、dashboard、表单、onboarding、settings，或任何“直接生成一个 UI”很可能抓不住用户真实任务的界面——它就更值得用。

为什么很多人会选 shape，而不是一个通用 prompt

普通 prompt 往往会直接给你 mockup 或组件想法。shape 则是有意把节奏放慢。它的核心差异在于：先强制补齐上下文，再生成一份后续可交接给实现类 skill 的设计 brief。仓库对它的边界写得很清楚：这是设计规划工具，不是写代码的工具。如果你想减少浅层 UI 建议，换来更站得住脚的产品决策，这种边界反而很有价值。

如何使用 shape skill

安装前提与必需的依赖步骤

通过你的 skills 工作流，从 pbakaus/impeccable 仓库安装这个 skill，例如：
npx skills add pbakaus/impeccable --skill shape

采用 shape skill 时最关键的一点，是 SKILL.md 里写明的前置要求：shape requires /impeccable first。也就是说，必须先调用 /impeccable，遵循它的 Context Gathering Protocol；如果当前还没有任何设计上下文，就要先运行 /impeccable teach，之后再使用 shape skill。如果跳过这一步，就等于脱离了它原本设计的工作流来使用。

shape skill 要怎样的输入，效果才会好

参数提示虽然是 [feature to shape]，但只给一行功能名，通常远远不够。更高质量的 shape skill 使用方式，最好一开始就提供：

• 功能目标
• 目标用户或角色
• 当前工作流或痛点
• 成功标准
• 平台、权限、合规、现有 design system 等硬约束
• 已知边界情况或明确不做的内容

弱输入示例：Shape a notifications page.
更强的输入示例：Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.

实际工作流，以及优先该读哪些文件

先读 SKILL.md，并把它当作这项能力的操作契约。当前这个仓库快照里只暴露了这个文件，所以大部分价值都来自于是否按它规定的顺序来用：

1. 先通过 /impeccable 收集设计上下文。
2. 在规划阶段使用 shape，而不是实现阶段。
3. 让它主导发现式访谈。
4. 把访谈结果整理成设计 brief。
5. 再把这份 brief 交给 /impeccable craft、/impeccable，或其他实现工作流。

这一点很重要，因为 shape skill 的优化目标，是在 UI 工作开始之前减少拍脑袋决策，而不是一次性生成精致完整的页面。

能让 shape skill 输出更好的提问模式

想更有效地调用 shape skill，最好在提问时明确要求它先访谈，再输出最终产物。推荐结构包括：

• 要 shape 的功能
• 主要用户是谁
• 当前问题是什么
• 必须满足的约束
• 你希望这份 brief 帮你定下哪些关键决策

示例：
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.

这种方式比“为 X 设计一个 UI”更有效，因为它给了 skill 足够空间，先通过澄清问题来收敛方向，而不是过早定型。

shape skill 常见问题

shape skill 是拿来写代码，还是做规划？

shape skill 是做规划的。仓库里已经明确说明：它不写代码。它的输出是一份指导后续实现的设计 brief。如果你想立刻拿到代码，那它不是合适的起点；如果你想先把产品和 UI 决策做得更稳，它就很适合。

什么情况下，shape 比普通 prompting 更合适？

当功能定义还不完整、风险较高、直接面向用户，或者很可能涉及复杂状态与取舍时，就应该用 shape。如果只是做一个随手用的 mockup，通用 prompt 可能更快；但如果你需要围绕工作流、用户需求、约束条件和交接质量进行推理，shape 会更合适。

shape skill 适合新手吗？

适合，但有一个前提：新手也必须掌握足够的产品上下文，才能把发现式访谈回答好。这个 skill 能提供结构，但它不能替你凭空发明用户、约束或成功指标。如果你刚接触 UX 规划，它这种以访谈驱动的方式其实反而有帮助，因为它会把那些你本来就应该先想清楚的问题提前暴露出来。

什么情况下不该把 shape 用在 UI Design 上？

当问题已经被定义得非常完整、你只需要做一个很小的视觉微调，或者任务本质上是纯技术问题而不是用户交互问题时，就可以跳过 shape for UI Design。另外，如果你不愿意执行前置的上下文收集步骤，它也不适合你，因为这个 skill 本身就是建立在那层基础之上的。

如何把 shape skill 用得更好

给 shape skill 更好的规划输入

影响效果最大的杠杆，就是输入质量。对 shape 来说，好的输入绝不只是功能名，还应包含用户类型、任务频率、失败成本、现有模式、业务规则，以及哪些内容应该明确排除在范围外。skill 当然还是会继续访谈你，但起始上下文越完整，最终 brief 就越锐利，也越不容易落入泛泛而谈的建议。

避开最常见的失败模式：过早给出解决方案

仓库里最强的一条提醒，就是不要太早做设计决策。shape skill 最常见的误用之一，是在用户问题还没厘清之前，就直接要求 screens、cards、tabs 或具体 layout。如果你发现对话太早跳到界面模式上，应该主动拉回来：先追问未被满足的用户需求、任务流程、状态设计、取舍关系和约束条件。

迭代的重点应该是设计 brief，不只是 prompt

完成第一轮之后，优化方向应该是继续打磨 brief，去挑战那些仍然不清晰的决策：

• 哪个用户目标是第一优先？
• 还有哪些状态没覆盖到？
• 哪些假设需要验证？
• 哪些内容是 v1 明确不做的？
• 哪些地方会让实现阶段产生歧义？

和反复要求“给我一个更好的 UI”相比，这种迭代方式对提升 shape skill 的使用质量更有效。

让 shape skill 与下游执行串起来

想真正提升 shape install 的实际价值，最实用的方式是把它当作链路的第一阶段。先用 shape 产出设计 brief，再把这份 brief 传给 /impeccable craft 或其他实现类 skill。你的交接产物越清晰，后续代码生成或设计生成就越不容易偏离用户需求，陷入那种“看起来像那么回事、其实很弱”的 UI。