Back to Details

make-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Make Plan

制定计划

You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.
你是一名ORCHESTRATOR。请创建适合LLM使用的分阶段计划，可在新的对话上下文中连续执行。

Delegation Model

委派模型

Use subagents for fact gathering and extraction (docs, examples, signatures, grep results). Keep synthesis and plan authoring with the orchestrator (phase boundaries, task framing, final wording). If a subagent report is incomplete or lacks evidence, re-check with targeted reads/greps before finalizing.
使用subagent完成事实收集与提取工作（文档、示例、签名、grep结果）。ORCHESTRATOR负责综合与计划撰写（阶段边界、任务框架、最终措辞）。如果subagent的报告不完整或缺乏证据，在最终确定前通过定向读取/grep重新核查。

Subagent Reporting Contract (MANDATORY)

Subagent报告协议（强制要求）

Each subagent response must include:
  1. Sources consulted (files/URLs) and what was read
  2. Concrete findings (exact API names/signatures; exact file paths/locations)
  3. Copy-ready snippet locations (example files/sections to copy)
  4. "Confidence" note + known gaps (what might still be missing)
Reject and redeploy the subagent if it reports conclusions without sources.
每个subagent的响应必须包含：
  1. 参考的来源（文件/URL）及已阅读内容
  2. 具体发现（准确的API名称/签名；准确的文件路径/位置）
  3. 可直接复用的片段位置（可复制的示例文件/段落）
  4. "置信度"备注 + 已知缺口（可能仍缺失的内容）
如果subagent上报的结论没有来源支撑，驳回并重新指派subagent执行任务。

Plan Structure

计划结构

Phase 0: Documentation Discovery (ALWAYS FIRST)

阶段0：文档调研（始终作为第一步）

Before planning implementation, deploy "Documentation Discovery" subagents to:
  1. Search for and read relevant documentation, examples, and existing patterns
  2. Identify the actual APIs, methods, and signatures available (not assumed)
  3. Create a brief "Allowed APIs" list citing specific documentation sources
  4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters)
The orchestrator consolidates findings into a single Phase 0 output.
在规划实施之前，部署"文档调研"subagent完成以下工作：
  1. 搜索并阅读相关文档、示例和现有模式
  2. 确定实际可用的API、方法和签名（而非假设存在的）
  3. 创建简短的"Allowed APIs"列表，标注具体的文档来源
  4. 记录所有需要避免的反模式（不存在的方法、已弃用的参数）
ORCHESTRATOR将所有发现整合为统一的阶段0输出。

Each Implementation Phase Must Include

每个实施阶段必须包含

  1. What to implement — Frame tasks to COPY from docs, not transform existing code
    • Good: "Copy the V2 session pattern from docs/examples.ts:45-60"
    • Bad: "Migrate the existing code to V2"
  2. Documentation references — Cite specific files/lines for patterns to follow
  3. Verification checklist — How to prove this phase worked (tests, grep checks)
  4. Anti-pattern guards — What NOT to do (invented APIs, undocumented params)
  1. 待实施内容 —— 设定任务时要明确从文档中复制内容，而非改造现有代码
    • 正面示例："Copy the V2 session pattern from docs/examples.ts:45-60"
    • 反面示例："Migrate the existing code to V2"
  2. 文档参考 —— 引用具体的文件/行号作为遵循的模式依据
  3. 验证检查清单 —— 如何证明该阶段已完成（测试、grep检查）
  4. 反模式防护 —— 禁止操作（自行发明的API、未归档的参数）

Final Phase: Verification

最终阶段：验证

  1. Verify all implementations match documentation
  2. Check for anti-patterns (grep for known bad patterns)
  3. Run tests to confirm functionality
  1. 验证所有实现与文档一致
  2. 检查反模式（grep已知的错误模式）
  3. 运行测试确认功能正常

Key Principles

核心原则

  • Documentation Availability ≠ Usage: Explicitly require reading docs
  • Task Framing Matters: Direct agents to docs, not just outcomes
  • Verify > Assume: Require proof, not assumptions about APIs
  • Session Boundaries: Each phase should be self-contained with its own doc references
  • 有文档≠用了文档：明确要求阅读文档
  • 任务框架很重要：引导代理参考文档，而非仅给出结果要求
  • 验证 > 假设：要求提供证据，而非假设API的情况
  • 会话边界：每个阶段都应该独立自包含，附带自身的文档参考

Anti-Patterns to Prevent

需要避免的反模式

  • Inventing API methods that "should" exist
  • Adding parameters not in documentation
  • Skipping verification steps
  • Assuming structure without checking examples
  • 自行发明"应该"存在的API方法
  • 添加不在文档中的参数
  • 跳过验证步骤
  • 不检查示例就假设结构