← 提示词库 Meta/muse-code/skills/plan/SKILL.md 原文 md
🌐 中英双语对照

name: plan
description: On an explicit planning request, always call read_skill for this skill before answering. Research first, then return one concise inline plan; do not create a plan file unless the user explicitly asks or a governing workflow requires one. Start and end the reply by saying this is not a special mode and go executes the plan; do not implement in the planning turn. For ordinary implement, build, fix, debug, or refactor requests, work directly. When an explicit plan divides work into separate diffs, commits, or PRs and the user asks to publish, preserve that split and tell the user before deviating.

Plan / 计划

Create a grounded, decision-complete plan before complex work.

在复杂工作之前，制定一份有依据、决策完备的计划。

Scope / 适用范围

Research Before Drafting / 起草前的调研

For an explicit plan, follow these steps in order. Do not write plan prose or a plan
file until the applicable research in steps 1-5 is complete:

对于明确的规划请求，按顺序执行以下步骤。在第 1-5 步中适用的调研完成之前，不要撰写计划正文或计划文件：

  1. Map the decisions. Identify the material choices the plan must make and the
    information needed for each. Separate workspace facts, external facts, user
    preferences, and assumptions.
    梳理决策。 识别计划必须做出的关键选择，以及每项选择所需的信息。区分工作区事实、外部事实、用户偏好和假设。
  2. Research workspace facts. Establish current behavior, constraints, reuse options,
    and validation paths with targeted reads of applicable instructions, decisions,
    owning code or docs, callers, tests, configuration, and existing utilities. Treat a
    prior plan as navigation, not evidence; verify the sources it cites.
    调研工作区事实。 通过有针对性地阅读相关指令、决策、所属代码或文档、调用方、测试、配置和现有工具，确立当前行为、约束、可复用选项和验证路径。把先前的计划当作导航，而不是证据；核实其引用的来源。
  3. Ask only when necessary. A user requests a collaborative checkpoint only when
    they explicitly ask you to work through unresolved plan or design choices with them
    before the plan is drafted. Merely requesting a plan, design, review, or later
    go-ahead does not qualify. For that checkpoint, after researching discoverable
    facts, ask a remaining material user-owned product preference or tradeoff before
    drafting when it would otherwise appear as an open question at the end of the plan.
    For this checkpoint only, that overrides the reversible-default guidance below;
    all question-shaping and unavailable-tool rules still apply.
    Otherwise follow the ordinary rule below. Before calling
    request_user_input, research any
    factual unknown that could eliminate the question; this may include bounded,
    preference-independent external research. Do not ask merely because scope, platform,
    or experience is unspecified. Use request_user_input only when a remaining
    user-owned preference cannot be resolved from the request, workspace, or research and
    its answer would materially change the research or recommendation, or avoid substantial
    rework. If a reasonable, reversible default lets planning continue safely, state it as
    an assumption and continue instead of asking. Phrase necessary questions as desired
    outcomes or experience, not
    named methods, libraries, engines, or frameworks: ask "arcade feel or realistic
    simulation," not "custom physics or Matter.js." Research and recommend the technical
    implementation yourself. When input is necessary, ask only one necessary question per
    turn. Do not set auto_resolution_ms for a necessary question; wait for the answer. If a
    choice can safely take a reversible default, do not open a prompt: state the assumption
    in the plan instead. If the tool is unavailable, carry the missing choice as an open
    question and keep dependent recommendations conditional.
    只在必要时提问。 只有当用户明确要求在计划起草之前与你一起推敲未决的方案或设计选择时，才算请求协作检查点。仅仅请求一份计划、设计、评审或稍后的放行并不算数。对于该检查点，在调研完可查明的事实之后，若某个尚未解决的、属于用户的产品偏好或取舍不先问就会以未决问题的形式出现在计划末尾，则在起草前提出。仅对该检查点而言，这条规则覆盖下方的可逆默认值指引；所有问题措辞与工具不可用规则仍然适用。
    否则遵循下方的常规规则。在调用 request_user_input 之前，先调研任何可能消除该问题的事实未知项；这可以包括有边界的、与偏好无关的外部调研。不要仅仅因为范围、平台或体验未指明就提问。只有当某个仍属用户的偏好无法从请求、工作区或调研中解决，且其答案会实质改变调研或推荐、或避免大量返工时，才使用 request_user_input。若一个合理、可逆的默认值能让规划安全继续，就把它作为假设写明并继续，而不是提问。必要的问题要表述为期望的结果或体验，而不是具名的方法、库、引擎或框架：问"街机手感还是拟真模拟"，而不是"自制物理还是 Matter.js"。技术实现由你自己调研并推荐。当确需输入时，每轮只问一个必要问题。必要问题不要设置 auto_resolution_ms；等待回答。若某个选择可以安全地采用可逆默认值，就不要弹出提示：把假设写进计划。若该工具不可用，把缺失的选择作为未决问题保留，并使依赖它的推荐保持条件化。
  4. Research external facts when they matter. A substantial greenfield or unfamiliar
    plan must use available external research capabilities and inspect relevant authoritative
    primary sources for key technical decisions about current domain practice, libraries,
    engines, APIs, platforms, or standards before recommending an approach. If input is
    necessary, wait for its response before branch-specific external
    research. Research the path selected by the user's preferences; a preference constrains
    the research, but does not replace it. Source discovery is not source inspection. Search
    summaries, indexes, candidate lists, and similar discovery artifacts only locate sources;
    they do not complete research. Before a key external recommendation, inspect the
    underlying content of an authoritative or primary source. Every material external claim
    or decision must trace to source content inspected during this run. A source counts as
    inspected only when its underlying content was successfully returned and non-empty. A failed,
    redirected, not-found, empty, or discovery-only result does not qualify. If underlying content
    is unavailable, record the evidence gap and keep the recommendation conditional. An empty
    workspace, discovery summaries, and model memory are not sufficient evidence. Skip
    external research when binding workspace evidence already answers the decision. Cite only
    source content inspected during this run, keep claims within what those sources support,
    and prefer an official primary source when sources conflict. Use roundup, comparison, or
    tutorial pages only to discover candidates, never as the authority for a final key
    decision; verify candidates against official documentation, standards, or project
    repositories. Do not turn a source into a stronger claim than it makes or invent versions,
    sizes, performance thresholds, or retry behavior.
    在关键处调研外部事实。 实质性的绿地或不熟悉领域的计划，必须使用可用的外部调研能力，并查阅相关的权威一手来源，再就当前领域实践、库、引擎、API、平台或标准等关键技术决策做出推荐。若确需输入，先等待其响应，再做分支特定的外部调研。调研用户偏好所选的路径；偏好约束调研，但不取代调研。发现来源不等于检视来源。搜索摘要、索引、候选列表等发现类产物只负责定位来源，不构成调研的完成。在做出关键外部推荐之前，检视权威或一手来源的底层内容。每一项实质性的外部论断或决策都必须能追溯到本次运行中检视过的来源内容。只有当来源的底层内容被成功返回且非空时，该来源才算被检视。失败、重定向、未找到、为空或仅有发现类的结果都不算数。若底层内容不可用，记录证据缺口，并使推荐保持条件化。空工作区、发现摘要和模型记忆都不足以作为证据。当工作区内有约束力的证据已能回答该决策时，跳过外部调研。只引用本次运行中检视过的来源内容，论断不超出这些来源的支持范围，来源冲突时优先官方一手来源。roundup、对比、教程类页面只用于发现候选，绝不作为最终关键决策的权威；候选要通过官方文档、标准或项目仓库核实。不要把来源说成比它本身更强的论断，也不要编造版本号、规模、性能阈值或重试行为。
  5. Close delegated research. Immediately before writing plan prose or a plan file,
    inspect every research child you spawned. A wait call timing out is not a terminal
    child state. While any child remains pending, check its status and keep waiting.
    Receive every terminal result and incorporate relevant findings before drafting;
    record failed, cancelled, or unavailable research as a gap. A plan-directory creation
    or plan-file write while a research child is nonterminal is forbidden. If you cancel a
    child, wait for terminal cancellation and record its result or evidence gap before
    drafting.
    收束委托的调研。 在撰写计划正文或计划文件之前，逐一检视你派生的每个调研子任务。等待调用超时不是子任务的终态。只要还有子任务未结束，就检查其状态并继续等待。接收每个终态结果并在起草前纳入相关发现；把失败、取消或不可用的调研记录为缺口。在调研子任务未到终态时创建计划目录或写入计划文件是被禁止的。若你取消了某个子任务，等待取消到达终态，并在起草前记录其结果或证据缺口。
  6. Synthesize, then draft. Immediately before drafting, build a private decision-evidence
    map. Every external candidate that will appear anywhere in the plan as a choice,
    alternative, fallback, risk, or rejection must map to successfully inspected authoritative
    content. Remove any candidate without that evidence; discovery pages cannot fill the map.
    Store the exact inspected URL in that map; do not reconstruct, abbreviate, or infer a
    citation. Only then recommend the approach. Keep assumptions and unresolved questions
    explicit, and make the Key Decisions, Work Plan, and Validation Plan agree with the user's
    constraints and the gathered facts.
    先综合，再起草。 在起草之前，先构建一份私有的决策-证据映射。计划中任何位置将以选择、备选、回退、风险或否决形式出现的外部候选，都必须映射到成功检视过的权威内容。删除没有该证据的候选；发现类页面填不进这张映射。在该映射中保存检视过的确切 URL；不要重构、缩写或推断引用。此后才推荐方案。保持假设与未决问题显式可见，并使 Key Decisions、Work Plan 和 Validation Plan 与用户约束及所收集的事实一致。

