메뉴
新产品/新场景立项前的三大闭环兼容性检查。在触发 role-产品经理 之前，验证新产品是否与现有认知体系、工作域架构、技术架构兼容，识别缺口并给出补齐建议。触发词：「新项目立项」「启动新产品」「新产品兼容性检查」「立项前检查」「这个产品和我们体系兼容吗」「三大闭环兼容性」。与 role-产品经理 的区别：后者设计产品内容；本 Skill 检查产品与整体体系的结构兼容性。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
AI配图能力层 Skill。任何需要生成信息图的任务都调用此 Skill，而不是自行调用 API。包含：模型选择、API调用、多视角草图流程、风格库引用、配图索引联动。触发词：「需要绘图」「生成配图」「画一张图」「制作信息图」「根据这段文字画图」「图片提示词」。
架构/系统差距分析 Skill。将当前系统/代码库/文档与目标框架/标准/竞品对比，生成带证据链的差距报告（兼容/冲突/缺失三类），为整改计划提供输入。触发词：「对比XXX和YYY」「这两个项目有什么异同」「找出差距」「现有系统与目标有什么不对齐」「竞品分析」「和XXX相比缺什么」。
分析文章可用的多种配图视角，为每个角度生成提示词草图供用户选择。触发词：帮我分析配图角度/生成多视角草图/配图有几种选择/给我几个配图方案。
管理他山公众号的配图风格库，提供风格模板调用和新风格沉淀。触发词：调用风格库/用XX风格/存入风格库/更新风格模板/风格库有哪些风格。
按郑总的审稿标准审阅中文文章草稿，检查AI腔、标题写法（4种错误类型）、绝对表达、结构层次污染、结语完整性，逐条给出修改方案。当用户说"审稿""帮我检查文章""review一下"时使用，也可在完成文章草稿后主动执行。
追踪文章审稿意见，将编辑反馈结构化记录并逐条落实。触发词：审稿意见/修改文章/这里写得不好/审稿反馈/帮我追踪这个意见。
| 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 问题）被遗留到开发后期才发现。
验证结果：