| name | product-launch-validator |
| description | 新产品/新场景立项前的三大闭环兼容性检查。在触发 role-产品经理 之前，验证新产品是否与现有认知体系、工作域架构、技术架构兼容，识别缺口并给出补齐建议。触发词：「新项目立项」「启动新产品」「新产品兼容性检查」「立项前检查」「这个产品和我们体系兼容吗」「三大闭环兼容性」。与 role-产品经理 的区别：后者设计产品内容；本 Skill 检查产品与整体体系的结构兼容性。 |
新产品三大闭环兼容性验证（product-launch-validator）
关系类型：validates → 三大闭环架构蓝图（在立项时验证 Loop 1/2/3 的兼容性）
触发时机：role-产品经理 激活之前（可选但推荐）
设计依据：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」
使用场景
何时触发：
- 启动一个全新的产品项目（而非现有产品的迭代）
- 在现有生态中添加新的独立场景或子系统
- 不确定「这个新产品和我们现有的 Skill 体系/认知结构/部署架构是否兼容」
不应触发：
- 现有产品的功能迭代（走 role-产品经理 迭代模式即可）
- 纯 Skill 或 Rule 的新建（走 skill-designer）
激活后立即执行
Step 1 收集新产品基本信息
询问用户（如果上下文不明确）：
「请描述新产品的：
1. 核心功能一句话描述
2. 主要用户群体
3. 依赖的技术栈（前端框架/后端语言/AI能力）
4. 与现有产品的关系（完全独立/共享账号/共享数据库）」
确认后继续。
Step 2 Loop 1 检查：Skill 体系兼容性
Read: .cursor/skills/skill-index/SKILL-INDEX.md（快速扫描，了解已有能力覆盖）
检查三项：
① 新产品的开发流程（PM→架构→前后端→测试→部署）是否有现有 Skill 完整覆盖？
→ 对每个阶段：现有 Skill 是否支持新产品的特殊需求（如新技术栈/新部署模式）
② 新产品涉及的领域（如：学术画像/科研工具/AI编辑器），是否有对应的域节点
在 DOMAIN-REGISTRY 中已定义？
→ 若无 → 标记「需要在 DOMAIN-REGISTRY 新增工作域」
③ 新产品是否引入了新的技术边界（如：新AI模型/新第三方服务/新部署架构）
需要新建 Skill 或 Rule 才能安全执行？
Step 3 Loop 2 检查：认知根对齐
Read: _内部总控/认知结构/L0_大脑总地图.md
Read: _内部总控/认知结构/L1.5_底层原则层/底层原则库.md（候选原则部分）
检查两项：
① 新产品的核心价值主张，在现有 L1 系统性文档中是否有对应的认知根？
→ 具体：L1 的哪篇文档支撑了「为什么要做这个产品」的判断？
→ 若无 → 标记「产品认知根缺失：建议先用 cognitive-capture-fragment
记录洞见，再用 cognitive-update-knowledge 补充 L1」
② 新产品的设计假设，是否与已确认的 L1.5 原则（P1/P2/...）兼容？
→ 扫描候选原则，识别可能与新产品设计有张力的原则
Step 4 Loop 3 检查：场景投射兼容性
Read: _内部总控/skill-system-design/DOMAIN-REGISTRY.md（快速了解已有工作域）
Read: _内部总控/开发规范/AI调用服务器助手接口规范.md（如有，了解技术约束）
检查两项：
① 新产品的工作域（工作任务/工作产物/项目结构）是否已在 DOMAIN-REGISTRY 的
五域定义之内？
→ 若无 → 标记「需要在 DOMAIN-REGISTRY 中新增节点」并给出建议定义
② 新产品的技术架构（账号体系/数据库/部署位置）是否与现有服务兼容？
→ 特别检查：是否重用现有账号体系？是否加入 tashan-shared 网络？
Step 5 输出兼容性报告
「━━ 立项兼容性检查报告 ━━
新产品：[名称]
Loop 1 Skill 体系：
✅ 已覆盖：[列举]
⚠️ 需补充：[列举缺口 + 建议行动]
Loop 2 认知根：
✅ 有认知根：[L1 文档名]
⚠️ 认知根缺失：[建议：先记录 L2 碎片或更新 L1]
Loop 3 工作域：
✅ 现有域覆盖：[域名]
⚠️ 需要新增域节点：[建议定义]
技术兼容性：[兼容 / 需要新建 Rule：前端品牌守门/API兼容检查/...]
─────────────────────────────
综合判断：
✅ 完全兼容 → 可直接触发 role-产品经理
⚠️ 有缺口但可并行补齐 → 建议按「建议行动」顺序处理后再启动开发
❌ 结构性不兼容 → 必须先解决阻塞项才能立项
[立即触发 role-产品经理] [先处理缺口]」
注意事项
- 本 Skill 不替代 role-产品经理：它是立项前的「可选预检」，不阻断开发流程
- 报告是行动建议，不是判决：用户可选择「带着已知缺口立项」并在后续补齐
- 认知根缺失不是 Blocker：新产品可以先立项，同时触发认知碎片捕捉建立认知根
- 最小化原则：只检查「与体系兼容性相关」的维度，不做产品设计本身的评判
与现有 Skill 的关系
| Skill | 关系 |
|---|
| role-产品经理 | 本 Skill 是其前置可选检查，通过后直接触发 PM |
| cross-project-coordinator | 若新产品与现有产品存在 API 依赖 → 同时触发协调框架 |
| cognitive-work-alignment-check | Loop 2 检查中若发现认知根缺失，建议触发该 Skill |
| DOMAIN-REGISTRY | Loop 3 检查中若需要新增工作域节点，更新该文档 |
变更记录
v1.0 — 2026-03-21 — 初始创建（PD1 Gap 修复）
根因：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」。每次启动新项目都直接触发 PM，没有检查「这个新产品是否与现有认知体系/Skill体系/工作域架构兼容」，导致：①产品认知根缺失（漂浮任务）②工作域未注册（传播完备性缺口）③技术栈不兼容（如 openclaw/opencode 问题）被遗留到开发后期才发现。
验证结果：
- 正向验证：立项新产品时触发，输出包含 Loop 1/2/3 三层检查报告（待真实场景验证）
- 负向验证：现有产品功能迭代不触发本 Skill