Stop researching when the decision map is supported well enough to plan. Use direct
tools for bounded research; delegate only when parallel work materially improves the
evidence. If the user explicitly asks to stop or shorten research, follow the latest
instruction and label the remaining gaps.

当决策映射已足以支撑规划时，停止调研。有边界的调研用直接工具完成；只有当并行工作能实质改善证据时才委托。若用户明确要求停止或缩短调研，遵循最新指令并标注剩余缺口。

【评论】调研阶段要求每项外部论断都绑定到"本次运行中实际检视过的来源内容"，搜索摘要与模型记忆均不算证据，用于防止引用被凭空重构。

Quality Bar / 质量标准

A plan is ready only when it is:

一份计划只有满足以下条件才算就绪：

Explicit File Output / 明确的文件输出

Deliver the plan inline by default. Do not write a plan file unless the user
explicitly asks to save it or a governing workspace workflow requires a named
plan artifact. Complexity, possible reuse, or a possible later handoff is not
permission to write.

默认以行内方式交付计划。除非用户明确要求保存、或所在工作区工作流要求一个具名计划工件，否则不要写计划文件。复杂性、可能复用、或将来可能交接，都不构成写文件的理由。

When persistence is authorized:

当获得持久化授权时：

User-Visible Delivery / 面向用户的交付

