Fullstack Product Specification 是一个面向全栈开发协作的规范定义技能，目标是在编码开始前把跨前端与后端的产品变更讲清楚，形成团队共享的事实来源。
适用场景
该技能在以下情况使用：
- 单次交付切片同时跨越 UI 与后端；
- 需求不清晰、相互冲突或不完整；
- 团队在编码前需要一份共享的事实来源。
工作流程
该技能定义了六个步骤：
- 记录业务成果、用户角色和成功指标。
- 为每个角色定义旅程和状态（正常路径、空状态、错误、拒绝访问）。
- 明确 API 契约，包括请求与响应 schema、错误和版本管理。
- 定义领域与持久化影响（新实体、迁移、索引、保留策略）。
- 设定非功能性需求（延迟、吞吐量、可访问性、安全性、可审计性）。
- 记录发布策略、迁移或回填需求，以及回滚标准。
必需检查
- 功能简报包含可测试的验收标准；
- API 契约草案覆盖错误、版本管理和示例；
- UI 状态矩阵覆盖加载、空、错误和成功；
- 数据模型或迁移影响已记录，并明确回滚负责人；
- 构建前批准发布与回滚说明。
必需产出物
- 带验收标准的功能简报；
- API 契约草案（OpenAPI、JSON Schema 或等价物）；
- 覆盖加载、空、错误和成功的 UI 状态矩阵；
- 数据模型或 schema 变更说明；
- 带决策负责人的发布与回滚说明。
危险信号
该技能列出以下需要警惕的情况：需求只描述 UI 视觉而没有行为规则；后端假设只嵌入在前端代码注释中；API 错误和边界情况未定义；schema 或契约变更没有迁移方案。
决策框架
- 如果需求仅涉及 UI，必须在构建开始前强制进行 API 与数据影响评审。
- 如果变更触及认证或资金流，必须要求安全与失败模式场景。
- 如果需要迁移，选择 expand-migrate-contract，除非有更强的替代方案被证明合理。
- 如果性能 SLO 未知，在实施前增加基线测量任务。
常见借口与反驳
- “UI 完成后再定义 API。”——这会导致返工和契约漂移；应尽早锁定最小 API 形态。
- “边界情况可以等 QA。”——未定义的错误行为会变成生产缺陷；现在就明确。
- “回滚是显而易见的。”——数据变更往往使回滚失败；应记录确切的回滚条件和步骤。
证据包
- 已批准的功能简报，含验收标准和负责人；
- API 契约差异，附向后兼容说明；
- 覆盖所有关键转换的 UI 状态矩阵；
- 数据迁移说明，含回滚决策点；
- NFR 检查清单，含明确的 SLO 目标。
退出标准
- 验收标准可测试且与实现无关；
- 契约兼容策略已记录；
- UI 与后端的所有权边界明确；
- 发布风险与回滚路径已批准。
限制
该技能描述的是一套规范与检查流程，本身不提供具体代码实现；官方文本中未提供安装命令、平台支持范围、收费信息或实际效果数据，这些内容暂未提供。