Startup OS｜创业商业化诊断

> Display Name: Startup OS｜创业商业化诊断
> 路径约定：<startup_os_root> = 本技能安装目录（SKILL.md 所在目录）；<startup_os_workspace> = 用户工作空间（存放 05_CASES 案例库的目录，默认 = 对话会话工作空间，可用环境变量 STARTUP_OS_WORKSPACE 显式指定；解析逻辑以 scripts/prepare_case.py 为准）。全部运行资产以相对路径从 <startup_os_root> / <startup_os_workspace> 解析；禁止使用任何本机绝对路径。
> Version: 0.1.3-alpha
> Skill Type: User Entry / Packaging Layer（薄包装层）
> 定位：本技能是 Startup OS 的 WorkBuddy 用户入口。它自身不做任何商业分析，只负责：识别用户意图 → 收集输入材料 → 匹配/准备 Case → 委派现有 Startup OS Runner 执行 → 委派 Product Presenter 呈现 → 自动执行 Investor Lens（Phase 8A-3.2） → 用用户语言返回结果。
>
> Prefer Thin Wrapper. Do Not Rewrite Working Runtime. Do Not Duplicate Rules. Do Not Duplicate Agent Logic.
> 分析能力与规则全部来自本技能捆绑资产：<startup_os_root>/rules（规则与 Schema）、<startup_os_root>/subskills（9 个运行子技能）、<startup_os_root>/renderer（报告渲染器）。

1. When To Use（触发意图）

用户在对话中上传 BP / 项目材料，并用自然语言要求诊断，例如：

• "诊断这个项目"
• "分析这份BP"
• "帮我做商业化诊断"
• "帮我看看这个创业项目"
• "用Startup OS分析"
• "对这个项目做压力测试"

或任何同义表达。本技能是唯一用户入口；触发后用户不需要再理解或提及任何内部概念（Runner / Agent / API / MODE / Presenter / Runtime / Artifact 均为内部实现，不得暴露给用户）。

2. Input Expectations（输入预期）

• 支持材料：PDF / DOCX（PPT / Word 等常见形态亦可，按现有 Skill 能力处理）。
• 用户上传多份材料时，默认视为同一项目的 evidence set，一次性全部纳入；仅当用户明确说明属于不同项目时才分开处理。
• 用户不需要填写文件路径：材料以对话上传件为准；若用户以本地路径提供文件，直接使用该路径。
• 没有可分析材料时：不运行任何分析。 直接用用户语言提示：

> "请先上传项目BP或相关材料（PDF 或 Word 均可），上传后我会自动开始诊断。"

3. Execution Workflow（执行流程）

Step 0 — 材料识别

1. 在当前对话中定位用户上传的 BP / 项目材料文件（附件路径）。
2. 找不到任何可分析材料 → 按第 2 节提示，STOP。
3. 找到材料 → 登记：文件名、格式、数量（多份 = 同一项目 evidence set）。

Step 1 — 既有 Case 匹配

运行本技能自带适配脚本（薄 adapter，只做匹配，不做分析）：

python <startup_os_root>/scripts/prepare_case.py match --file <材料路径> [--file <材料路径2> ...]

按返回的 verdict 分流：

Step 2 — 创建新 Case

python <startup_os_root>/scripts/prepare_case.py create --file <材料路径> [...] [--name <公司名>]

• 公司名可从材料文件名或用户表述获得；无法确定时省略 --name（脚本自动以材料名命名）。
• 脚本只新增 Case 目录并复制材料，绝不修改任何既有 Case。
• 记录返回的 case_dir，作为后续唯一工作边界。

Step 3 — 委派执行（Delegation）

读取 <startup_os_root>/subskills/startup-os-runner/SKILL.md（捆绑子技能，非独立安装），将 case_dir 作为 Case Directory 传入，严格按其全部规则执行：

• Runner 负责完整工作流：Startup Intake → Commercial Triage → 按 Triage 决策执行 selected agents（Customer / Business Model / GTM）→ Commercial IC（仅当 Gate 满足）；
• MODE A / B / C 的全部纪律（Triage Decision Is Binding、MODE B Ends Before IC、Never Overwrite 等）以 Runner Skill 为准；
• 各专项分析由对应捆绑子技能（startup-intake / commercial-triage / customer-agent / business-model-agent / gtm-agent / commercial-ic，位于 <startup_os_root>/subskills/）执行，规则一律从 <startup_os_root>/rules/ 正式文件读取；
• 分析工作流完成后，呈现层依次执行：Step 4（Product Presenter）→ Step 4.5（Investor Lens 自动执行）→ Step 5（用户摘要）→ Step 6（可视化报告）；
• 本技能不得代替任何一步分析。

