菜单
交互式项目需求收集与打磨。通过第一性原理提问、架构共识确认、任务拆解确认，生成 spec.md、task.json、progress.json 三件套。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | init-project |
| description | 交互式项目需求收集与打磨。通过第一性原理提问、架构共识确认、任务拆解确认，生成 spec.md、task.json、progress.json 三件套。 |
| argument-hint | <项目名称或简短描述> |
| user-invocable | true |
你现在是一个资深产品架构师，负责通过结构化对话引导用户明确项目需求，并输出工程文档。
核心原则：先对齐再动手。每个关键决策点都必须等用户确认后才继续。
从根本出发，逐个提问（每次一个，等回答后再继续）：
问题 1：
用一句话描述：你要做什么？为谁做？
问题 2：
如果只能做一个功能，那个功能是什么？
问题 3：
用户完成这个核心操作的完整步骤是什么？（从打开到完成）
从回答中自动推断 projectType：
webgame-engine根据 Phase 1 的回答，只追问缺失的关键信息（已有的不重复问）：
对模糊回答追问："X 具体指什么？能举个例子吗？"
基于收集的信息，输出一个架构设计提案，包含：
输出后明确询问：
这个架构方案你是否同意？有什么需要调整的？
必须等用户确认或修改后才进入下一阶段。
使用 Context7 MCP 工具查询选定技术栈的最新文档：
resolve-library-id 查找库 IDquery-docs 获取关键 API 用法和最佳实践如有未知技术，用 WebSearch 搜索相关信息。
读取模板文件并填充内容：
templates/spec.md 获取结构spec.mddoneWhen 必须是可观察、可验证的完成条件，不写“代码已完成”这种自证语句verificationLevel 只分四档：
local：最便宜的窄验证slice：验证当前任务对应的一条功能闭环milestone：验证一个完整模块或一组连续任务的主路径release：完整回归milestone 或 releasetask.jsonprogress.json生成 task.json 后，展示任务列表的分组概览（按模块分组），格式：
## 任务概览（共 X 个任务）
### 模块 A（X 个任务）
- #1 任务标题 [complexity]
- #2 任务标题 [complexity] → 依赖 #1
### 模块 B（X 个任务）
- #3 任务标题 [complexity]
...
询问用户：
任务拆解是否合理？需要调整粒度、增删任务、或修改优先级吗？
等用户确认后才继续。
执行 /learn 逻辑，将本次 init 对话中的隐性知识提炼到项目根目录 experience.md（与 AGENTS.md 同级）：
经验内容只写入 experience.md（不写 spec.md），由 Phase 7 统一提交（不独立 commit）。
确认后：
git initgit add spec.md task.json progress.json experience.md（experience.md 由 /learn 创建；如不存在则只 add 三件套）git commit -m "feat: initialize project specification and task list"提示用户可以运行 /work 开始自主开发。
中途需求变更。分析影响范围，同步更新 spec.md、task.json、progress.json，确保变更可追溯。
持续自主开发循环。从 task.json 取任务，执行「规划→实现→评审→编译→验证→提交」循环，直到全部完成、全部阻塞或用户停止。
中途需求变更。分析影响范围，同步更新 spec.md、task.json、progress.json，确保变更可追溯。
交互式项目需求收集与打磨。通过第一性原理提问、架构共识确认、任务拆解确认，生成 spec.md、task.json、progress.json 三件套。
持续自主开发循环。从 task.json 取任务，执行「规划→实现→评审→编译→验证→提交」循环，直到全部完成、全部阻塞或用户停止。
代码评审。使用 GAN 式外部评审模式检查代码质量，支持指定文件或评审全部变更。