Product launch validator
Skill TashanGKD/tashan-cursor-skills/skills/product-launch-validator
他山 Cursor Skill 体系 — 95个Skills + 32个Rules + 18个SubAgents，让AI在执行任务时能自主判断、按规范执行、并从经验中自我进化
npx -y skills add TashanGKD/tashan-cursor-skills --skill product-launch-validatorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
新产品/新场景立项前的三大闭环兼容性检查。在触发 role-产品经理 之前，验证新产品是否与现有认知体系、工作域架构、技术架构兼容，识别缺口并给出补齐建议。触发词：「新项目立项」「启动新产品」「新产品兼容性检查」「立项前检查」「这个产品和我们体系兼容吗」「三大闭环兼容性」。与 role-产品经理 的区别：后者设计产品内容；本 Skill 检查产品与整体体系的结构兼容性。
SKILL.md
6.8 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it
新产品三大闭环兼容性验证（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