Step 4 — 委派呈现（Presenter）

工作流完成后，读取 <startup_os_root>/subskills/product-presenter/SKILL.md（捆绑子技能），对 case_dir 生成：

• product_output_v01.md（人类可读）
• product_output_v01.json（机器契约，12 root keys）

若 Case 已存在这两个文件（EXISTING_PARTIAL 场景可能已含），遵循 Never Overwrite：直接使用既有文件。

强制执行（产物验证）：Step 4 完成后必须确认 case_dir/product_output_v01.json 已生成（机器契约 12 root keys）。若缺失 → 重新执行 Presenter 一次；仍失败 → 停止并如实说明卡点，不得宣告诊断完成。

Step 4.5 — Investor Lens 自动执行（Phase 8A-3.2 集成点）

Product Output 生成后，默认自动执行 Investor Lens（用户无需任何额外指令，如"生成投资人观点" / "运行 Investor Lens"）：

1. 读取 <startup_os_root>/subskills/investor-lens/SKILL.md（捆绑子技能），严格按其 Skill + <startup_os_root>/rules/investor_lens_rules_v02.md + <startup_os_root>/rules/investor_lens_schema_v01.json 执行；
2. 已有 Lens 保护：若 investor_lens_v01.json / investor_lens_v01.md 已存在 → Never Overwrite，直接使用既有产物，不重跑；
3. 无 Lens 时按 Triage MODE 生成：
   - MODE A → 允许输出 NOT_AVAILABLE 或非常有限 PARTIAL；不得为了生成观点而绕过证据不足纪律；
   - MODE B → 必须生成 PARTIAL（即使 GTM / Commercial IC 未运行；limitations 首条声明"当前尚未进入完整综合商业判断，因此以下投资人视角仅基于现有专项证据"）；基于 Product Output + Customer + Business Model + Triage 生成有限专业判断；
   - MODE C → 生成 COMPLETE（消费 Customer / BM / GTM / Commercial IC / Product Output）；
4. 失败隔离：Lens 执行失败（Skill 缺失 / 校验失败 / 生成异常）→ 不得影响已成功的 Product Output。Product Output 保留，Lens 标记 FAILED / NOT_AVAILABLE，user_summary 与 HTML 仍生成基础版本，并显示"投资人视角暂未生成"；
5. 校验：运行 <investor-lens>/scripts/validate_investor_lens.py <investor_lens_v01.json>，ALL PASS 才视为 Lens 成功。

> 旧 Case enrichment（Phase 8A-3.2）：旧 Case 已有 Product Output 但无 Investor Lens 时，同样自动执行本步——不重跑上游 Agent、不覆盖 Product Output，只新增 investor_lens_v01.json / investor_lens_v01.md 并重新派生 user_summary / HTML。已有 Lens 时遵守 Never Overwrite。

强制执行（产物验证）：Step 4.5 结束后 case_dir 中必须存在 investor_lens_v01.json（COMPLETE / PARTIAL / NOT_AVAILABLE 任一合法状态）或 investor_lens_v01.md。两者皆无 → 标记 Lens FAILED 并记录失败原因，继续 Step 5/6 基础交付（不伪造观点，user_summary 与 HTML 中显示"投资人视角暂未生成"）。

Step 5 — 用户摘要

读取 product_output_v01.json，按第 5 节结构输出最终用户摘要，并用 present_files 展示 product_output_v01.md。

Investor Lens 摘要集成（Phase 8A-3.2）：若 Investor Lens 成功生成，用户摘要默认新增【投资人视角】区段，只展示两项：

• Investor Lens Summary（投资人视角摘要）
• Key Investment Variable（关键投资变量）

不得默认展示详细 Lens 内容（维度判断 / why / break / changes / questions 均不进入默认摘要）。若 Lens 不可用 → 不伪造观点，摘要中显示"投资人视角暂未生成"。

Step 6 — 可视化报告（Phase 8A-3 / 8A-3.2 集成点）

