z-assess（立项评估）
一句话：在"想清楚了"与"开工"之间加一道决策闸门——评四维、登风险、验假设，落到三选一的结论，不和稀泥。
help 用法卡
调用消息或斜杠参数恰为 help / 帮助 / 怎么用（整条仅此一词）时，逐字输出本卡后停，不进入任何流程；请求含其他内容时按正常流程走。
【z-assess 用法卡】立项评估——四维+风险+假设，结论三选一（Go / No-Go / 有条件 Go）。
| 场景 | 你这样说 | 会发生什么 |
|---|---|---|
| 可行性 | 「X 值不值得做？给我个 Go/No-Go」 | 对质 1–2 轮 → 评估报告 |
| 上线就绪 | 「X 要上线了，评审能不能上、还缺什么」 | 读 SRS/测试计划对质就绪度 → 三选一结论 |
| 重评 | 「上次评估的条件满足了，重新评一次」 | 读 05-管理/ 旧报告，出前版差异摘要 |
答"不知道"如实进假设清单；基线后产物落 05-管理/变更/。跨系列问法见 z-flow-kickoff help。
三条铁律（覆盖下文所有规则）
- 结论三选一：最终必须落到 Go / No-Go / 有条件 Go 之一，禁止"总体看好、建议继续观察"式的和稀泥结论。"有条件 Go"的条件必须可检验（有判据、有期限），如"两周内拿到数据授权，否则回退 No-Go"。
- 不虚构数字：成本、收益、工期没有依据就不量化，标"未量化"并列入决策待补；绝不编 ROI、编报价。可量化的先写算式与假设，再给结论。
- 待核 ≠ 已知：输入里标"待核/空缺"的信息（如 z-chain 图上的空位）一律按不确定处理，进风险与假设清单，不得充当可行性证据。
Gate：评估对象必须"已定义"
动手前检查：这个事项有没有一句话目标和使用方？
- 有 → 继续。
- 没有 → 先补齐再评估：已安装 z-clarify 时请用户先走澄清；用户要求当场评时，先问目标/使用方/硬约束三个最小问题再继续，并在报告中注明"输入未完整，结论为初步"。
- 用户只给了一个模糊想法、又明确要求"快速评估" → 允许粗评，但结论只能给"有条件 Go（条件＝先完成澄清）"或 No-Go，并在报告显著位置标注输入完整度。
输入（按优先级）
- 系列产物（z-系列工作区约定）：
docs/00-立项/下的 需求澄清报告与需求条目登记册（z-clarify）、生态角色表（z-chain，含空缺风险）。读到的直接引用，不重复问。 - 对话上文中的信息。
- 都没有 → 退化为最小输入模式（Gate 的三个最小问题）。
输入使用规则：每条评估依据标注来源（文件/用户口述/公开检索）；有检索工具时先检索再断言，检索不到的保持"待核"，模型知识不冒充证据（同 z-chain 数据来源规则）。
四维可行性（每维给：灯 + 一句结论 + 最大不确定项）
| 维度 | 问什么 | 常用证据来源 |
|---|---|---|
| 技术 | 有没有已知解法？团队能力与经验够不够？关键依赖成熟吗？ | 澄清报告·现状与数据；z-chain 上游供给空缺（断供风险在此记账） |
| 经济 | 成本构成？收益构成？能量化就量化，不能就定性 | 澄清报告·目标与指标；用户口述预算 |
| 操作 | 谁用？谁来运维？要改哪些流程/习惯？组织接不接受？ | 澄清报告·干系人；z-chain 治理/核心层空缺（没人拍板、没人接，在此记账） |
| 合规与进度 | 有没有法规/安全/合规红线？deadline 现实吗？ | 澄清报告·规则约束 |
灯判定：绿＝有依据支持可行；黄＝方向可行但存在关键不确定项；红＝存在依据表明不可行或与硬约束冲突。红灯不是终审——它必须出现在结论的理由里，并写明"翻红为绿需要什么"。
风险登记（top 3–5，宁缺勿编）
每条：风险描述｜概率(低/中/高)｜影响(低/中/高)｜缓解动作｜再评估触发条件。
z-chain 的空缺风险清单（无人拍板/无人对结果负责/产出没人接/上游断供）直接并入。凑不满 3 条就少写，不硬编。
关键假设（最危险假设先验证）
列出评估结论成立所依赖的关键假设，按"若为假、伤害最大"排序，每条给最廉价的验证方式（能一句话问清的不做调研，能调研的不做原型）。"有条件 Go"的条件通常就来自这里。
开场协议（完整级，z-系列工作模式）
首次进入先复述再对质——复述并入第 1 轮对质消息的开头（作答即确认，不单独占一轮）：
- 复述理解：评估对象 + 已读到的系列产物（输入来自
00-立项/时点名引用，如"读到登记册 R-001…"）+ 将评什么；必须含用户原话具体事实。 - 计划：对质 1–2 轮、每轮主题、形式（面板/卡片/文本）；报总预算与用户任务（答不上来说"不知道"也算有效回答，如实进假设清单）。
- 预期产物：立项评估报告（项目语境含落盘路径）。
- 当次边界：不做技术选型、不替用户拍板。
被 z-flow-kickoff 编排进入时沿用其契约与横幅，本节自动满足。
交互（1–2 轮对质，最多 3 轮）
不是问答收集（那是 z-clarify 的事），而是对质：把模型看到的最大不确定项、红灯依据、危险假设摆给用户，请用户补证据或确认接受风险。
第 1 轮 摆四维初判 + 最大不确定项（3–4 个对质问题）
第 2 轮 摆风险与危险假设，确认缓解动作与验证顺序（视需要）
收口 复述评估全貌 → 用户确认 → 输出立项评估报告
- Gen UI 宿主（如 ZCode Desktop）：双栏面板，配方同 z-clarify——左栏为本轮对质问题（点选高亮），右栏为评估实时状态（四维灯 + 风险清单 + 假设状态，
aria-live="polite"），"提交本轮"按钮用await window.zcode.sendFollowUpMessage({ prompt: "评估第 X 轮：Q1=…, Q2=…", title: "立项评估 第 X 轮" })发回；每轮更新同一文件（如assess-panel.html，写入宿主声明的会话可视化目录），当轮回复中以::visualize{"path":"<会话可视化目录>/assess-panel.html"}独立一行引用（不包代码块、不加链接）。面板 <1MB、无网络请求、颜色只用主题变量；sendFollowUpMessage桥接不可用时不重试，面板降级为纯展示，改由用户在聊天中作答。 - 无 Gen UI 宿主：AskUserQuestion 卡片（每题 2–4 选项，说明固定带一句"选它意味着什么"）；再退化为纯文本对质。
- 用户答不上来的就是不确定项，如实进假设清单，不装作收集到了。
输出与落盘
报告用金字塔结构（z-pyramid 如已安装则按其纵向三规则检验；未安装按"结论先行/同类分组/逻辑顺序"自查）：第一句就是建议，然后四维理由组，然后证据。
立项评估报告
〇、结论：Go / No-Go / 有条件 Go（条件与期限）
一、四维可行性（每维：灯｜结论一句｜依据｜最大不确定项）
二、风险登记（top 3–5）
三、关键假设与验证顺序（每条：最廉价验证方式）
四、决策待补清单（阻塞最终拍板的信息）
附录：输入清单与完整度（用了哪些材料、缺了什么）
落盘（z-系列工作区约定）：项目语境下默认写入 docs/00-立项/立项评估报告.md，落盘前一句话告知路径；已有同名文件先给差异摘要、确认后再覆盖；非项目语境或用户拒绝落盘时只出对话产物。基线后（部署期）：评二期/重构/"值不值得继续"且工程文档基线已存在（docs/01-需求/ 起）时，报告改落 docs/05-管理/变更/立项评估-<主题>.md（00-立项/ 已冻结），输入优先读 SRS、变更记录与跟踪矩阵。
与 z-系列的关系
z-flow-kickoff（编排：开场协议→契约→横幅→交接→续跑）
└─ z-pyramid(拆解) → z-clarify(澄清→登记册) ⇄ z-chain(生态/干系人事实)
↓
z-assess(本 skill：四维+风险+假设 → Go/No-Go)
↓ Go
z-init(工程文档基线化) → 下游 spec/开发（松耦合，AGENTS.md 契约）
- z-clarify 供给澄清报告与需求条目登记册；本 skill 不重新澄清，缺信息按 Gate 退回。
- z-chain 供给生态事实底座；空缺与三问答不上的位置直接进风险登记。
- z-pyramid 供表达结构（结论先行、纵向三规则）。分工要说清：评估"什么维度、什么结论"是本 skill 的事，"怎么把结论表达清楚"才是它的事。
- z-init 在 Go 之后消费本报告：风险登记册种子化、"有条件 Go"的条件转为里程碑前置项。
- 各 skill 相互独立、按需组合；联动方未安装时按本文件内的退化规则执行。
边界
- 不做技术选型与方案设计：红灯的技术项只描述"该方向存在未解风险"，不替用户选路。
- 不做精确工作量估算，只做量级判断（人日/人月/人年级）并标注置信度。
- 不替用户拍板：本 skill 给建议与可检验条件，Go/No-Go 的最终决定权在用户/决策方。
- 不虚构（铁律 2、3）；语言与用户一致。
