用途
draft-experience 是一个产品体验设计技能，用于在任何人规划如何构建之前，先把一个功能塑造成产品形态。它扮演项目经理角色，与用户协作，由用户做决定。输出是产品是什么——一个人获得的结果——并且恰好停在问题变成“如何构建”的地方。评判标准是：某人能否在没有任何说明的情况下使用第一级阶梯，以及交付的形态是否让技术计划变得更小。
主要能力
- 一句话定义：用一个人的话，一句话说明谁、做什么、得到什么。
- 用例阶梯：按最小请求优先排列的编号用例表，每一级都是一个人端到端完成并获得结果的事。
- 第一级完整描述：逐步说明一个人做什么、每步看到什么、默认发生什么、永远不必决定什么、空状态说什么，以及离线、第二设备、出错时的行为。
- 隐藏与揭示：功能中第一级不展示的每项能力，以及一个人获得它的时刻（菜单、快捷键、第二次使用、展开状态）。
- 有意不做：每项有意不做的内容，附原因和它本会为谁服务。
- 开放产品问题：每个问题一个决策，说明选择是什么、每个选项对用户意味着什么、成本是什么，以及推荐。
使用方式
输入参数命名主题（例如 /draft-experience tasks），可以是功能、缺陷或提案。docs/<feature>/ 是项目的规划文件夹。
读取 docs/<feature>/notes/*（如有）——高层产品对话的笔记，通常是意图。读取项目对当前可用功能的描述（如有）——包括部分完成的内容。读取任何倡议路线图和有意推迟工作的记录。查看产品——阅读足够的代码和用户指南，了解今天一个人实际看到什么。读取项目的设计指导（如有）。
写作前询问用户：他们想要这个成为什么、首先为谁服务、以及任何他们已知的在内或在外。一次一个问题，每个都附推荐。
输出为 docs/<feature>/EXPERIENCE.rev1.md，包含六个部分，按顺序：一句话、阶梯、第一级完整描述、隐藏与揭示、有意不做、开放产品问题。
评审轮次：EXPERIENCE.revN.md 由 review-doc 评审，生成 EXPERIENCE.revN.notes.md。写 rev(N+1) 前，在“Responses to revN notes”部分明确回答每个发现：已修复（及如何）、不同意（及原因——用户裁决）、或需要用户决策。绝不静默丢弃。每轮关闭后提交每个 rev 及其笔记。用户签字后，用 finalize-doc 写 docs/<feature>/EXPERIENCE.final.md。
小模式：当主题是缺陷、小改进或关于已存在事物的疑问时，在对话中回答：一句话、它位于现有阶梯的哪一级、一个人现在能做什么之前不能做的、以及一两个开放问题。仅在用户要求时写文件，或如果答案结果是一个披着缺陷外衣的功能。
适用场景
- 在规划技术实现之前塑造功能的产品形态。
- 检查已提出的工作：读一个计划、路线图、拉取请求或缺陷报告，问：一句话是什么，工作是否真正交付它？这是哪一级，是否有更小的一级被跳过？其中什么仅因系统支持而存在？是否已有办法做这个？它做了哪个属于用户的决策？
- 以发现和建议的形式在对话中报告，不编辑别人的计划。
限制
- 绝不假设或替用户做产品决策。推荐，附理由和每个选项对用户的成本；用户决定。
- 停留在机制之上。读代码是为了发现已存在什么和今天一个人能做什么——绝不是为了设计实现。
- 不包含模式、模块、API、里程碑。
- 没有能力仅因系统拥有它而被证明合理：形态中每个元素都追溯到阶梯中的某物。
- 草稿完成后告诉用户可供评审——不要开始规划它，不要在同一会话中未经要求就写设计或路线图。
- 除非被要求，否则不推送。
- 本地化是形态，不是润色。如果产品以多种语言发布，提议的每个标签在所有语言中都存在。
- 性能是形态。如果一级不会立即回答，那是体验的一部分，属于文档。
- 可访问性是产品质量，不是后续步骤——键盘操作、焦点、对比度，以及不依赖颜色 alone 的含义。
- 诚实对待已存在的事物。部分完成不是完成。
暂未提供
该技能的收费、价格、平台支持、具体效果等事实暂未提供。