结果呈现阶段调用 <startup_os_root>/renderer 的确定性渲染器（renderer.py），把 product_output_v01.json 渲染为单文件可视化报告：

python <startup_os_root>/renderer/renderer.py --input <case_dir>/product_output_v01.json --outdir <case_dir> --quiet

• 若 investor_lens_v01.json 存在（本流程生成或既有）：追加 --lens <case_dir>/investor_lens_v01.json；默认 PUBLIC_LOCKED（展示 Investor Lens Summary + Key Investment Variable，详细内容 LOCKED 且 HTML source 不含 detail 明文）；需要完整内部报告时显式 --mode INTERNAL_FULL；
• 产出：startup_os_report.html（可视化报告）+ user_summary.md（文本摘要，含【投资人视角】两行）。二者同源，均映射自 Product Output JSON；渲染器只做映射，零商业判断，不改变任何结论；
• 用 present_files 优先展示 startup_os_report.html；渲染器缺失或执行失败时，回退到 Step 5 的 Chat 摘要方式呈现，不阻塞结果。

强制执行（产物验证）：Step 6 完成后必须确认 case_dir/startup_os_report.html 与 case_dir/user_summary.md 均已生成。任一缺失 → 重新执行 renderer 一次；渲染器仍不可用 → 回退 Chat 摘要并如实说明报告未生成，不得伪造产物。

Step 7 — FINAL DELIVERY GATE（Completion Criteria，强制）

A Startup OS diagnosis is NOT COMPLETE until all of the following exist in case_dir：

• [ ] product_output_v01.json（Step 4 Product Presenter 产物）
• [ ] investor_lens_v01.json（COMPLETE / PARTIAL / NOT_AVAILABLE 任一合法状态；Investor Lens 自身失败时允许基础版交付，见 Step 4.5 失败隔离）
• [ ] user_summary.md（Step 6 Renderer 产物）
• [ ] startup_os_report.html（Step 6 Renderer 产物）

规则：

1. 专项分析（Intake / Triage / Customer / BM / GTM / IC）完成后不得提前返回——必须继续执行呈现层：Step 4 → Step 4.5 → Step 5 → Step 6；
2. 每一派生步骤完成后必须验证对应产物存在；缺失 → 重试该步骤一次；仍失败 → 诚实停止并说明卡点；
3. 只有四件套就绪（或按 Step 4.5 / Step 6 明示的例外）后，才允许向用户宣告"诊断完成"；
4. 不得要求用户第二次输入"生成报告" / "生成 Investor Lens" / "渲染 HTML"。

最终 Chat 返回格式（Gate 通过后，按序返回，不是长篇分析文本）：

1. 一句话项目判断（来自 commercial_snapshot）
2. 当前商业化状态
3. Top Facts（当前已知重要事实）
4. Top Gaps（最关键的证据缺口）
5. Next Actions（下一步最值得补充的材料）
6. 【投资人视角】Investor Lens Summary + Key Investment Variable（Lens 可用时）
7. 明确提示："已生成可视化诊断报告：startup_os_report.html"（并用 present_files 展示该文件）

4. User Language Discipline（用户语言纪律）

• 面向用户的全部输出使用 references/user_language_map.md 的映射表；
• 内部 Artifact / 正式分析文件继续使用正式术语与八类证据体系（SOURCE_FACT 等），但不得原样出现在用户对话中；
• 内部状态对用户的说法：材料披露 / 已验证 / 当前未知 / 当前分析范围 / 暂未进入综合商业判断；
• 禁止对用户输出：错误码（DEPENDENCY_MISSING 等）、工程名词（normalized_document / artifact / runtime / schema / MODE A/B/C 字面量）、"Agent 失败"、"IC Gate blocked"、"Artifact 缺失"；
• 不足以继续时统一说："当前材料不足以支持进一步判断。"

5. Output Behavior（输出行为）

最终用户摘要固定包含以下 7 项，每一项都必须映射自 product_output_v01.json 对应字段，不得由本技能自行分析或重新推导：

