用途
Product Interface Spec 用于为产品或项目产出「详细功能设计计划」，其规格能让产品、设计、开发和测试共同使用。它围绕一条主链组织内容：用户目标 → 功能 → 页面 → 操作 → 状态变化 → 结果 → 验收证据。目标是让功能完整、流程清晰、页面结构明确，避免以几个界面、几张正常态截图拼凑出所谓的完整设计。
核心交付是三条主线：完整的功能清单与逐模块详规、走得通的交互流程、可直接接手的逐页界面结构，再由此推导计划任务。使用时应先读固定工作法，按其步骤执行。
主要能力
- 按固定模式整理详细功能设计计划。
- 全产品盘点，建立功能总表，并逐模块展开详规。
- 规划导航与逐页结构，描述信息架构与页面内容结构。
- 梳理用户旅程与逐操作转换，覆盖主路径、异常与恢复分支。
- 建立 Surface Registry，为每个交互单元定义触发、前提、上下文、状态转换与验收。
- 从功能与 Surface 推导可交接的计划任务。
- 支持功能清单整理、交互流程梳理、界面结构规划、产品设计计划和已有规格接续。
使用方式
按技能描述，完整整理与计划请求必须先读取固定交付合同 v1，并依次执行：来源 → 功能 → 导航 → 流程 → Surface → 任务 → 审阅。不得自行删减阶段、合并交付文件或省略必填字段。
交付形态：按合同创建固定七份 Markdown 文件与 delivery.json；若已有既有文件，则引用并补齐，不覆盖人工决定。文档方面需读取固定文档模板及审阅清单。
结构校验：最终执行 python3 <skill>/scripts/validate_delivery.py <PACKAGE> --require-ready，通过后才允许报告「按固定模式整理完成」。但语义审阅不能由脚本通过替代，未解决阻断必须保留。
首次完整整理时，需参照示例成果：读取示例阅读指南、示例项目A 原成果摘录及贯穿示例，按 00–06 学习从真实功能到界面、交互和任务的展开过程。示例项目A P02 用于另一业务链对照；示例项目B 教学包用于了解固定文件和机器索引的组织方式。接续已有项目时再读接续示例。注意：示例不是目标项目需求事实源，不得复制示例的菜单、技术栈、数量、待确认规则或审阅通过状态。
模式与授权：
- 「怎么做/审查/解释」：可在回复中给方法或只读审查，不因技能触发就创建文件。
- 「整理/输出计划/写文档」：写入用户指定目录；未指定则延续项目文档组织，先报告拟交付位置。
- 已有规格：从现有产物继续，保留 ID、人工修改和执行状态。只读参考仓库用于提取方法，不迁入其业务需求或状态。
- 视觉生成、业务实现、安装工具、初始化规格体系、提交发布分别受当前授权约束；本技能不自动启动这些阶段。
适用场景
- 功能清单整理：先明确用户/角色、对象、作用域、状态、触发条件和可观察结果，再定页面。
- 交互流程梳理：每条核心旅程覆盖入口 → 前置检查 → 输入 → 预览/必要审批 → 提交 → 处理中 → 结果 → 后续去向。
- 界面结构规划：区分产品端、全局外壳、业务域、导航入口、页面、局部页签和动作层。
- 产品设计计划：从功能和 Surface 推导设计、实现、验证任务。
- 已有规格接续：沿用已有编号并在机器索引中登记类型与父关系。
限制与要求
- 不得用文件数量、JSON 校验或少量设计图代替内容深度。
- 任务计划是必交付内容。
- 已存在的规格/任务作为唯一事实源，本技能产物提供结构化追踪视图；不形成两套冲突的事实源。
- 每个功能需包含稳定 ID、用户目标、前置条件、输入/输出、权限范围、主路径、异常与恢复、关联页面、验收、来源和成熟度；只有模块名、功能名和优先级的表格不合格。
- 每个主页面或结构不同的子页必须有布局分区表或文字线框；仅写「顶部+侧栏+内容区」不合格。
- 主链图必须配逐操作转换表；图中缺少错误分支、按钮去向未查明的均不合格。
- 每个 Surface 需使用模板定义触发、前提、上下文、必需信息、主/次操作、状态转换、成功/失败去向、返回行为与验收。
- 结构检查不能替代产品语义审查。
- 已有页面数/任务数不得自动转化为「完整产品已设计/实现」。
- 目标尺寸来自项目，不从历史示例推断。
- 正式实施任务引用已有规格体系；新设计细节若改变需求，先按项目流程更新正式规格。
- 关于具体收费、价格、平台支持等信息，现有资料暂未提供。