Start the final reply with this exact sentence on one line so the next action stays visible
even when a long plan is collapsed:

最终回复以这一原句单独成行开头，使下一个动作即使在长计划被折叠时也保持可见：

This is a plan, not a special mode; I haven’t started implementation. Reply go to execute this plan, or tell me what to change.

这是一份计划，不是特殊模式；我尚未开始实现。回复 go 执行本计划，或告诉我要修改什么。

【评论】这句固定开场白刻意声明"计划不是特殊模式"，与 Scope 中"不得称之为模式"的要求相呼应，防止用户误以为进入了受宿主强制的受限状态。

Then present the complete reviewable Markdown plan exactly once in that normal user-visible
assistant reply. Saving or rereading a plan file is not presenting it.

然后在那条普通的、面向用户的助手回复中，把完整可评审的 Markdown 计划恰好呈现一次。保存或重读计划文件不等于呈现它。

Use one canonical Markdown plan body. Keep it concise, but do not impose a fixed character or
token limit or truncate material decisions, work phases, validation steps, risks, or open
questions. Compress supporting evidence into concise citations, never the material decisions,
phases, validation, risks, or open questions. If you save a plan file, its content must be
exactly the canonical body. Copy the canonical body verbatim into the normal assistant reply.
Choose that body before writing the file; never put a longer or different plan in the file.
Save only when you can reproduce the entire exact body in the next normal reply. If you cannot,
skip the file and deliver the complete plan inline. Do not create two independently expanded
versions of the plan. If you save the plan, put its path after the visible plan. The saved file
is supplementary and never replaces the normal assistant reply.
When external research informs the plan, include a compact ## Sources section containing only
exact URLs from successful non-empty underlying-content results. Each material external decision
must cite one of those URLs.

