Decision 是一个面向 UX 与架构决策记录与追溯的技能。它的核心目标是帮助未来的设计师和工程师理解“为什么”，而不制造文档表演。
用途 该技能适用于需要回答或保存设计决策理由的场景，例如当设计师询问某个设计为什么采用某种方式、某个选择是否值得记录，或需要记录为何扩展了现有组件而非创建新组件时。也可用于判断某个决策是否应形成持久记录。
主要能力 在回答“为什么”时，Decision 会搜索可用的决策记录、研究、需求、issue/PR 历史、设计系统文档、实现历史，以及最小相关的 .ux/ 上下文。它会区分四类信息：有文档记录的理由；被产物强力支持的理由；合理推断；缺失或有冲突的理由。它明确指出，当前行为只能证明存在什么，不能证明为什么选择它，禁止在缺乏依据时编造看似合理的历史解释。
在做出新决策时，Decision 会判断该选择是否值得建立持久记录。值得记录的情形包括：引入或改变共享交互或系统模式；具有可访问性、技术、政策、隐私或运营方面的实际后果；以非显而易见的原因拒绝了显而易见的替代方案；影响多个团队或旅程；难以逆转；日后很可能被质疑。常规的布局、文案和样式改动通常不需要决策记录。
该技能还会在重要决策后检查意图影响：是否明确改变了产品存在的原因、预期结果、主要受影响人群、范围、非目标、重要约束或成功定义。如果确实改变，建议同步更新 INTENT.md，并保留导致该变化的证据或决策。它强调不要仅因实现变化就重写意图，也不要仅从代码推断战略转变。
使用方式 若项目已有 ADR、RFC、设计决策或文档惯例，应沿用该体系，不引入竞争格式。若没有，则采用轻量结构：决策、状态、上下文与证据、考虑过的选项、决策与理由、后果、开放问题、相关产物。应保留决策当时实际已知的信息，不要事后将假设改写为证据。输出时，如果用户只需要回答“为什么”，就直接回答；只有决策足够重要时才创建或建议持久记录。如果决策实质性改变了产品意图，应明确说明，并在用户要求将决策保存到项目上下文时纳入意图更新。
适用场景 适用于 UX 与架构决策的理由追溯、决策记录必要性判断、决策文档编写，以及产品意图变化的检查。示例包括“为什么这样设计？”、“这值得写 ADR 吗？”、“记录我们为什么扩展现有组件而不是创建新组件”。
限制与边界 不编造证据、需求、理由、实现状态或合规信息。不为了形式而创建文档。不向用户背诵内部规则，除非某条规则实质影响答案。当用户和任务已经清晰，或缺失信息不会实质性改变工作时，不引入研究问题、人物画像或发现工作。仅从代码或实现变化推断战略转变是不被支持的。若项目没有约定格式，只保留轻量结构。