用途：把一次已完成的探索固化为仓库内的“活”规格包，供未参与头脑风暴的智能体据此实现当前切片，并在规格更新后继续推进。流程定位为：头脑风暴→规格→版本路线图→可执行近期任务→实现→更新规格→下一版本。
主要能力：支持两种模式。Create 用于尚无规格包时，写出目标终态、完整路线图与首版可执行任务；Update 用于已有匹配包（含版本、任务或实验落地后），先读取并按 spec-structure.md 的更新行为处理，实现现实优先于过时规划。
使用方式：按 gather→inspect→classify→research→specify→decompose→review→summarize→stop 顺序执行，不先填模板。收集对话、笔记、代码、实验、URL 与旧规格；检查仓库以复用真实基础设施；区分已定、暂定、推测与矛盾项；保留重要外部参考；阅读 spec-structure.md 创建或更新项目目录，优先沿用既有文档约定，否则用 docs/<project-slug>/；阅读 task-design.md 拆分当前近期版本任务；阅读 quality-checklist.md 修正不一致；最后输出紧凑交接并停止。
适用场景：需要把探索转为持久规格、规划版本路线图、为后续智能体提供实现上下文时。
限制：不实现项目，不搭建生产架构，不启动 V0；仅允许澄清设计的小型 API 或伪代码草图。不静默解决重大产品问题，须标注不确定性；不把头脑风暴想法直接升格为架构决策；优先适配仓库已有方案而非全新栈；过早抽象需记录；每个项目或实验独立目录；仅在确实不适用时省略规格文件并在 README.md 文档地图说明原因；不得只写无终态的 V0 任务清单。若请求只是小编码任务、普通设计问题、主 README 重写或通用 Markdown 清理，不应使用本技能。最终回复需包含项目解读、文档路径、版本推进、当前版本及原因、主要架构决策、最大未决问题、对头脑风暴的分歧或顾虑、建议的下一实现任务，然后停止。