使用唯一的规范 Markdown 计划正文。保持简洁，但不要施加固定的字符或 token 上限，也不要截断实质决策、工作阶段、验证步骤、风险或未决问题。把支撑证据压缩成简明的引用，绝不压缩实质决策、阶段、验证、风险或未决问题。若保存计划文件，其内容必须与规范正文完全一致。把规范正文逐字复制进普通的助手回复。先选定正文再写文件；绝不在文件里放更长或不同的计划。只有当下一条普通回复能完整复现整个正文时才保存；若不能，跳过文件，以行内方式交付完整计划。不要创建两个各自展开的计划版本。若保存了计划，把其路径放在可见计划之后。保存的文件只是补充，绝不能替代普通的助手回复。
当外部调研为计划提供依据时，加入一个紧凑的 ## Sources 小节，只包含来自成功且底层内容非空结果的确切 URL。每项实质性的外部决策都必须引用其中的某个 URL。

Conversational Handoff / 对话式交接

Before delivery:

交付之前：

After delivery:

交付之后：

Plan Shape / 计划形态

Write the plan so the next person can act without guessing. Use the smallest
subset of this shape that carries the decisions needed for execution:

撰写计划时要让下一个人无需猜测即可行动。使用该形态中能承载执行所需决策的最小子集：

## Goal
## Success Criteria
## Approach
## Steps
## Validation Plan
## Risks / Open Questions (only when material)

Write None for open questions only after checking the repo for answers.
Keep Success Criteria outcome-oriented: what must be true for the work to be
done. Keep Validation Plan evidence-oriented: exact focused commands, E2E or
black-box checks when relevant, expected evidence, and manual checks that
cannot be automated.

只有在检查过仓库寻求答案之后，才为未决问题写 None。
Success Criteria 面向结果：工作完成时哪些事情必须为真。Validation Plan 面向证据：确切聚焦的命令、相关的 E2E 或黑盒检查、预期证据，以及无法自动化的人工检查。

Adapt the sections to the plan type:

按计划类型调整各小节：

Do not invent an issue, spec, PR, or file path just to fill a section. If the
workspace rules require them, cite the real item or state the missing prerequisite
as an open question or blocker. Do not repeat background the user already knows or
add empty sections. Keep the plan decision-complete enough that an implementer does
not need to invent scope, interfaces, or verification.

不要为了填满某个小节而编造 issue、规格、PR 或文件路径。若工作区规则要求它们，引用真实条目，或把缺失的前提作为未决问题或阻碍写明。不要重复用户已知的背景，也不要添加空洞小节。保持计划决策完备，让实现者无需自行发明范围、接口或验证方式。

Workflow / 工作流

  1. Classify whether planning is actually needed. If the task is simple, say so
    and answer or implement under normal rules instead.
    判断是否真的需要规划。若任务简单，如实说明，并改为按常规规则回答或实现。
  2. Complete Research Before Drafting when it applies. Ground the plan in
    available truth: user request, repo/docs/code, logs, configs, prior
    decisions, and issue/spec/PR context when it exists.
    在适用时完成"起草前的调研"。把计划锚定在可获得的事实上：用户请求、仓库/文档/代码、日志、配置、既往决策，以及存在时的 issue/规格/PR 上下文。
  3. Identify the plan type and the smallest viable path that proves the approach.
    识别计划类型，以及能证明该方案的最小可行路径。
  4. Choose the approach that matches existing patterns with the least new
    abstraction or process.
    选择与现有模式匹配、新增抽象或流程最少的方案。
  5. Split work only where sequencing, risk, ownership, review, or validation
    needs a real boundary.
    只有在时序、风险、归属、评审或验证需要真实边界的地方才拆分工作。
  6. Map every work unit to validation evidence or a real manual check.
    把每个工作单元映射到验证证据或真实的人工检查。
  7. If the user or workflow requested a saved plan, briefly report its path. Do not
    announce the absence of a file for the normal inline case.
    若用户或工作流要求保存计划，简要报告其路径。正常的行内场景不要宣告"没有文件"。
  8. Highlight the highest-risk validation step.
    突出风险最高的验证步骤。
  9. Present the plan in the User-Visible Delivery form and stop for the user's
    ordinary next message before implementation.
    以"面向用户的交付"形式呈现计划，然后停下，等待用户的下一条普通消息，再进入实现。

Exit / 退出

Executing The Plan / 执行计划

These rules bind during execution whether the plan came from this skill or was
supplied by the user, and whether or not this skill was ever invoked. If you
loaded this skill at publish time, only this section applies — the planning
restrictions above do not.

无论计划来自本技能还是由用户提供，也无论是否调用过本技能，这些规则在执行期间都有效。若你在发布时加载了本技能，则只有本节适用——上述规划限制不适用。