菜单
面向新项目或现有项目的文档驱动开发 skill。Use when the user wants to create, 补齐, 更新, or refine project specs, run a Spec Kit-inspired workflow loop, maintain workflow/knowledge/change docs, analyze consistency, converge implementation back into docs, or update README/AGENTS for a real project.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/legeling/spec-init --skill spec-init命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | spec-init |
| description | 面向新项目或现有项目的文档驱动开发 skill。Use when the user wants to create, 补齐, 更新, or refine project specs, run a Spec Kit-inspired workflow loop, maintain workflow/knowledge/change docs, analyze consistency, converge implementation back into docs, or update README/AGENTS for a real project. |
这个 skill 不是“帮用户创建一堆空模板”的脚手架，也不是“固定 Bash 初始化器”。
它的真正职责是：
FR -> DES -> TEST -> T默认把这个 skill 当成“agent 写 spec 的工作流”，不是“脚本生成目录”。
优先级：
docs/、README.md、AGENTS.md用户只有一个想法、方向或需求草稿。
你要做的是：
用户已经有代码或仓库，想完善、补齐或更新 spec。
你要做的是：
[待确认]，但不要把整份文档都留空。先阅读并遵循：
references/doc-boundaries.mdreferences/example-idea-to-docs.md边界如下：
docs/workflow/00-intake/README.md: 为什么做，谁来用，什么不做docs/workflow/01-requirements/README.md: 做什么，为什么做，怎么验收docs/workflow/02-design/README.md: 当前阶段怎么实现，方案对比，规范约定docs/knowledge/context/README.md: 长期稳定的角色、术语、实体、业务边界docs/knowledge/structure/README.md: 长期稳定的模块边界、系统结构、集成关系docs/knowledge/behavior/README.md: 长期稳定的关键流程、状态流转、业务规则docs/knowledge/reference/README.md: 样例、协议、schema、素材、fixtures 等固定参考资料docs/workflow/03-implementation/README.md: 先做什么后做什么docs/workflow/04-verification/README.md: 怎么验证完成docs/workflow/04-verification/01-test-strategy-and-quality-gates.md: 长期测试策略、测试层级、质量门禁和准出标准docs/workflow/04-verification/02-test-standards.md: 测试代码命名、断言、隔离、Mock、失败路径和报告规则docs/workflow/04-verification/03-test-design-methodology.md: 等价类、边界值、状态机、决策表、安全、并发、契约和回归设计方法docs/workflow/04-verification/04-test-case-matrix.md: 模块级测试用例矩阵、优先级、层级、自动化状态和覆盖对象docs/workflow/04-verification/05-regression-suite.md: 长期回归套件、触发条件、命令登记规范和残余风险记录docs/workflow/04-verification/06-test-data-and-fixtures.md: 测试数据、fixtures、H2/Redis/外部依赖替身和脱敏规范docs/workflow/04-verification/07-coverage-map.md: 模块、需求、设计、测试资产和已知缺口之间的覆盖映射docs/workflow/05-tasks/README.md: 现在具体做什么动作docs/issues/README.md: 尚未解决的问题、阻塞项、风险和技术债docs/changes/: 这次为什么变、影响什么、同步了哪些文档和测试docs/releases/: 某个版本最终对外交付了什么docs/archive/README.md: 已归档、已替代、已废弃但仍需保留历史的文档docs/adr/: 关键架构或技术决策为什么改变docs/rules/: 默认工程规则这个 skill 保留自己的 layered docs 拓扑，但执行节奏借鉴 Spec Kit 的阶段化工作流：
| 阶段 | spec-init 落点 | 目标 |
|---|---|---|
| specify | docs/workflow/00-intake/README.md, docs/workflow/01-requirements/README.md | 把想法变成用户、边界、FR/NFR/AC |
| clarify | intake / requirements 的待确认区，必要时更新 docs/issues/ | 只澄清会影响范围、架构、数据、权限、测试的关键问题 |
| plan | docs/workflow/02-design/README.md, docs/workflow/03-implementation/README.md, docs/workflow/04-verification/README.md, docs/knowledge/ | 形成设计、实施顺序、验证策略和长期真相 |
| tasks | docs/workflow/05-tasks/README.md, docs/changes/active/<change-key>/tasks.md | 拆成可执行、可验证、可追踪的任务 |
| analyze | tasks 完成后、实现前，检查 requirements / design / verification / tasks / changes 是否冲突 | 找孤立 ID、缺失映射、未确认阻塞项和文档边界错误 |
| implement | 代码、测试、脚本、迁移等真实改动 | 只执行已能回链到 FR -> DES -> TEST -> T 的工作 |
| converge | 完成后回写 workflow、knowledge、changes、issues、releases、archive、README、AGENTS | 让代码现状、当前真相和历史变更记录重新一致 |
不要把这些阶段理解成必须生成 specs/ 目录。spec-init 的长期文档源仍是当前项目的 docs/ 拓扑。
先判断：
如果是现有项目：
如果是新项目：
先判断这次请求更接近哪一类：
tasks / verification / implementationrequirements / design / knowledge / changeschanges / verification / design，必要时回写 requirements 和 knowledgereleases / changes / READMEissues/archive/ 并说明替代关系不要把所有请求都当成“继续写任务”或“继续写代码”。
至少收集或推断：
如果用户要求的是“完整设计”或“完整需求”，还必须继续补齐：
如果用户是新手，主动给最小问题清单，不要只说“请补充更多信息”。
如果用户没有提到某个关键设计点，且这个点会影响 spec 质量：
特别要覆盖：
按顺序产出或更新：
docs/workflow/00-intake/README.mddocs/workflow/01-requirements/README.mddocs/workflow/02-design/README.mddocs/knowledge/context/README.mddocs/knowledge/structure/README.mddocs/knowledge/behavior/README.mddocs/knowledge/reference/README.mddocs/workflow/03-implementation/README.mddocs/workflow/04-verification/README.mddocs/workflow/05-tasks/README.mddocs/issues/（当存在未决问题、阻塞、技术债、已知风险时）docs/changes/active/<change-key>/（当本轮是新需求、bugfix、重构、流程变更时）docs/releases/（当本轮涉及版本发布或对外变更总结时）docs/archive/（当旧文档需要废弃但仍需保留历史时）docs/rules/README.md / AGENTS.md / spec-init.topology.yml要求：
当用户要的不是“占位 spec”而是“完整需求”时，requirements 至少覆盖：
不要只写一个首页或一个接口就停住，除非用户明确说只整理最小范围。
当用户要“完整设计”时，design 至少覆盖：
[待确认] 分离记录不要把 design 简化成“推荐某个框架”或“先做哪几个页面”。
对现有项目：
在结束前显式检查：
FR-* -> AC-*FR-* -> DES-*FR-* -> TEST-*FR-* / DES-* / TEST-* -> T-*至少形成一条完整链：
FR-001 -> DES-001 -> TEST-001 -> T-001
如果项目已经比较完整，不要只满足“至少一条链”。要尽量把高优先级需求都接入追踪链，而不是停在最小演示状态。
spec 应该随着项目推进不断完善。每轮需求澄清、设计决策、实现变更、测试补强后，都要检查：
docs/workflow/01-requirements/README.md 是否需要补新需求或修正边界docs/workflow/02-design/README.md 是否需要补新模块、新约定或新的异常链路docs/knowledge/ 是否需要补新的长期稳定真相docs/workflow/04-verification/README.md 是否需要补新的测试映射和回归策略docs/workflow/04-verification/01-test-strategy-and-quality-gates.md 是否需要更新测试层级、质量门禁或准出标准docs/workflow/04-verification/02-test-standards.md 是否需要更新测试代码、断言、隔离或 Mock 规则docs/workflow/04-verification/03-test-design-methodology.md 是否需要新增测试设计方法或模块风险模板docs/workflow/04-verification/04-test-case-matrix.md 是否需要登记新的长期测试用例docs/workflow/04-verification/05-regression-suite.md 是否需要更新回归套件和触发条件docs/workflow/04-verification/06-test-data-and-fixtures.md 是否需要沉淀新的 fixtures 或测试数据规则docs/workflow/04-verification/07-coverage-map.md 是否需要更新模块覆盖状态和测试缺口docs/workflow/05-tasks/README.md 是否需要把新发现的工作拆成任务docs/issues/ 是否需要新增未解决问题、阻塞项、风险或技术债docs/changes/ 是否需要新增或移动一个 change workspacedocs/releases/ 是否需要补一条版本说明docs/archive/ 是否需要归档被替代、已作废或不再生效的文档README.md、AGENTS.md、docs/rules/、spec-init.topology.yml 是否需要同步不要把 spec 当成“初始化时写一次，以后不更新”的静态文档。
把文档分成四层：
intake / requirements / design / implementation / verification / taskscontext / structure / behavior / referenceactive / completed / legacyissues / adr / releases / archive / rules默认规则：
docs/changes/active/<change-key>/docs/changes/active/<change-key>/docs/adr/docs/releases/vx.y.z.mddocs/issues/docs/archive/ 并记录替代关系不要只改当前状态不留痕，也不要只写变更记录却不更新当前状态。
在任务拆完、准备实现前，必须做一次一致性分析：
FR-* 是否有 AC-*DES-* 承接高优 FR-*TEST-* 验证高优 FR-*T-* 串起 FR / DES / TESTdocs/changes/active/<change-key>/ 是否记录了本轮背景、影响、验证和同步清单[待确认]实现完成后，必须做一次收敛检查：
docs/knowledge/完成状态的 change 不允许继续留在 docs/changes/active/：
docs/changes/active/<change-key>/ 移到 docs/changes/completed/（项目启用年月归档时使用 docs/changes/completed/YYYY/MM/<change-key>/）overview.md 或 impact.md 写清剩余条件docs/changes/README.md 索引、提交引用路径，以及必要的 releases / issues / ADR / archive 记录如果分析或收敛发现缺口，先补文档和任务，再继续实现或交付。
scripts/spec-init.sh 和 assets/templates/project/ 只是辅助资源，不是主工作流。
仅在以下情况才优先使用它们：
即使使用了脚本，也必须继续：
不能把“脚本跑完”当成任务完成。
如果用户不懂概念或没有说全：
如果用户说：
你必须：
不要假设这是“初始化项目”。
最终回复优先说明：
[待确认]FR -> DES -> TEST -> T 追踪链issues/ 还是 archive/references/doc-boundaries.md: 文档边界references/example-idea-to-docs.md: 从想法到 spec 的最小示例assets/templates/project/: 可选模板资源scripts/spec-init.sh: 可选目录骨架脚本examples/demo-app/: 最小示例项目优先把这些资源当参考和辅助，不要把它们当最终交付物。