Back to Details

planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Planning

规划

Implements dynamic planning for flexible user journeys. Instead of forcing a rigid workflow, this skill discovers what the user wants, proposes a plan, and adapts as needed.
实现动态规划，支持灵活的用户旅程。该Skill不会强制执行僵化的工作流，而是会识别用户需求、提出计划，并根据需要进行调整。

Phase 1: Brainstorming

第一阶段：头脑风暴

Goal: Understand what the user wants to accomplish.
First message rules:
  • If the user describes a goal, ask one clarifying question at most — then move to Phase 2.
  • Do NOT list capabilities, pipeline steps, or menus unprompted.
  • Do NOT read files or run tools unless the user asks.
During brainstorming:
  • The goal of this phase is to determine which skills and tools to use to fulfill the user's intent. Every question you ask should help you decide whether a specific skill or tool belongs in the plan.
  • Before asking questions, review the name, description, and details of each skill in your context (do not actually load the full SKILL.md files yet), as well as the available MCP tools. Identify what information you'd need from the user to decide if each skill/tool is relevant.
  • Ask only questions whose answers would include or exclude a skill or tool from the plan. Do not ask generic or open-ended questions. Each question should map to a planning and skill-selection decision.
  • When evaluating whether to include a skill, check if ALL of the skill's responsibilities are satisfied, not just the primary one. If a skill handles multiple decisions (e.g., technique selection AND model selection), include it if any of those decisions remain unresolved.
  • Move to Phase 2 as soon as you can determine which skills and tools the plan needs. Don't over-ask — 1 to 3 targeted questions should be sufficient in most cases.
目标： 了解用户想要完成的任务。
首条消息规则：
  • 如果用户描述了目标，最多询问1个澄清问题，然后进入第二阶段。
  • 不要在用户没有要求的下列出功能、流程步骤或菜单。
  • 除非用户要求，否则不要读取文件或运行工具。
头脑风暴过程中：
  • 本阶段的目标是确定要使用哪些Skill和工具来满足用户意图。你提出的每个问题都应该能帮助你判断某个特定Skill或工具是否应该纳入计划。
  • 提问前，请查看上下文中每个Skill的名称、描述和详情（暂时不要加载完整的SKILL.md文件），以及可用的MCP工具。明确你需要从用户处获得哪些信息，才能判断每个Skill/工具是否相关。
  • 仅提问那些答案能决定是否将某个Skill或工具纳入/排除出计划的问题，不要提出通用或开放式问题。每个问题都应该对应一个规划和Skill选择决策。
  • 评估是否要纳入某个Skill时，请检查该Skill的所有职责是否都能满足，而不仅仅是主要职责。如果某个Skill需要处理多项决策（例如技术选型 AND 模型选型），只要其中任何一项决策尚未确定，就将其纳入计划。
  • 一旦确定计划需要哪些Skill和工具，就立即进入第二阶段。不要过度提问，大多数情况下1到3个针对性问题就足够了。

Phase 2: Plan Generation

第二阶段：计划生成

Goal: Propose a structured plan for the user to review.
Generate a plan as a numbered list of tasks. Each task has:
  • A short name
  • A one-sentence description of what happens
  • Which skill handles it (if applicable)
Format:
Based on what you've described, here's what I propose:

1. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*
2. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*
3. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*

Does this plan look right, or would you like to change anything?
Rules for plan generation:
  • Before presenting a plan, always read 
    references/skill-routing-constraints.md
    and validate the plan against it.
  • Draw tasks from the skills available in your context. Use each skill's name and description to determine relevance.
  • Only offer capabilities that are covered by an available skill. Do not offer, suggest, or imply the ability to help with tasks that no skill supports. If the user needs something outside the available skills, explain that it is not supported.
  • Not every plan needs every skill. Tailor the plan to the user's actual intent.
  • If the user already has artifacts (e.g., a trained model), skip the steps that produce them.
  • Keep plans short. Only include tasks that are necessary.
When the user approves the plan, write it to 
PLAN.md
using the following format. Save the file under the project directory structure defined by the directory-management skill, if available.
markdown
undefined
目标： 提出结构化计划供用户审核。
生成的计划为编号任务列表，每个任务包含：
  • 简短名称
  • 一句任务内容描述
  • 负责处理该任务的Skill（如适用）
格式：
Based on what you've described, here's what I propose:

1. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*
2. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*
3. ⬜ **[Task Name]** — [What happens]. *(Skill: [skill-name])*

