设计文档说明了目标，不一定能让接手的人立即实施。writing-plans 用来填补这一步：把已确认方案落到代码位置、数据接口和验证步骤，让后续 Agent 不必一边写代码一边重新猜需求。
安装并开始
在 Claude Code 会话内运行下面的插件命令，安装整套 Superpowers，保留各技能之间的衔接。Codex 用户在插件界面搜索并安装 Superpowers；两个客户端需要分别安装。安装后开启新会话，在项目目录里明确提出使用 writing-plans，再交代任务范围。
/plugin install superpowers@claude-plugins-official
从批准过的设计开始
以下是可按项目调整的首次输入：
使用 Superpowers writing-plans，基于 docs/specs/order-export.md 生成实施计划。先核对当前目录、测试框架和接口；每个任务写清修改文件、测试输入、预期失败与通过结果。保留导出权限、最大行数和时间格式约束，先写计划，不执行。
先提供设计文件和项目真实结构。没有决定的数据格式、上限或权限不适合悄悄藏进计划；应先补问或回到设计阶段。这个技能适合已经知道要做什么、需要明确怎么完成的任务，而不是替代需求澄清。
让任务具有可判断的边界
计划应先说明涉及哪些文件，各自承担什么责任，再按能独立理解和验证的交付拆分。例如订单导出可以分为权限与参数校验、数据读取、文件生成、下载交互；切分方式仍需符合当前项目，不能为了多几个任务把同一个接口拆得支离破碎。
每项任务写出新增或修改的路径、输入输出、测试位置和执行命令。测试应包含具体输入及预期，而不是只写“添加单元测试”；实现说明不能停在“处理错误”这种空话。官方流程强调先看到有意义的失败，再做最小实现，随后确认通过。
把跨任务约束留在显眼处
导出最大行数、时间格式、权限检查位置等约束可能影响多个文件。让 Agent 将这些要求统一写在计划中，并确认每个相关任务都遵守。边界情况也要落到相应任务的测试，而不只是文末一段提醒，否则后续执行很容易漏掉。
默认计划保存到 docs/superpowers/plans 下的日期文件。读完后检查路径是否存在、命令是否适合当前包管理器、任务之间的数据类型是否一致，以及是否还有占位符。一个新会话也应能依据计划找到设计与必要上下文。
计划交付后再决定执行方式
写完计划只是完成了规划。先审阅，再决定由当前会话实施，还是按任务使用独立子代理并审查。隔离工作区属于开始执行时要处理的问题，不必为了写计划先创建一套新环境。项目很小、只有一个明确改动时，也不必把它拆成冗长仪式；关键是任务是否足够具体，完成后能否证明满足设计。
计划能否交给下一位开发者：用一次模拟接手检验
假设已确认要给现有应用接入单点登录。计划不应只列“接入 OAuth、补测试、上线”；它应指出当前登录回调、会话存储、用户绑定和错误页分别在哪些文件，新接口收到什么参数、返回什么，旧账号如何关联新身份。把任务依赖写明：先验证提供方回调和状态参数，再处理账号绑定，最后更新界面与文档。每项都附可执行的测试命令和预期现象，而不只写“测试通过”。
请另一位没参加讨论的开发者只读计划，回答第一个要改的文件、测试在哪里、哪条约束不能破坏。如果回答仍依赖口头解释，计划缺了上下文。若仓库实际采用另一包管理器或测试脚本不存在，应在计划阶段修正，不要等实施时让 Agent 猜。计划可以标出待决的身份冲突策略，但该决策没确认前不应把后续任务写成已经可执行。具体路径、边界和通过标准比页数更重要。
交接前尝试打破计划
计划写完后，挑第一步和最有风险的一步做一次“接手演练”：在真实项目中确认命令、工作目录、依赖环境、文件路径和字段名都存在。一个使用者在长期使用中发现，表面完整的计划会漏掉虚拟环境激活、写错测试命令或让字段映射在步骤间漂移。可以让第二个阅读者专门尝试推翻计划：“按顺序执行时哪一步会先失败？哪项输入在后续被悄悄改名？”把发现直接修回计划，再交给实施会话；不要等执行到一半才让接手者猜。