用途：当功能名称已存在，但角色、动作、状态、权限、失败路径或完成证据不清；团队准备基于薄弱需求画界面或开工；需要在不改动已批准信息架构与品牌结构的前提下细化产品行为；或需要让“完成”“已批准”“已交付”具备可验证含义时使用。不适合用来选视觉风格、生成最终 UI、设计后端架构或重写已批准的导航模型。
主要能力：1）建立权威来源，列出已批准需求、信息架构、术语、政策与用户明确决定，并区分已确认、提议、待决策；2）定义结果，写明角色、情境、期望结果与范围外行为；3）对产品对象建模，识别业务对象、生命周期归属、版本/范围键及关系；4）定义动作契约，为每个用户或智能体动作记录前置条件、输入、可见结果、副作用、证据、取消/撤销与失败处理；5）定义状态模型，覆盖正常、空、加载/运行中、等待人工、阻塞/冲突、失败、取消与恢复等实质影响体验的状态；6）定义权限矩阵，记录查看、修改、批准、覆盖、导出或执行自动化的授权，未知权限保持待决策；7）定义证据与验收，状态标签不等于证明，须说明何种产物、事件、批准或运行时结果证明成功。
使用方式：按上述顺序推进，并发布功能契约，结构参考 feature-contract.md；导航问题交给 navigation-design，页面延续约束交给 ui-continuity。最佳实践包括：行为先于布局，卡片和表格只是表现形式而非功能契约；保留上游决定，不得在补功能规格时“改进”已批准的信息架构；不虚构权限，批准、覆盖、AI 执行与破坏性动作需明确规则；状态不等于证据；除正常路径外还要设计恢复，定义重试、回滚、恢复、冲突与人工接管；提议须保持标注，不能被伪装成已确认行为。定稿前查看 anti-patterns.md。输出契约包含：功能目标与范围、角色与对象、动作契约、状态模型、权限矩阵、证据/验收规则、依赖与待决策项，以及不含视觉样式的下游页面影响。
限制：资料未提供具体平台、安装命令、收费或价格信息。