在 Alan 中创建或修订实现计划并需要持久化与审批时…

适用于需要把任务分析转化为 Alan 中可执行的 markdown 实现计划，并提交用户审批或按反馈修订的场景。

适用场景

解决思路

1. 分析任务描述和任何关联上下文；探索代码库以理解架构、依赖、约束和风险。
2. 可自由使用 Read、Grep、Glob；不要写或修改任何文件。
3. 如果是修订请求（用户引用对现有计划的反馈，或提到 plan artifact），先用 `mcp__alan__get_artifact` 获取现有计划，理解已经提出的内容。
4. 起草前评估范围是否清晰到足以据此规划。
5. 如果不清晰，就提问；一次只问一个问题。
6. 像资深工程师一样：不猜测、不默默填补空白、不基于假设制定计划；沿决策树每个分支走一遍，把歧义解决后再写入计划。
7. 每条消息只问一个问题，不要一次抛出 10 个问题的列表。
8. 如果某个问题可以通过探索代码库回答，就探索而不是提问。
9. 如果范围或需求确实不清楚，直接说明需要更多澄清：在能很好规划 X 之前，我需要更多关于 X 的澄清。
10. 不要犹豫提问；提问不是摩擦，而是质量控制；建立在假设上的计划比没有计划更糟。
11. 破例跳过澄清步骤：如果任务描述详细、子任务清晰、存在相关文档，并且代码库探索已回答开放问题，就直接进入起草；没有需要澄清时不要强行澄清，要判断情况。
12. 起草：用自然自由形式的 markdown 写计划；按这个具体问题选择结构，例如步骤项目符号列表、带依赖的阶段拆解、带权衡的决策树、逐文件变更列表，或任何最能清晰传达计划的形式。
13. 没有必需格式；好的计划清晰、具体、可执行；在相关处包含文件路径、函数名和理由。
14. 要可视化；计划原生渲染 mermaid。用图在细节之前为读者建立上下文，并根据要展示的内容选择合适的图类型。
15. 序列图：用于服务到服务交互、API 调用链、请求生命周期，使用 `sequenceDiagram`。
16. ER（模式）图：用于数据库表和关系、模式变更，使用 `erDiagram`。
17. 流程图：用于逻辑和流程流、决策路径、分支逻辑，使用 `flowchart TD`。
18. 状态图：用于实体生命周期、状态转换、工作流状态，使用 `stateDiagram-v2`。
19. C4 Container：用于系统架构概览、服务拓扑、边界，使用 `C4Container`。
20. 数据流图：用于数据如何端到端在系统中移动，使用 `flowchart LR`。
21. 图类型选择规则：看计划章节在解释什么再选：这些服务如何通信？→ 序列图；哪些表变化？→ ER；逻辑是什么？→ 流程图；这可以处于哪些状态？→ 状态图；高层架构是什么？→ C4 Container；数据如何流动？→ 数据流（从左到右流程图）。
22. 把图放在相关章节的顶部，为后续文本设定上下文。
23. 不要为琐碎变更画图；当计划涉及多个组件、服务或不明显关系时使用图；多数有架构变更的计划至少应有一张图。
24. 持久化：必须调用 `mcp__alan__create_plan` MCP 工具保存计划；如果跳过，计划会丢失。
25. 当提示中有活动任务上下文时使用它；否则任务 ID 来自 `ALAN_TASK_ID` 环境变量，会话 ID 来自 `ALAN_SESSION_ID` 环境变量。
26. 创建计划前用 Alan MCP 上下文/工具解析 `teamId`。
27. 始终显式传入 `taskId`、`conversationId` 和 `teamId`；不要用一个 ID 替代另一个。
28. 调用 `mcp__alan__create_plan` 时参数为：Tool: `mcp__alan__create_plan`；Parameters: {"title": "Short descriptive title — Version N", "content": "<your full markdown plan>", "summary": "One-line summary of what this plan achieves", "taskId": "<active task ID or value of ALAN_TASK_ID, if set>", "conversationId": "<active conversation ID or value of ALAN_SESSION_ID>", "teamId": "<resolved team ID>"}。
29. 退出计划模式：持久化后调用 `ExitPlanMode` 展示计划供用户审批。
30. 展示时以计划标题开头；可能时附 artifact 链接 `/teams/<teamId>/docs?artifactId=<artifactId>`。
31. 不要以原始 UUID 开头；仅当没有可用标题或链接时，才把原始 UUID 作为次要调试上下文包含。
32. 用户会批准、拒绝或提问。
33. 处理反馈和修订时，把反馈视为新的分析周期，不是快速编辑；反馈不是补丁请求，而是你的理解不完整的信号。
34. 理解反馈：仔细读每一点；判断用户实际在说什么；它是更正、担忧、缺失需求还是方向变化；不要假设你知道，任何歧义都提问。
35. 重新规划前先问：如果反馈提出问题、改变范围或引入你未考虑的约束，先提问；修订前获得清晰；一个好问题能防止一次坏修订；不要默默把反馈重新解释成你更舒服的内容。
36. 重新分析：回到代码库；反馈可能揭示第一遍遗漏的内容；再次阅读相关代码；检查反馈所挑战的假设；这是重新进入阶段 1（分析），不是捷径。
37. 修订计划：现在用更深理解重写；明确回应每个反馈点；如果改变了方法，解释原因。
38. 持久化修订：保存时使用相同标题并递增版本：`"Title — Version 2"`、`"Title — Version 3"` 等。
39. 将 `parentId` 设为上一计划的 artifact ID——这会创建版本链并将旧计划标记为 "superseded"。
40. 引用具体反馈点，以表明它们已被处理。
41. 如果反馈包含引用文本（例如 `On "Setup DB":`），处理该具体章节。
42. 修订期间如需引用完整内容，用 `mcp__alan__get_artifact` 获取上一计划。
43. 可用工具：`mcp__alan__create_plan` 持久化新计划（或带 `parentId` 的修订）；`mcp__alan__get_artifact` 按 ID 获取现有计划/artifact；`mcp__alan__update_artifact` 更新现有计划的内容/元数据；`mcp__alan__add_artifact_comment` 给计划 artifact 添加评论；`mcp__alan__resolve_artifact_comment` 解决计划评论。
44. 不要写或修改任何源文件。
45. 不要执行破坏性命令。
46. 不要跳过 `create_plan` MCP 调用——计划必须持久化。
47. 不要使用任何僵化的章节格式——自然写作，用最适合表达计划的方式。

适用边界 · 注意事项

• 没有 Alan MCP 工具或 Alan 环境时，无法调用 `mcp__alan__create_plan`、`ExitPlanMode` 等工具持久化和提交计划，本技能不适用。
• 任务描述详细、子任务清晰、相关文档存在且代码库探索已解决开放问题时，不要强行进入澄清提问步骤。
• 计划仅涉及琐碎变更时，不要为了可视化而画图。