菜单
新产品/新场景立项前的三大闭环兼容性检查。在触发 role-产品经理 之前，验证新产品是否与现有认知体系、工作域架构、技术架构兼容，识别缺口并给出补齐建议。触发词：「新项目立项」「启动新产品」「新产品兼容性检查」「立项前检查」「这个产品和我们体系兼容吗」「三大闭环兼容性」。与 role-产品经理 的区别：后者设计产品内容；本 Skill 检查产品与整体体系的结构兼容性。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill product-launch-validator命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
施测大五人格量表（Mini-IPIP，20题），评估外向性、宜人性、尽责性、神经质和开放性。当用户选择填写量表、或画像中人格数据缺失时使用。
基于 SOC 职业分类
正在显示 SKILL.md
| name | product-launch-validator |
| description | 新产品/新场景立项前的三大闭环兼容性检查。在触发 role-产品经理 之前，验证新产品是否与现有认知体系、工作域架构、技术架构兼容，识别缺口并给出补齐建议。触发词：「新项目立项」「启动新产品」「新产品兼容性检查」「立项前检查」「这个产品和我们体系兼容吗」「三大闭环兼容性」。与 role-产品经理 的区别：后者设计产品内容；本 Skill 检查产品与整体体系的结构兼容性。 |
关系类型：validates → 三大闭环架构蓝图（在立项时验证 Loop 1/2/3 的兼容性） 触发时机：role-产品经理 激活之前（可选但推荐） 设计依据：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」
何时触发：
不应触发：
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-产品经理 | 本 Skill 是其前置可选检查，通过后直接触发 PM |
| cross-project-coordinator | 若新产品与现有产品存在 API 依赖 → 同时触发协调框架 |
| cognitive-work-alignment-check | Loop 2 检查中若发现认知根缺失，建议触发该 Skill |
| DOMAIN-REGISTRY | Loop 3 检查中若需要新增工作域节点，更新该文档 |
根因：三大闭环架构蓝图 §差距清单「新产品/场景加入时兼容性检查：❌缺失」。每次启动新项目都直接触发 PM，没有检查「这个新产品是否与现有认知体系/Skill体系/工作域架构兼容」，导致：①产品认知根缺失（漂浮任务）②工作域未注册（传播完备性缺口）③技术栈不兼容（如 openclaw/opencode 问题）被遗留到开发后期才发现。
验证结果：