1. 一句话项目判断 — 来自 commercial_snapshot
2. 当前商业化状态 — 来自 workflow / commercial_snapshot（用户语言）
3. 当前已知的重要事实 — 来自 layers / commercial_snapshot（标注 已验证 / 材料披露）
4. 当前最关键的证据缺口 — 来自 evidence_gaps
5. 下一步最值得补充的材料 — 来自 evidence_requests
6. 当前分析范围 — 来自 analysis_coverage
7. 是否已经进入 Commercial IC — commercial_ic 存在且完成 → "是"；否则 → "否"，并按用户语言说明原因
8. 【投资人视角】（Phase 8A-3.2 可选新增） — Investor Lens 成功时追加两项：Investor Lens Summary + Key Investment Variable；Lens 不可用时显示"投资人视角暂未生成"，不伪造观点

规则：

• Chat Summary 只做映射，不做第二次商业判断，不增加结论，不改变任何 Agent / IC Verdict；
• 正式结果以 Product Output 为准；Lens 摘要仅来自 investor_lens_v01.json 的 investor_lens_summary / key_investment_variable 字段；
• 摘要模板见 references/user_language_map.md 第 3 节；
• product_output 某键缺失或为空 → 如实说明，不编造。

6. Safety / Evidence Discipline（安全与证据纪律）

• Existing Artifact Before New Run. Never Overwrite Formal Artifacts. 既有正式产物一律不覆盖、不删除、不重命名（由 Runner 与 presenter Skill 强制执行）。
• Evidence Discipline：BP / founder material 默认 SOURCE_FACT；UNKNOWN ≠ unverified；Positive Evidence Must Be Preserved；Industry pattern ≠ company fact。该纪律由正式规则文件（evidence_rules 等）执行，本技能不复制其内容。
• 正式资产保护：本技能捆绑资产（<startup_os_root>/rules、<startup_os_root>/subskills、<startup_os_root>/renderer）与既有 <startup_os_workspace>/05_CASES 只读；新增 Case 目录是唯一允许的写入（且仅经 prepare_case.py create）。
• 不使用互联网；不跨 Case 读取（Runner 强制）。
• 新 Case 目录命名遵循既有惯例（Case_NNN_公司名，编号由脚本自动分配）。

7. Failure Behavior（失败行为）

8. Hard Prohibitions（硬禁止）

1. 本技能不得自行分析 BP、自行判断证据等级、自行选择分析深度；
2. 不得复制 Rules / Agent 逻辑 / Presenter 逻辑到本技能（单一事实来源：正式目录 + 已安装 Skill）；
3. 不得覆盖、删除、重命名任何既有正式 Artifact 或 Case；
4. 不得绕过 Runner 的 MODE A/B/C 纪律与 Commercial IC Gate；
5. 不得在用户输出中暴露内部工程术语；
6. 不得使用互联网或跨 Case 读取；
7. 不得为"完成流程"伪造结果或静默降级；
8. 不得修改 <startup_os_root>/rules / <startup_os_root>/subskills / 其他已安装 Skill。

9. SELF-CHECK（每次执行后）

1. 是否自行分析了 BP？YES → FAIL
2. 是否绕过或改写了 Runner / 各分析 Skill 的规则？YES → FAIL
3. 是否覆盖了任何既有正式产物？YES → FAIL
4. 既有完整 Case 是否被重跑？YES → FAIL
5. 用户摘要每个字段是否都来自 product_output_v01.json？NO → FAIL
6. 用户输出是否包含工程术语/错误码？YES → FAIL
7. 无材料时是否友好提示而非报错？NO → FAIL
8. 是否只新增了 Case 目录（无其他写入）？NO → FAIL
9. （Phase 8A-3.2）Product Output 后是否自动执行了 Investor Lens（生成 Lens 产物，或如实标注不可用）？NO → FAIL
10. （Phase 8A-3.2）Lens 失败时是否保留了 Product Output 并生成基础版 user_summary / HTML？NO → FAIL
11. （Phase 8A-3.2）用户摘要【投资人视角】是否只展示 Investor Lens Summary + Key Investment Variable 两项？NO → FAIL
12. （Phase 8A-3.2）已有 Lens 是否被覆盖？YES → FAIL
13. 四件套（product_output_v01.json / investor_lens_v01.json 或合法 NOT_AVAILABLE / user_summary.md / startup_os_report.html）全部就绪后才宣告"诊断完成"？NO → FAIL
14. 是否在专项分析结束后提前返回（未执行呈现层 Step 4 → 4.5 → 5 → 6）？YES → FAIL
15. Chat 是否明确提示"已生成可视化诊断报告：startup_os_report.html"？NO → FAIL

全部 PASS 本次执行才有效。