Does this plan look right, or would you like to change anything?
计划生成规则：
  • 提交计划前，请务必读取
    references/skill-routing-constraints.md
    ，并对照该文件验证计划是否符合要求。
  • 任务应从上下文中可用的Skill中选取，参考每个Skill的名称和描述判断相关性。
  • 仅提供可用Skill覆盖的功能，不要提供、建议或暗示可以帮助完成没有对应Skill支持的任务。如果用户需要的内容不在可用Skill的支持范围内，请说明该需求暂不支持。
  • 不是每个计划都需要用到所有Skill，请根据用户的实际意图定制计划。
  • 如果用户已经有了对应的产出物（例如已训练好的模型），则跳过生成该产出物的步骤。
  • 保持计划简洁，仅包含必要的任务。
用户批准计划后，请使用以下格式将计划写入
PLAN.md
。如果有目录管理Skill，请按照该Skill定义的项目目录结构保存文件。
markdown
undefined

Plan

Plan

  1. ⬜ [Task Name] — [Description]. (Skill: [skill-name])
  2. ⬜ [Task Name] — [Description]. (Skill: [skill-name])
  3. ⬜ [Task Name] — [Description]. (Skill: [skill-name])

**Status indicators:**

- ⬜ Not Started
- 🔄 In Progress
- ✅ Completed

Update `PLAN.md` whenever a task's status changes.

---
  1. ⬜ [Task Name] — [Description]. (Skill: [skill-name])
  2. ⬜ [Task Name] — [Description]. (Skill: [skill-name])
  3. ⬜ [Task Name] — [Description]. (Skill: [skill-name])

**状态标识：**

- ⬜ 未开始
- 🔄 进行中
- ✅ 已完成

每当任务状态发生变化时，请更新`PLAN.md`。

---

Phase 3: Plan Iteration

第三阶段：计划迭代

Goal: Refine the plan until the user approves it.
  • If the user suggests changes, regenerate the plan incorporating their feedback.
  • If the user approves (e.g., "looks good", "let's go", "yes"), begin execution by handing off to the first task's skill.
目标： 优化计划直到用户批准。
  • 如果用户提出修改建议，请结合用户反馈重新生成计划。
  • 如果用户批准（例如“看起来不错”、“开始吧”、“是的”），则交接给第一个任务对应的Skill开始执行。

Execution

执行

Once the plan is approved:
  1. Before starting a task, update its status in 
    PLAN.md
    to 🔄 (In Progress).
  2. If the task maps to a skill, load that skill's full SKILL.md before doing any work. Do not attempt the task from general knowledge — always defer to the skill's instructions.
  3. Execute the task by following the loaded skill's workflow.
  4. When the task completes, update its status in 
    PLAN.md
    to ✅ (Completed), then briefly confirm completion and move to the next task.
  5. If the user interrupts with a new request mid-execution:
    • Completed tasks are immutable — DO NOT ever modify completed tasks in the plan. You are allowed to only modify tasks that are in progress or not started.
    • Regenerate the remaining tasks to incorporate the user's new input.
    • Present the updated remainder for approval before continuing.
计划获批后：
  1. 开始某个任务前，将其在
    PLAN.md
    中的状态更新为🔄（进行中）。
  2. 如果该任务对应某个Skill，请先加载该Skill的完整SKILL.md文件再开始工作，不要依靠通用知识尝试完成任务，始终遵循Skill的操作说明。
  3. 按照已加载Skill的工作流执行任务。
  4. 任务完成后，将其在
    PLAN.md
    中的状态更新为✅（已完成），然后简要确认完成情况，再进入下一个任务。
  5. 如果用户在执行过程中打断并提出新需求：
    • 已完成的任务不可修改，绝对不要修改计划中已完成的任务，仅允许修改进行中或未开始的任务。
    • 重新生成剩余任务，纳入用户的新输入。
    • 继续执行前，先提交更新后的剩余计划给用户审批。

Plan Completion

计划完成

When all tasks in the plan are done:
"We've completed everything in the plan. What would you like to do next?"
This re-enters Phase 1 (Brainstorming) for a new goal. There is no terminal state — the conversation continues as long as the user wants.
计划中所有任务都完成后：
"We've completed everything in the plan. What would you like to do next?"
此时会重新进入第一阶段（头脑风暴），承接新的目标。本流程没有终止状态，只要用户有需求，对话就会持续进行。

References

参考资料

Always load the corresponding reference plan based on the customer intent to learn about what a typical plan looks like, and then adjust based on customer's needs.
  • references/model-customization-plan.md
    — A typical end-to-end model customization/finetuning plan for reference when generating plans.
  • references/skill-routing-constraints.md
    — Mandatory inclusion rules, ordering constraints, and skill boundary rules. Always consult when generating or modifying a plan.
请始终根据用户意图加载对应的参考计划，了解典型计划的结构，再根据用户需求进行调整。
  • references/model-customization-plan.md
    — 典型的端到端模型定制/微调计划，生成计划时可参考。
  • references/skill-routing-constraints.md
    — 强制纳入规则、排序约束和Skill边界规则，生成或修改计划时务必参考。