workflow

标准工作流

1. 仔细思考问题，阅读相关文件，并将计划写入 specs/[timestamp]-[feature-name].md，其中 [timestamp] 使用 YYYYMMDDThhmmss 格式，[feature-name] 使用 kebab case。
2. 让首屏内容实用：状态、负责人、一句话说明、当前形态、目标形态和验证依据。
3. 添加实施任务清单，随着工作完成逐项勾选。
4. 自主分小步执行，并设置小型检查点。只有在计划涉及相互竞争的产品或架构选择、需求尚未明确、破坏性操作或范围过广的风险时，才暂停并征求用户意见。
5. 对于有多种可行方案、涉及 3 个以上文件或架构调整的非简单变更，请在实施前通过前后差异和 ASCII 图展示不同方案。请参阅 change-proposal。
6. 随进度勾选已完成的清单项，并将进度备注保持在较高层级：已更改、已验证、剩余工作、受阻事项。
7. 尽可能缩小每项任务和代码变更的范围。避免无关清理和大范围重构。
8. 最终交接前，针对已修改的文件运行 post-implementation-review。借此检查过时的抽象、无效路径、不变量偏移、命名问题和验证缺失。
9. 在规范文档中添加评审部分，总结变更、评审发现、验证情况和相关后续工作。

何时应用此技能

在以下情况下使用此模式：

• 在 specs/ 中为非简单功能创建带时间戳的规划规范。
• 编写代码前，制定以清单为基础的实施计划。
• 编写规范时尊重维护者的时间，确保首屏清晰、节奏合理。
• 将工作拆分为小而简单的检查点来执行，并提供较高层级的进度更新。
• 仅在产品选择或架构选择尚未明确、涉及破坏性操作或存在范围过广的风险时暂停。
• 交接工作前执行实施后评审。
• 结束工作时，在规范中添加评审总结。

规范文档位置

所有规范文档都放在根目录的 /specs/ 中。不要在 apps/ 或 packages/ 中创建嵌套规范文档。

主题需要时，可以编写较长的规范文档。不要按行数拆分。只有当一个文件混合了不同读者任务（包括总体架构、历史讨论、实施日志、交接提示和当前执行路径）时，才拆分文件、添加当前执行部分或创建配套的执行规范。

提示词和交接材料可以放在规范文档旁边，并使用 .prompt.md、.handoff.md 或 .execute.md 等明确后缀。它们应链接回规范文档的正式版本；除非后缀明确表明，否则不应将其视为当前实施计划。