milestones

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Milestones

Command-driven GitHub milestone skill. Parse the first token as a command when it matches the table; otherwise map clear intent.

Default: if the user gives only a milestone identifier (title, number, URL) and optional details — no admin command — execute Complete the work. Do not ask which admin command to run. Do not stop at

status

critique

plan

alone.

Admin commands shape the milestone when explicitly requested; they are not the default path.

命令驱动的 GitHub 里程碑技能。当第一个词匹配下表中的命令时，将其解析为命令；否则根据明确意图映射。

默认行为： 如果用户仅提供里程碑标识符（标题、编号、URL）和可选详情——无管理命令——则执行 Complete the work。不要询问要运行哪个管理命令。不要仅停留在

status

critique

plan

步骤。

仅在用户明确请求时，管理命令才会调整里程碑；它们不是默认路径。

Operating contract

操作契约

Shared by every DecisionNerd/dev-skills skill. Canonical copy:

handbook/concepts/14-operating-contract.md

Define done first. Before using tools, write the finish line in one or two lines: the acceptance criteria (existing issue AC, BDD scenarios, tests, or contract when they exist; otherwise propose them and say where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on work you did not verify.
Requested scope sets the finish line. A question ("is it ready?", "why is it broken?", "what next?") ends with the answer and a
```
Next:
```
line naming the exact next invoke. An outcome request ("fix", "finish", "land", "#42") continues through the chain (diagnose → fix → test → check-readiness → merge-it) until the outcome or a real blocker. Do not end a turn with "Do you want me to…?" for in-scope, in-repo work.
Stop only for real blockers. Stop and ask only when you cannot continue without the user, or before: deleting data or unmerged work, force-push or history rewrite, changing anything outside this repository (GitHub objects, deployments, live data, production or paid resources, external services), or leaving the requested scope, unless the user's request already named that exact action. Keep the harness's permission prompts for risky commands. Otherwise keep going and put status notes in the same message as the next action.
Ask well, once. For a genuine question use the harness's structured question tool when it has one (Claude Code:
```
AskUserQuestion
```
; Codex:
```
request_user_input
```
when the current mode supports it) with concrete options; otherwise plain text with numbered options. Treat the answer as settled; do not re-open earlier verdicts, plans, or answers unless asked.
Fan out when work is parallel. Use subagents for independent reads (repo survey, evidence gathering, per-option research, per-area audits) and for independent verification (a reviewer that did not write the change). Writes stay single-owner per path set and sequential. Brief every child with goal, done-when, constraints, must-not, and return shape; verify each child's result before consolidating. Use Claude Code's
```
Workflow
```
tool only for orchestration across many subagents that truly needs it; it is expensive.
Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents (Claude Code
```
CLAUDE_CODE_SUBAGENT_MODEL
```
or a CLAUDE.md rule; Codex
```
agents.default_subagent_model
```
or a role's
```
agents.<name>.config_file
```
; Cursor a custom subagent's
```
model:
```
frontmatter), follow it and do not pass a model. Otherwise: mechanical search or inventory → fast/cheap (Claude Code
```
haiku
```
); implementation and evidence gathering → mid (
```
sonnet
```
); planning, review, adversarial verification → top (
```
opus
```
or
```
fable
```
). In Claude Code set it with the
```
Agent
```
tool
```
model
```
param or agent frontmatter
```
model:
```
; in Codex pass a spawn model or set
```
model
```
in the role's config file; in Cursor set
```
model:
```
(default
```
inherit
```
) in
```
.cursor/agents/*.md
```
. Where the harness cannot choose, children inherit the parent model or the harness picks one (Cursor's built-in Explore/Bash/Browser subagents pick per subtask); say which in the status note.
Keep a checklist on long runs. For more than about five steps or work that crosses skills, keep
```
TASKS.md
```
at the repo root and tick items as they finish. Do not commit it unless the repo already tracks one.
Close every run with three headings.
```
Blocked on me
```
(the one genuine question or blocker, else "none");
```
Changed
```
(files, commits, GitHub objects, deploys, else "nothing");
```
Found
```
(evidence, verdict, and
```
Next: <exact invoke>
```
).

所有 DecisionNerd/dev-skills 技能共享此契约。官方副本：

handbook/concepts/14-operating-contract.md

。

先定义完成标准。 使用工具前，用一两行写出终点：验收标准（若存在现有 issue 的 AC、BDD 场景、测试或契约，则使用它们；否则提出验收标准并说明应存放的位置）以及证明完成的证据。在报告完成前重新检查。永远不要对未验证的工作报告完成。
请求的范围决定终点。 对于问题（“准备好了吗？”、“为什么坏了？”、“下一步是什么？”），以答案和一行
```
Next:
```
结尾，明确指出下一次要调用的操作。对于结果请求（“修复”、“完成”、“上线”、“#42”），则沿着链路（诊断 → 修复 → 测试 → check-readiness → merge-it）继续执行，直到达成结果或遇到真正的阻塞。对于范围内、仓库内的工作，不要以“你想让我…吗？”结束一轮对话。
仅因真正的阻塞停止。 仅在没有用户就无法继续时，或在以下操作前停止并询问：删除数据或未合并的工作、强制推送或历史重写、修改此仓库之外的任何内容（GitHub 对象、部署、实时数据、生产或付费资源、外部服务）、超出请求范围——除非用户的请求已经明确指定了该操作。对于风险命令，保留运行框架的权限提示。否则继续执行，并将状态说明与下一步操作放在同一条消息中。
一次问清楚，问到位。 对于真正的问题，如果运行框架有结构化提问工具（Claude Code：
```
AskUserQuestion
```
；Codex：当前模式支持时使用
```
request_user_input
```
），则使用该工具并提供具体选项；否则使用带编号选项的纯文本。将答案视为最终结论；除非用户要求，否则不要重新讨论之前的结论、计划或答案。
并行工作时拆分任务。 对于独立的读取操作（仓库调研、证据收集、各选项研究、各领域审计）和独立验证（未编写变更的评审者），使用 subagent。写入操作在每条路径上保持单一负责人且顺序执行。向每个子 agent 说明目标、完成条件、约束、禁止事项和返回格式；在合并前验证每个子 agent 的结果。仅当确实需要编排大量 subagent 时，才使用 Claude Code 的
```
Workflow
```
工具；该工具成本较高。
为每个子 agent 选择模型等级；遵循路由配置。 如果运行框架或用户配置已经为 subagent 配置了路由（Claude Code 的
```
CLAUDE_CODE_SUBAGENT_MODEL
```
或 CLAUDE.md 规则；Codex 的
```
agents.default_subagent_model
```
或角色的
```
agents.<name>.config_file
```
；Cursor 自定义 subagent 的
```
model:
```
前置元数据），则遵循该配置，不要传递模型参数。否则：机械搜索或盘点 → 快速/低成本（Claude Code
```
haiku
```
）；实现和证据收集 → 中等（
```
sonnet
```
）；规划、评审、对抗性验证 → 顶级（
```
opus
```
或
```
fable
```
）。在 Claude Code 中，通过
```
Agent
```
工具的
```
model
```
参数或 agent 前置元数据的
```
model:
```
设置；在 Codex 中，传递生成模型或在角色的配置文件中设置
```
model
```
；在 Cursor 中，在
```
.cursor/agents/*.md
```
中设置
```
model:
```
（默认
```
inherit
```
）。如果运行框架无法选择，子 agent 将继承父模型或由框架选择（Cursor 内置的 Explore/Bash/Browser subagent 会根据子任务选择）；请在状态说明中注明使用的模型。
长时间运行时保留检查清单。 对于超过约五个步骤或跨技能的工作，在仓库根目录保留
```
TASKS.md
```
，并在完成时勾选项目。除非仓库已经跟踪该文件，否则不要提交它。
每次运行结束时包含三个标题。
```
Blocked on me
```
（一个真正的问题或阻塞，否则为“none”）；
```
Changed
```
（文件、提交、GitHub 对象、部署，否则为“nothing”）；
```
Found
```
（证据、结论，以及
```
Next: <具体调用>
```
）。

Commands

命令

Command	What it does
`create`	Create a milestone (title, description, due date) after draft + approval
`update`	Edit title, description, or due date
`critique`	Critique milestone purpose, scope, issue set, and close criteria
`narrow`	Reduce milestone scope; move issues out or to later milestones
`widen`	Expand milestone deliberately; pull in related open issues with rationale
`merge`	Consolidate two milestones (move issues, close/redirect the loser)
`clean`	Clean description noise, fix due dates, tidy issue membership
`refine`	Sharpen description and close criteria without changing membership
`explain`	Plain-language explanation of the milestone for the user
`document`	Improve/add repo release notes, changelog, or runbook for this milestone
`close`	Close milestone when issues are done (or with explicit incomplete waiver)
`status`	Progress: open/closed issue counts, blockers, due date risk
`plan`	Propose which open issues belong; optional tracker issue via `issues create`
`list`	List open (and optionally closed) milestones
`help` / `library`	List commands

Target: milestone title, number, or URL. Use

gh api

gh milestone

when available, or

gh api repos/{owner}/{repo}/milestones

命令	功能
`create`	起草并获得批准后创建里程碑（标题、描述、截止日期）
`update`	编辑标题、描述或截止日期
`critique`	评审里程碑的目标、范围、issue 集合和关闭标准
`narrow`	缩小里程碑范围；将 issue 移出或移至后续里程碑
`widen`	有计划地扩大里程碑范围；说明理由后拉入相关的开放 issue
`merge`	合并两个里程碑（移动 issue，关闭/重定向被合并的里程碑）
`clean`	清理描述中的冗余内容、修正截止日期、整理 issue 归属
`refine`	在不改变成员的前提下，优化描述和关闭标准
`explain`	用通俗易懂的语言向用户解释里程碑
`document`	完善/新增该里程碑的仓库发布说明、变更日志或运行手册
`close`	当 issue 完成时关闭里程碑（或在明确接受未完成项的情况下关闭）
`status`	进度情况：开放/关闭 issue 数量、阻塞项、截止日期风险
`plan`	提议哪些开放 issue 应纳入；可通过 `issues create` 创建跟踪 issue
`list`	列出开放（可选包含已关闭）的里程碑
`help` / `library`	列出所有命令

目标：里程碑标题、编号或 URL。优先使用

gh api

gh milestone

，或使用

gh api repos/{owner}/{repo}/milestones

。

Routing

路由规则

No argument:
```
list
```
open milestones; if exactly one is the obvious focus → Complete the work on it; else ask via the structured question tool — options: complete a listed milestone /
```
create
```
/
```
plan
```
.
First word is a command: run it; remainder is the target. After admin work, state
```
Next: milestones <name>
```
and run it when the user signaled progress.
Clear admin intent (“narrow the launch milestone”, “how’s the v1.2 milestone?” as status-only): map and proceed.
Milestone identifier ± details, no admin command (
```
v1.2
```
, title, number, or
```
v1.2 ship the API issues
```
): Complete the work — execute, don’t menu.

Before mutating GitHub (create/edit milestone, move issues, close), state the proposed change; ask one structured question with options

<do it> / revise / stop

. Skip when the user’s request already named that exact action. Completion handoffs follow the target skill’s approval rules.

无参数：
```
list
```
开放里程碑；如果恰好有一个是明显的焦点 → 对其执行 Complete the work；否则通过结构化提问工具询问——选项：完成列出的某个里程碑 /
```
create
```
/
```
plan
```
。
第一个词是命令：运行该命令；其余部分为目标。完成管理工作后，说明
```
Next: milestones <名称>
```
，并在用户表示要继续推进时执行。
明确的管理意图（例如“缩小发布里程碑的范围”、“v1.2 里程碑进展如何？”仅需状态查询）：映射对应命令并继续。
里程碑标识符 ± 详情，无管理命令（
```
v1.2
```
、标题、编号，或“v1.2 发布 API 相关 issue”）：执行 Complete the work——直接执行，不要显示菜单。

在对 GitHub 进行变更操作前（创建/编辑里程碑、移动 issue、关闭），说明拟议的变更；提出一个结构化问题，选项为

<执行> / 修改 / 停止

。如果用户的请求已经明确指定了该操作，则跳过。完成交接遵循目标技能的审批规则。

Shared operations

共享操作

Use references/ops.md for critique/narrow/widen/merge/clean/refine/explain/document as applied to milestones.

里程碑相关的 critique/narrow/widen/merge/clean/refine/explain/document 操作，请参考 references/ops.md。

Complete the work

Milestone admin (

create

plan

critique

narrow

/ …) organizes the slice. Completing the work means finishing the open issues and shipping the release.

里程碑管理（

create

plan

critique

narrow

/ …）负责规划任务切片。完成工作意味着解决所有开放 issue 并发布版本。

Default path (identifier ± details)

默认路径（标识符 ± 详情）

When routed here (no admin command):

Resolve the milestone; list open issues and blockers (
```
gh issue list --milestone ...
```
).
Fold any user details into priority (which theme/issue to hit first).
Pick the critical-path open issue (or release path if issues are done) and run the smallest execution skill from the table now. One-line why — no recommend-only menu.
Chain forward issue-by-issue through Integrate until blocked on a required GitHub mutation or the user stops you. When the slice is releasable and policy defines a later phase, state
```
Next: merge-it <next-phase>
```
; run it only when the user requests that phase. For independent open issues in the slice, fan out one subagent per issue with non-overlapping paths (mid tier); the parent verifies each result before merge-it. This is the one place a Claude Code
```
Workflow
```
is warranted when there are many issues — note that it is expensive. Keep
```
TASKS.md
```
across the chain.
If membership is clearly wrong and blocks progress, do the minimum
```
plan
```
/
```
narrow
```
fix, then continue execution on the remnant.

当路由到此处时（无管理命令）：

解析里程碑；列出开放 issue 和阻塞项（
```
gh issue list --milestone ...
```
）。
将用户提供的所有详情纳入优先级考量（确定优先处理哪个主题/issue）。
选择关键路径上的开放 issue（如果 issue 已完成则选择发布路径），并立即运行下表中最合适的最小执行技能。用一行说明理由——不要只提供推荐菜单。
通过 Integrate 逐个 issue 链式推进，直到遇到需要 GitHub 变更的阻塞或用户停止。当任务切片可发布且策略定义了后续阶段时，说明
```
Next: merge-it <下一阶段>
```
；仅在用户请求该阶段时执行。对于切片中独立的开放 issue，为每个 issue 分配一个 subagent，路径不重叠（中等模型等级）；父 agent 在 merge-it 前验证每个结果。当 issue 数量很多时，这是唯一值得使用 Claude Code
```
Workflow
```
工具的场景——请注意其成本较高。在整个链式执行过程中保留
```
TASKS.md
```
。
如果 issue 归属明显错误且阻塞了进度，进行最小程度的
```
plan
```
/
```
narrow
```
修正，然后继续处理剩余的任务。

After explicit admin commands

显式管理命令之后

After

status

critique

explain

plan

create

, state

Next: milestones <name>

(or

recon issue #N

merge-it

as fits); run it when the user already signaled finish/ship.

Situation	Execute
Open issue needs a plan	`recon issue #N` then implement
Bug blocking the milestone	`diagnose-bug` / `troubleshoot-app` → `fix-it`
Issue ready to implement	implement (or `fix-it` if repair-shaped)
Need tests / evidence on a key issue	`test-it`
Scope done on an issue?	`check-readiness`
PR open for milestone work	`merge-it`
Issues done; staging / production release	`merge-it` (Stage/Ship phases)
Wrong membership / too much WIP	`milestones narrow` , then execute the remnant
Missing tracker/closure issue	`issues create` (tracker+closure), then continue
Unsure which issue first	`recon milestone <name>` , then execute its primary

Do not default to

milestones refine|critique|clean|status

when a milestone identifier was given. Prefer execute on the critical-path issue.

在执行

status

、

critique

、

explain

、

plan

、

create

之后，说明

Next: milestones <名称>

（或根据情况使用

recon issue #N

merge-it

）；当用户已经表示要完成/发布时执行。

场景	执行操作
开放 issue 需要规划	`recon issue #N` 然后实现
Bug 阻塞了里程碑	`diagnose-bug` / `troubleshoot-app` → `fix-it`
issue 已准备好实现	实现（如果是修复类问题则用 `fix-it` ）
关键 issue 需要测试/证据	`test-it`
某个 issue 的范围已完成？	`check-readiness`
里程碑相关的 PR 已开放	`merge-it`
issue 已完成；预发布/生产环境发布	`merge-it` （Stage/Ship 阶段）
归属错误 / WIP 过多	`milestones narrow` ，然后执行剩余任务
缺少跟踪/关闭 issue	`issues create` （跟踪+关闭），然后继续
不确定先处理哪个 issue	`recon milestone <名称>` ，然后执行其主要任务

当提供了里程碑标识符时，不要默认执行

milestones refine|critique|clean|status

。优先执行关键路径上的 issue。

Create / plan / status / close

创建 / 规划 / 状态 / 关闭

create

Read repo conventions (
```
AGENTS.md
```
, existing milestone names).
Draft title, description (purpose, in-scope themes, out-of-scope, close criteria), optional due date.
State the draft; ask one structured question with options
```
create / revise / stop
```
. Create via API on approval.
State
```
Next: milestones <name>
```
(usually execute critical-path
```
recon issue
```
after a quick
```
plan
```
, or
```
issues create
```
for a tracker/closure issue); run it when the user wanted a working milestone, not just the shell.

读取仓库约定（
```
AGENTS.md
```
、现有里程碑名称）。
起草标题、描述（目标、范围内主题、范围外内容、关闭标准）、可选截止日期。
说明草稿内容；提出一个结构化问题，选项为
```
create / revise / stop
```
。获得批准后通过 API 创建。
说明
```
Next: milestones <名称>
```
（通常在快速
```
plan
```
后执行关键路径的
```
recon issue
```
，或为跟踪/关闭 issue 执行
```
issues create
```
）；当用户需要一个可用的里程碑而不仅仅是空壳时执行。

plan

Load the milestone and candidate open issues (
```
gh issue list --milestone ...
```
and unassigned related issues).
Propose adds/removes with one-line rationale each.
State proposed adds/removes; ask one structured question with options
```
apply / revise / stop
```
. On approval, edit issue milestones accordingly.
If a tracker/closure issue is needed, hand off to
```
issues create
```
with tracker+closure guidance.
Execute the first issue (
```
recon issue #N
```
or diagnose/fix) — not only “membership updated.”

加载里程碑和候选开放 issue（
```
gh issue list --milestone ...
```
以及未分配的相关 issue）。
提议添加/移除的 issue，每个附一行理由。
说明拟议的添加/移除内容；提出一个结构化问题，选项为
```
apply / revise / stop
```
。获得批准后，相应编辑 issue 的里程碑归属。
如果需要跟踪/关闭 issue，将任务交接给
```
issues create
```
，并提供跟踪+关闭的指导。
执行第一个 issue（
```
recon issue #N
```
或诊断/修复）——不要只停留在“成员已更新”。

status

Report: due date, open vs closed counts, % complete, top blockers, overdue risk. After an explicit

status

command, state

Next: milestones <name>

(or

recon issue #N

on the blocker). On default routing, skip standalone status and go straight to completion.

报告内容：截止日期、开放与关闭数量、完成百分比、主要阻塞项、逾期风险。在显式执行

status

命令后，说明

Next: milestones <名称>

（或针对阻塞项的

recon issue #N

）。在默认路由下，跳过单独的状态查询，直接进入完成流程。

close

Only when open issues are closed, moved out, or the user explicitly accepts closing with leftovers (document waivers in the milestone description or a closing comment on a tracker issue). If close criteria need a release train, recommend

merge-it

Stage/Ship phases instead of premature close.

仅当开放 issue 已关闭、已移出，或用户明确接受保留未完成项关闭时（需在里程碑描述或跟踪 issue 的关闭评论中记录豁免情况）。如果关闭标准需要发布流程，推荐使用

merge-it

Stage/Ship 阶段，而非提前关闭。

Output

输出

Blocked on me

none

Changed

nothing

Found

Next: milestones <name> (or the execution skill that best fits the current state)

Next: milestones <名称>（或最符合当前状态的执行技能）

Related skills

Grounding

基础依据

This skill’s TTPs are grounded in current engineering baselines (DORA, GitHub Docs, Fowler/Beck, Google SRE & SWE book, OpenTelemetry, OWASP LLM / NIST AI RMF, Diátaxis — see handbook

sources.md

Time-boxed releasable slices over endless backlog; keep milestone WIP honest (DORA small batches).

Handbook card:

handbook/practices/milestones.md

本技能的 TTPs 基于当前工程最佳实践（DORA、GitHub Docs、Fowler/Beck、Google SRE & SWE 书籍、OpenTelemetry、OWASP LLM / NIST AI RMF、Diátaxis——参见 handbook

sources.md

）。

采用有时间限制的可发布切片，而非无尽的待办列表；保持里程碑 WIP 真实可控（DORA 小批量原则）。

手册卡片：

handbook/practices/milestones.md

。

milestones

Original

Translation

Milestones

Milestones

Operating contract

操作契约

Commands

命令

Routing

路由规则

Shared operations

共享操作

Complete the work

Complete the work

Default path (identifier ± details)

默认路径（标识符 ± 详情）

After explicit admin commands

显式管理命令之后

Create / plan / status / close

创建 / 规划 / 状态 / 关闭

create

create

plan

plan

status

status

close

close

Output

输出

Blocked on me

Blocked on me

Changed

Changed

Found

Found

Related skills

相关技能

Grounding

基础依据