z-init（软件工程项目文档初始化）
一句话：项目确认后，把早期想法的产物转成工程文档基线——目录、模板、编号、追踪一次到位，待确认处留槽不编造。
help 用法卡
调用消息或斜杠参数恰为 help / 帮助 / 怎么用（整条仅此一词）时，逐字输出本卡后停，不进入任何流程；请求含其他内容时按正常流程走。
【z-init 用法卡】工程文档基线——立项 Go 后按 ISO 29148 / GB/T 8567 lite 建文档集。
| 场景 | 你这样说 | 会发生什么 |
|---|---|---|
| 正常建档 | 「项目定了，按规范初始化项目文档」 | 一轮 4 问 → 建档 → 自查报告 → 交接说明 |
| 纯模板 | 「搭文档骨架，需求后面补」 | 只搭骨架不填内容，README 声明需求待补 |
前置：项目已确认（还在犹豫→先 z-assess）；个人试用建议轻量档；产出含 AGENTS.md 接口契约。跨系列问法见 z-flow-kickoff help。
Gate：确认"已立项"才动手
- 用户明确表达项目已确认（立项通过 / Go / 开工 / 初始化项目）→ 继续。
- 用户还在犹豫要不要做 → 停，建议先走 z-assess（未安装则一句话说明：先评估后初始化）。
- 已确认但没有早期产物（没走过 z-clarify/z-assess）→ 允许"纯模板模式"：只搭骨架不填内容，并在 README 声明需求待补；同时提示可用 z-clarify 补课。
开场协议（轻量级，z-系列工作模式）
问询前一句话复述并入问询消息（项目 + 将建什么档位 + 吸收哪些早期产物），四个问询问题即确认载体，用户作答即视为确认开工。被 z-flow-kickoff 编排进入时沿用其契约与横幅。
初始化前的一轮问询（≤1 轮，4 问，已知的不重复问）
- 项目名与一句话定位（README 首行与 SRS 背景用）
- 项目类型（Web / 服务 / 数据 / 算法 / 嵌入式 / 其他——影响测试与运维文档的侧重）
- 文档档位：轻量（个人/小团队——个人试用项目默认建议此项）｜标准（常规团队协作）｜完整（对齐 GB/T 8567 全集，如招投标/验收场景）
- 协作约定（分支模型、评审节奏——可选"按团队现状留空"）
有 AskUserQuestion 类工具时用卡片（选项说明带"选它意味着什么"）；无工具环境纯文本，一轮问完。
目录与文档集（标准档）
README.md 一句话定位、快速上手、文档地图
CHANGELOG.md 版本记录（Keep a Changelog 格式）
AGENTS.md 接口契约：文件所有权、R-xxx 语义、变更通道、单一事实源（见"接口契约与收口交接"）
docs/
00-立项/ 早期产物原样保留（澄清报告/需求条目登记册/评估报告/生态角色表）
01-需求/
SRS.md 软件需求规格说明（结构见下）
需求跟踪矩阵.md 目标 ↔ 需求 ↔ 验证方式 双向追踪
02-设计/
架构说明.md 占位模板（注明何时填：技术方案评审前）
ADR/0000-adr-模板.md 架构决策记录模板 + 首条示例
03-开发规范.md 分支/提交/评审/完成定义（DoD）
04-测试/
测试计划.md 策略、准入准出；用例追踪需求 ID
05-管理/
项目计划.md 里程碑（相对周期，不编日期）、分工占位
风险登记册.md 从评估报告种子化
变更记录.md 需求变更日志（变更-理由-影响-审批）
术语表.md 双方口径必须一致的词（从澄清报告附录种子化）
裁剪表：
| 档位 | 内容 |
|---|---|
| 轻量 | README + AGENTS.md + SRS + 项目计划 + 测试计划 + ADR |
| 标准 | 上表全集 |
| 完整 | 标准 + GB/T 8567 其余文档占位（概要设计/详细设计/数据库设计/用户手册/操作手册/开发进度月报目录），每份只给模板与"何时填" |
档位由问询第 3 题确定；用户没答时默认标准档并说明。
建档后自查（必做）：批量建档容易漏件——对照当次档位的文件清单逐一核对"存在且非空"（有意的占位模板除外），然后向用户报告"已建 N 件、缺 X 件及原因"。标准档 13 件：README、CHANGELOG、AGENTS.md、SRS、需求跟踪矩阵、架构说明、ADR/0000-adr-模板、开发规范、测试计划、项目计划、风险登记册、变更记录、术语表（docs/00-立项/ 为既有产物归位，不在 13 件内）。
接口契约与收口交接（松耦合边界）
本系列与其他阶段功能集（SDD/spec 工具、CI、运维体系）只通过文件契约耦合，不做工具特定集成。建档时生成 AGENTS.md——复制本 skill 的 assets/agents-template.md 按项目实况填充（agent 工具的事实发现约定，下游 agent 与协作者先读它）：
- 所有权：
docs/00-立项/冻结只读；docs/01–05/本系列产出、下游只读；下游自有产物目录（.speckit/、.kiro/等）归下游；需求类（SRS/跟踪矩阵/登记册）改动唯一入口05-管理/变更记录.md，管理类（风险登记册/项目计划）经用户确认直接更新、不登台账。 - 单一事实源：SRS 是需求唯一事实源；下游 spec/requirements 文件是派生视图——可再生、禁手改回写；再入（二期/变更）先从 SRS 再生派生视图再开工。
- 语义：R-xxx 全生命周期不变更、不复用；状态词（已确认/待定/待核/空缺）、MoSCoW、EARS 验证准则按登记册与 SRS 现行语义。
收口交接（自查后必做）：输出一段给下游（人或 agent）的交接说明——哪些文件就绪、把 SRS 第 3 章喂给你的 spec 工具、AGENTS.md 里有全部约定、需求改动一律走变更记录回流；已知下游工具时点名建议（如 spec-kit / Kiro / OpenSpec）。
SRS 结构（ISO/IEC/IEEE 29148 的 lite 适配）
1 引言（目的/范围/术语引用/参考）
1.1 项目宪章：3–5 条不可变红线（技术/质量/合规，从澄清报告·规则约束提炼），
宁可少列、条条可判；后续变更逐条对照，冲突即评审问题
2 系统概述（背景来自澄清报告·业务背景；干系人引用 00-立项）
3 需求
3.1 功能需求 表：ID｜名称｜优先级｜描述｜来源｜验证方式
3.2 非功能需求 （性能/安全/合规/可用性…同表）
3.3 约束与假设 （来自澄清报告·规则约束与数据依赖）
4 验收准则（来自需求条目登记册的验证准则汇总）
5 开放问题与待确认项（来自未决问题清单）
需求质量特性自查（29148）：每条需求——必要、无歧义、可验证、有唯一 ID、可追踪。写不出验证方式的需求＝还没想清楚，移入第 5 节开放问题，不硬塞进需求表。
种子化规则（从早期产物填充，每处标来源）
| 目标文档 | 来源 | 规则 |
|---|---|---|
| SRS 需求表 | 需求条目登记册（z-clarify） | ID 原样继承、之后继续编号；每条补"验证方式"（测试/演示/审查/分析），补不出的进开放问题 |
| 需求跟踪矩阵 | 登记册 + 澄清报告·目标 | 目标→需求→验证方式三列；登记册"待定"条目照登并标状态 |
| 风险登记册 | 立项评估报告（z-assess） | 风险原样入册，新增"负责人/复查日期"空槽 |
| 项目计划 | 评估报告·条件与假设 | "有条件 Go"的条件转为里程碑前置项；假设验证顺序转为早期任务 |
| 术语表 | 澄清报告附录 | 原样迁入 |
| README / 00-立项 | — | 早期产物只引用不改动（保留可追溯凭据） |
没有来源的内容一律留空槽（（待补：…）），不编造——继承 z-系列"宁空勿编"。早期产物不在 docs/00-立项/ 而在对话里时，先请用户确认后一并落盘归位。
注：登记册的验证准则是可测试的通过条件（如"抽检通过率≥95%"）；SRS 的验证方式是验证手段分类（测试/演示/审查/分析）。由准则选择手段，两列并存、不互替。
需求管理规范锚点（本 skill 落地四件事）
- 唯一标识：R-xxx 编号全生命周期不变更、不复用；新增需求继续编号。
- 基线：文档就绪后建议用户执行（只给命令建议，不替用户执行）：
git add -A && git commit -m "docs: 项目文档基线 v0.1" && git tag docs-baseline-v0.1 - 变更控制：一切需求改动走
05-管理/变更记录.md登记（变更内容-理由-影响范围-审批）；涉及 ID/优先级/验证方式的变更必须同步 SRS 与跟踪矩阵；基线后 z-clarify/z-assess 的变更类产物存05-管理/变更/，台账只登一行索引；变更前对照 SRS 1.1 项目宪章逐条自查，冲突项单独标出、交用户裁决；管理类文档（风险登记册、项目计划）经用户确认直接更新，不登台账（台账只管需求类改动）。 - 双向追踪：跟踪矩阵保证"每个目标有需求覆盖、每条需求有来源目标"，矩阵断链即评审问题。
与 z-系列的关系
z-flow-kickoff（编排：开场协议→契约→横幅→交接→续跑）
└─ z-pyramid(拆解) → z-clarify(澄清→登记册) ⇄ z-chain(生态/干系人事实)
↓
z-assess(四维+风险+假设 → Go/No-Go)
↓ Go
z-init(本 skill：文档基线化) → 下游 spec/开发（松耦合，AGENTS.md 契约）
本 skill 是系列终点与工程起点：上游产物全部留在 docs/00-立项/ 作可追溯凭据，下游（设计、开发、测试）按基线文档开展工作。各 skill 相互独立；上游产物缺失时按"纯模板模式"退化。
边界
- 只管文档基线，不做代码脚手架、技术选型、CI 配置（用户点名时另行处理并声明超出本 skill 范围）。
- 不编日期：里程碑用相对周期（如 M1=+2 周），绝对日期由用户填。
- 诚实声明：本 skill 是 ISO/IEC/IEEE 29148 与 GB/T 8567 的 lite 适配，满足常规团队协作与验收场景；用于招投标、认证等强合规场景时，需按对应规范全文核对增补。
- 语言与用户一致。
