tsubaki-01/tsubaki_skills/extracting-coding-specs-from-plans

从计划提取编码规格

把材料中已确认的目标和行为落实到代码改动与验收，使编码者能够实施，不必重新猜测产品或架构决策。独立接收计划、需求材料或设计文档，不要求先使用其他研究或设计技能。

先确定依据

从当前请求和上下文确定源材料、目标项目、改动目标及输出位置。用户已给出的路径与决定优先；输出名称缺省时按主题推导并告知，无需为了命名参数中断工作。

有现有项目时，只检查与目标有关的代码、项目指导和测试。找到已有模块、公共接口、数据类型与关键调用链，区分要复用、修改和新增的位置。当前工作目录未必是目标项目，不能据此替用户选项目。

材料明确面向新项目时，依据已确认设计写规格，不虚构“现有代码”。缺少访问某部分代码的条件时，说明哪些落点尚未查证，继续整理有依据的部分。

把决定变成可实施约定

围绕本次改动写清：

• 用户要求的可观察行为，以及来自计划或代码的关键约束。
• 相关文件和模块各改什么、为什么改，已有实现如何复用。
• 编码者必须一致遵守的接口、数据、状态或模块之间的约定。
• 核心流程怎样经过这些位置，必要失败行为如何沿用或改变现有机制。
• 有先后依赖的实施顺序，以及怎样观察结果是否满足要求。

只展开这次任务涉及的内容。新类型、模块或依赖要能对应已确认需求，并说明现有结构为什么不足；参考材料中出现某种机制，不构成在项目中采用它的理由。

关键契约确有需要时给出函数签名、字段或事件形状。普通内部 helper、局部变量和不影响契约的实现组织交给编码者，不为填满模板预设全部类与方法。不要把通用 Web、数据库或分层示例变成项目必须采用的结构。

对于会影响实现的决定，保留可回查的材料位置或代码符号，清楚区分已确认要求、代码事实、假设和待定项。无需给每句话加标签，也不要把同一内容在多个表格中重复展开。

用 grilling 处理需要用户决定的疑点

先查材料和代码能回答的事实。以下问题无法据此确定时，使用 grilling 技能与用户进一步辨明：

• 用户期望的行为存在会改变结果的不同解释。
• 源计划与现有项目冲突，需要选择保留哪种行为或边界。
• 必须改变关键契约、模块职责或引入新的机制，现有材料却没有做出这一决定。

向 grilling 提供已查明的事实、具体分歧和取舍，不替用户选择答案。沿用本次已有的决策记录，不重复提问已经回答的问题。

把待决项的影响说明白：哪些规格内容依赖答案，哪些可以继续完成。未决选择可以出现在草案中，但不能被写成确认要求，也不能把依赖它的规格宣称为可直接执行。仅影响局部实现组织的问题不需要升级成产品或架构决策。

输出与完成

遵守用户要求的文档位置和格式；需要默认落盘位置时使用 {workspace}/.codex/{topic}/{topic}_coding_spec.md，其中主题从任务推导。用户已有模板时按其组织；没有模板时，让文档结构服务于本次改动。

需要组织文件改动、关键契约或验收条目时，按需参考 SPEC-FORMAT.md。小改动直接用简短规格即可，不必读取模板或填充无关章节。

交付前沿核心流程检查：已确认要求是否有对应改动和可观察的验收，引用的现有落点是否查证，新增内容是否有依据，重要待决项是否已经处理或清楚标明。记录适合本次改动的验证方法和现有命令，不因模板存在就要求全量测试。

最终说明规格路径、关键改动和仍影响实施的问题。这一技能交付开发规格；编写规格本身不代表代码已实现或测试已执行。