planlisted

# Executable Plan `plan` 把已批准 Spec 或足够明确的请求转成 **Executable Plan**：范围、阶段、验证路径、验证能力、下一步和 commit unit 清楚到可以直接交给 `implement` 或 `verify`。 它不负责发散需求，也不替代 Spec review。它默认不创建三文件；只有当前项目 recovery surface 已选择 three-file backend，或用户明确要求三文件时，才使用 `templates/` 下的 three-file 模板。 ## 语言策略 - 用户可见文本跟随用户语言；中文用户场景下，计划说明、阶段标题、验收说明、风险和下一步默认使用中文。 - 协议稳定优先：协议 token 如 `EXECUTABLE PLAN WRITTEN`、`Executable Plan`、`Verification path status`、`runnable | blocked`、`final_integration_claim`、skill 名、路径和命令可保留英文，必要时使用中文标��� + 英文 token。 - 不把 Plan 模板硬编码为中文-only；中文用户使用 `templates/task_plan.zh-CN.md`，英文或其他非中文用户使用 `templates/task_plan.md` 作为 default，并按用户语言翻译人类可见说明。 - 输出契约中的 `<... label in user's language>` 是占位说明，实际回复时必须替换成用户语言标签，不要原样输出。 ## 路由快照 - **Use when**: Spec 或请求已经清楚，但还缺可执行阶段、active slice、验证路径或 commit unit。 - **Do not use when**: 需求、边界或验证策略还不清；任务只是单点小补丁。 - **Route to**: 计划可执行后转 `implement`；只需证明当前状态时转 `verify`；工作面缺口转 `harness-builder`。 ## 目的 这个 skill 解决"计划只活在聊天里"的问题，同时避免把所有项目强绑到同一种状态文件。 - agent 被压缩或新会话开启后，仍能从项目 artifact 恢复执行边界和证明方式。 - 多人/多 agent 协作时，能回答"现在做到哪、下一步是什么"。 - 范围不会在追加讨论中悄悄扩张。 - 验证能力在计划阶段暴露，避免做完后才发现无法证明。 ## 何时使用 ### 触发信号 - `brainstorm` 写出并经用户批准的 Spec，需要变成可执行计划。 - 用户给出明确请求且任务非平凡：多步、多文件、跨边界或需要验证。 - 既有 Executable Plan 过期：active slice 名不副实、blocker 已变、next 不可执行。 - planning surface 中有真相但执行���同没同步。 - 用户说「写计划」「列阶段」「拆任务」「定义 active slice」「写 commit unit」。 ### 不要使用 - 需求、边界或验证策略仍模糊：先 `brainstorm`。 - 任务是单点改动，计划 artifact 反而是噪声。 - 既有 Executable Plan 仍真实、active slice 与 next 一致。 ### 路由规则 | 状态 | 下一步 | | ---