planify

规划访谈

你要围绕用户的需求和技术拆分持续提问，直到将最初的想法或请求梳理成清晰的计划。你把文件编写工作交给技能 planify-write-plan。由你负责思考，planify-write-plan 只负责整理格式。

一个计划可以涵盖多个功能。

预期交付物是一份任务清单：

• 易于回顾和理解
• 开发完成后易于进行代码审查
• 整体规模与一个提交大致相当

参数

$ARGUMENTS = 自然语言描述的请求（可选）。如果为空，先询问用户想要规划什么，再开始探索。

阶段 1 — 探索

在提出任何问题之前，先了解现有情况。分析当前分支和 Git 工作区中已经完成的更改。 当你了解已有内容、使用的技术以及项目惯例后，本阶段结束。

1. 阅读 CLAUDE.md / AGENTS.md 和项目惯例（例如 .claude/rules/、贡献指南、样式或测试文档）。
2. 如有需要，加载可能帮助你了解项目和请求的现有技能。
3. 在一条消息中，根据初步判断的领域，在不同区域启动多个 Agent 子代理（subagent_type=Explore）（例如模型 + URL / 视图 + 模板 / 测试 + 服务）。每个子代理返回简短摘要和关键路径，绝不大段复制内容。
4. 查明项目使用的技术（pyproject.toml、package.json、模板），以便指导提问和网页搜索。
5. 针对性地搜索网页，查找与任务拆分相关的最佳实践和设计模式。

不要展示原始摘要——它只用于提出有针对性的问题。

继续处理

使用 .task/<KEY>/ 存放任务：使用 Jira 编号；如果没有 Jira，则使用根据需求生成的简短名称。 在本次会话中复用指定目录，并在 ticket.md 存在时读取它。如果有多个合适的任务目录，询问用户要使用哪一个。

确定前缀：从请求中提取一个简短的 slug（小写、用连字符连接，包含 2 到 5 个有意义的词）。 它用于命名任务的子目录：.task/<KEY>/<prefix>/。继续处理时复用已有目录。 如果 .task/<KEY>/<prefix>/plan.md 已存在：将其作为上下文阅读，不要重复提问已确定的问题， 只针对新增内容和更改提问。

粘贴的反馈（报告注释）

如果消息中包含由 report-render 生成的反馈块——以 # Retours — … 开头，后面是一组 ## Retour N — <ancre> 条目（包含一段引用的 blockquote，随后是 Commentaire : 行）——应处理这些反馈，而不是进行完整访谈：

1. 确定任务目录和前缀，然后加载目标计划：如果 .task/<KEY>/<prefix>/plan.md 存在，则加载该文件；否则加载当前对话中的计划。
2. 对每条反馈，根据锚点（<ancre> = 任务 ID T3 或章节标题）和 blockquote 中的文字，在计划中定位被引用的段落。
3. 直接应用明确的反馈。只针对含糊的反馈重新提问（将开放问题分组为相互独立的批次，并给出建议答复——遵循阶段 2 的相同规则）。
4. 重新委托 planify-write-plan 编写计划（阶段 4）。
5. 结束处理：在对话中简要汇总变更——按反馈说明哪些内容被添加 / 修改 / 删除。简明扼要，不创建任何文件。

Phase 2 — 询问

持续提问，直到双方达成共识，并充分梳理需求和请求。 当再没有任何重要决策悬而未决时，本阶段结束。

• 提出开放式问题，绝不提供封闭选项或菜单（不使用 AskUserQuestion）。
• 将相互独立的问题分批提出：同一批中的问题不得相互依赖。不要一次性抛出所有问题——分多批进行，等用户回答完一批后再提出下一批。
• 每个问题都附上你建议的答案，并说明理由。建议的答案应是最合理的选择（良好的做法、最佳实践、良好的设计模式等），而不是最简单或最快的选择。
• 按层级逐步梳理决策树，从最重要的决策开始，再深入细节：每一层中，相互独立的问题组成一批；依赖其他问题的部分留待下一批，直到梳理完与需求相关的所有分支。
• 先查找，再提问：如果能通过阅读代码找到答案，就阅读代码。积极主动，尽可能多地查阅代码，只有在找不到答案时才提问。
• 避免多余内容：找出并删除所有非必要内容。
• 只在重大决策上探讨多种方案：当架构决策会真正改变拆分方式时，列出 2 或 3 种方案，说明各自的权衡并给出建议，然后持续提问，直到做出决定。其他情况下，只需提出一个附带建议答案的问题。
• 明确术语：遇到含义模糊或过于宽泛的术语时，提出一个明确的术语并统一使用；通过具体边界场景检验业务规则；结合代码核实（“你的代码会取消整笔订单，但你说的是部分取消——究竟是哪一种？”）。
• 明确上下文：必要时结合代码。指出要查看的文件（格式应支持 IDE 显示链接并跳转到对应行）。

Phase 3 — 总结并确认

在用户确认总结之前，不得写入任何文件，也不得调用 `planify-write-plan`。

简要总结：功能、按顺序排列的任务标题以及关键决策。 明确询问“可以，还是需要调整？”（开放式问题）。如有需要，继续迭代。

第 4 阶段 — 交接

如果计划中的任务少于 4 项，询问用户是否只想查看计划，然后再进入开发阶段。

否则，在对话中整理一份结构化摘要，然后调用技能 planify-write-plan （该技能会将其整理为 .task/<KEY>/<prefix>/plan.md 和 tech.md）。摘要包含：

• 目录 — 为此任务选择的确切路径 .task/<KEY>/<prefix>/。
• 背景 — 说明原因，涵盖相关功能；如有不在范围内的内容，也需注明。
• 任务 — 按顺序列出。每项任务包括：标题、待完成工作的描述（包含适当的技术细节，并可附上代码片段以帮助理解），以及验收约束 （需满足的条件清单，无论这些条件是否可观察）。
• 技术 — 要创建或修改的文件；要复用的现有代码模式（及其位置）；简要 ADR（背景、决策、未选用的替代方案、后果）；横向事项（迁移、权限、功能标志、测试数据）。

文件写入后，告知用户可以通过 .task/<KEY>/<prefix>/plan.md 进入原生计划模式继续操作。

同时说明，用户也可以请求计划的 HTML 报告（« 给我生成一份 HTML 报告 »）：此时技能 report-render 会将摘要整理为 .reports/<prefix>.report.html，可在浏览器中阅读。