plan-it

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan it

规划

Repository identity

仓库身份

Before GitHub access, Git writes/network operations, delegation, or scheduling, read and follow the shared identity instructions. Apply them to invoked upstream skills and every worker.

在访问 GitHub、执行 Git 写入或网络操作、委派或调度之前，读取并遵循共享身份说明。这些规则也适用于所调用的上游 skill 和每个 worker。

User questions

用户问题

Before asking or relaying any user question, read and follow the user question rules.

Requires spec-it, ticket-it, their prerequisites, and subagent support.

Invoking this skill authorizes publishing the spec and approved tickets through those skills. Preserve their user confirmation and approval steps. Creating or editing this skill does not start publication.

在提出或转交任何用户问题之前，读取并遵循用户问题规则。

需要 spec-it、ticket-it、它们的前置依赖以及 subagent 支持。

调用此 skill 即表示授权通过上述 skill 发布 spec 和已批准的 ticket。必须保留其中的用户确认与批准步骤。创建或编辑此 skill 不会启动发布。

Orchestrate

编排

Read repository instructions and resolve the absolute repository path, target GitHub repository, tracker configuration, and both local skill paths. Resolve missing prerequisites or an ambiguous target before publication.
Read and follow
```
spec-it
```
and its upstream dependencies directly in the parent chat, using the Skill tool when available. This keeps the current discussion and codebase understanding available to
```
to-spec
```
. Preserve its test-seam confirmation and wait for successful publication with the verified issue URL and labels.
Independently fetch the returned issue and verify its target repository, that it is an issue rather than a pull request, and that it has
```
spec
```
and a
```
status/
```
label. Start the next stage only after
```
spec-it
```
reports success and this verification passes.
Start a fresh worker for
```
ticket-it
```
with conversation inheritance disabled, such as
```
fork_turns="none"
```
when supported. Supply its absolute skill path, repository path, verified parent issue URL, tracker configuration, and any user constraints or decisions absent from the published spec. Have it read and follow that skill and its upstream dependencies, fetching the parent's full body and comments. Require the proposed breakdown for user approval before publication unless that exact breakdown was already approved. Handle input as described below and wait for its verified completion report.
Return the parent and child URLs with their blockers and verification results. Claim completion only when both stages succeeded and every approved slice has a verified ticket.

读取仓库说明，并确定绝对仓库路径、目标 GitHub 仓库、tracker 配置以及两个本地 skill 路径。在发布前解决缺失的前置依赖或目标不明确的问题。
在主聊天中直接读取并遵循
```
spec-it
```
及其上游依赖，并在可用时使用 Skill tool。这样可以让
```
to-spec
```
获得当前讨论和代码库的相关信息。保留其 test-seam 确认环节，并等待发布成功，同时获取经过验证的 issue URL 和标签。
独立获取返回的 issue，验证其目标仓库，确认它是 issue 而非 pull request，并确认它具有
```
spec
```
和
```
status/
```
标签。只有在
```
spec-it
```
报告成功且验证通过后，才能进入下一阶段。
为
```
ticket-it
```
启动一个全新的 worker，并禁用对话继承，例如在支持时设置
```
fork_turns="none"
```
。向其提供绝对 skill 路径、仓库路径、经过验证的父 issue URL、tracker 配置，以及任何未体现在已发布 spec 中的用户约束或决定。让它读取并遵循该 skill 及其上游依赖，同时获取父 issue 的完整正文和评论。除非确切的拆分方案此前已获批准，否则必须先提交拟议的拆分方案供用户批准。按照下文所述处理输入，并等待经过验证的完成报告。
返回父级和子级 URL，并附上阻塞项和验证结果。只有两个阶段均已成功，且每个已批准的拆分项都有经过验证的 ticket 时，才能声明完成。

User input

用户输入

Give the ticketing worker these instructions: when a delegated skill needs a user answer or approval, return to the parent with the question, relevant draft or options, current progress, and existing artifact URLs. Pause dependent work until the parent supplies the user's response.

Ask the question in the parent chat through the User questions procedure and wait for the user. Relay the actual answer and its scope to the same worker, resuming it with the available follow-up tool. Repeat for further questions or revisions. Preserve

to-tickets

' breakdown review; delegation does not waive it. A request to run

plan-it

is not approval of an unseen breakdown.

向 ticket worker 传达以下指示：当委派的 skill 需要用户回答或批准时，应返回主聊天，并附上问题、相关草案或备选项、当前进度以及已有 artifact URL。在主聊天获得用户回复前，暂停所有依赖该回答的工作。

按照“用户问题”流程在主聊天中提出问题并等待用户。将用户的实际答复及其适用范围转交给同一个 worker，并通过可用的 follow-up tool 恢复其执行。如有后续问题或修改要求，则重复此流程。必须保留

to-tickets

的拆分方案审查；委派不能豁免该步骤。请求运行

plan-it

不等于批准用户尚未看到的拆分方案。

Recovery

恢复

If a replacement worker is needed, pass the user's accumulated decisions, constraints, and approvals with their exact scope, alongside the saved progress and artifact pointers. Do not treat approval of an earlier draft as approval of a revised draft.

On failure, interruption, or unverifiable results, leave the workflow incomplete and report the completed stage, existing issue URLs, incomplete operation, and remaining work. Retain the ticketing worker identifier and artifact pointers across user turns. Resume the spec stage in the parent chat or the existing ticketing worker where possible; if the worker is unavailable, give a replacement the recorded progress and have it inspect GitHub state before continuing. Reuse published issues and repair incomplete operations according to the relevant skills rather than creating duplicates. After a verified spec stage, resume ticketing directly against that parent.

如果需要替换 worker，应向其传递用户累计做出的决定、约束和批准事项，并明确每项批准的确切适用范围，同时提供已保存的进度和 artifact 指针。不得将用户对早期草案的批准视为对修改后草案的批准。

如果发生失败、中断或结果无法验证，应保持工作流处于未完成状态，并报告已完成的阶段、现有 issue URL、未完成的操作和剩余工作。跨用户轮次保留 ticket worker 的标识符和 artifact 指针。尽可能在主聊天中恢复 spec 阶段，或在现有 ticket worker 中恢复；如果该 worker 不可用，则向替代 worker 提供已记录的进度，并让它在继续之前检查 GitHub 状态。应依据相关 skill 复用已发布的 issue 并修复未完成的操作，而不是创建重复项。spec 阶段验证通过后，应直接基于该父 issue 恢复 ticket 阶段。