modernize

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Modernize

Reassess the old PR's goal against today's code before updating its branch. A conflict-free rebase is not evidence that the design still belongs.

在更新旧 PR 的分支之前，先用今天的代码重新评估该 PR 的目标。一次无冲突的 rebase 并不能证明它的设计依然成立。

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: acceptance criteria (existing issue AC, BDD scenarios, tests, or contract; otherwise propose them and where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on unverified work.
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; T3 Code: the
```
question
```
tool) 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 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 result before consolidating. Use Claude Code's
```
Workflow
```
tool only when orchestrating many subagents truly needs it; it is expensive. T3 Code: its delegated subagents — with optional worktree isolation for independent verification — cover this without the
```
Workflow
```
tool.
Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents, follow it and do not pass a model. Otherwise pick a tier per child: mechanical search or inventory → fast/cheap; implementation and evidence gathering → mid; planning, review, adversarial verification → top. Tier names differ per harness (Claude Code:
```
haiku
```
/
```
sonnet
```
/
```
opus
```
or
```
fable
```
; T3 Code: inherit by default or pick from its live provider/model catalog). Set the choice with the harness's spawn
```
model
```
param or agent frontmatter
```
model:
```
(per-harness details:
```
skills/agents/references/sub.md
```
). Where the harness cannot choose, children inherit or the harness picks; 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”）则沿着链路持续推进（diagnose → fix → test → check-readiness → merge-it），直到达成结果或遇到真正的阻塞。对于范围内的、仓库内的工作，不要以“要我继续做……吗？”结束回合。
只在真正的阻塞处停下。 仅在以下情况停止并询问：无法在没有用户参与的情况下继续；或即将进行以下操作之前——删除数据或未合并的工作、force-push 或重写历史、修改本仓库之外的任何内容（GitHub 对象、部署、线上数据、生产或付费资源、外部服务），或偏离所请求的范围——除非用户的请求已经明确指明了该具体动作。保留 harness 对高风险命令的权限提示。除此之外继续推进，并把状态说明与下一步动作放在同一条消息里。
只问一次，问得好。 对于真正的问题，在 harness 具备结构化提问工具时使用它（Claude Code：
```
AskUserQuestion
```
；Codex：在当前模式支持时使用
```
request_user_input
```
；T3 Code：使用
```
question
```
工具），并给出具体选项；否则用纯文本加编号选项。把回答视为已定论；除非被要求，不要重新推翻先前的结论、计划或答案。
可并行的工作就分派出去。 对独立的读取（仓库调研、证据收集、逐选项研究、逐领域审计）和独立的验证（由未编写该改动的评审者执行）使用 subagents。写入操作按路径集合保持单一负责人并顺序执行。向每个子任务交代目标、完成条件、约束、禁止事项和返回形式；在汇总前逐一验证结果。仅在确实需要编排大量 subagents 时才使用 Claude Code 的
```
Workflow
```
工具；它开销很大。T3 Code：其委派的 subagents——可选用 worktree 隔离来做独立验证——已能覆盖这些场景，无需
```
Workflow
```
工具。
为每个子任务选择模型档位，并优先遵从路由配置。 如果 harness 或用户配置已经为 subagents 做了路由，就遵循它，不要再指定模型。否则按子任务挑选档位：机械式搜索或盘点 → 快速/廉价；实现与证据收集 → 中档；规划、评审、对抗式验证 → 顶级。档位名称因 harness 而异（Claude Code：
```
haiku
```
/
```
sonnet
```
/
```
opus
```
或
```
fable
```
；T3 Code：默认继承或从其在线 provider/model 目录中挑选）。通过 harness 的 spawn
```
model
```
参数或 agent frontmatter 的
```
model:
```
设置选择（各 harness 细节见
```
skills/agents/references/sub.md
```
）。当 harness 无法选择时，子任务继承或由 harness 决定；并在状态说明中写明用的是哪种。
长流程要维护检查清单。 当步骤超过约五步，或工作跨越多个 skill 时，在仓库根目录维护
```
TASKS.md
```
并在完成时逐项勾选。除非仓库已经在跟踪该文件，否则不要提交它。
每次运行都以三个标题收尾。
```
Blocked on me
```
（唯一真正的问题或阻塞，若无则写“none”）；
```
Changed
```
（文件、提交、GitHub 对象、部署，若无则写“nothing”）；
```
Found
```
（证据、结论，以及
```
Next: <精确调用>
```
）。

When to use

何时使用

```
modernize <PR|branch>
```
Bring an old PR up to date, rebase it, or assess whether it remains useful.

Assessment-only requests stop at a recommendation. A request to update/rebase includes the scoped branch update, subject to repository history-rewrite policy. It does not include merging, changing the PR base, closing the PR, or expanding the feature.

```
modernize <PR|branch>
```
将旧 PR 更新到最新状态、对其做 rebase，或评估它是否仍有价值。

仅做评估的请求止步于给出建议。请求更新/rebase 则包含在限定范围内的分支更新，并受仓库的历史重写策略约束。它不包含合并、变更 PR 的 base、关闭 PR 或扩展该功能。

Instructions

指令

1. Pin intent and state

1. 锁定意图与现状

Read repository instructions and the PR's title, body, linked issues, reviews, commits, and full diff. Record the URL, state, author, head repository/branch/SHA, actual base repository/branch/SHA, checks, and review state. For a local branch, resolve its intended base from repository guidance or the user's request.

Inspect dirty work, attached worktrees, and active ownership. Preserve them and use an owned isolated checkout when needed. Never update another active writer's branch without a handoff. Fetch the actual base and head, including a fork's head remote when applicable; do not assume

origin/main

. Record the original head and merge base so the old PR and intervening base changes remain distinguishable. Retain the original head locally for comparison and recovery before rebasing.

阅读仓库说明以及 PR 的标题、正文、关联 issue、评审、提交和完整 diff。记录 URL、状态、作者、head 仓库/分支/SHA、实际 base 仓库/分支/SHA、checks 以及评审状态。对于本地分支，从仓库指引或用户请求中解析出其预期的 base。

检查未提交的工作、已挂载的 worktree 和活跃的归属情况。保留它们，必要时使用自己拥有的独立 checkout。绝不在未交接的情况下更新其他活跃写入者的分支。获取实际的 base 和 head，必要时包括 fork 的 head remote；不要假定是

origin/main

。记录原始 head 和 merge base，使旧 PR 与期间发生的 base 变更仍可区分。在 rebase 之前，本地保留原始 head 以便对比与恢复。

2. Check conceptual compatibility

2. 检查概念兼容性

Inspect base changes since divergence, callers, schemas/APIs, moved or removed code, and open/merged work likely to supersede the PR. Verify the original failure where practical. Ask whether the PR would duplicate a current mechanism, reintroduce retired behavior, or violate a newer invariant. Judge the intended benefit against current architecture; age and sunk effort prove neither value nor obsolescence.

Choose before rebasing or pushing:

Disposition	Evidence and action
MODERNIZE	Goal still useful; implementation fits. Update, verify, and push when requested.
REWORK	Goal still useful; design no longer fits. Explain the smallest coherent replacement; implement only if the user's scope includes rework.
CLOSE	Goal already solved, superseded, or no longer justified. Cite evidence; recommend closure without closing unless explicitly authorized.

An assessment-only request stops here. For REWORK/CLOSE, do not mechanically rebase an obsolete implementation to make its CI green.

检查自分叉以来 base 的变更、调用方、schema/API、被移动或删除的代码，以及可能取代该 PR 的在途或已合并工作。在可行的情况下复现原始故障。问自己：该 PR 是否会与现有机制重复、重新引入已废弃的行为，或违反更新的不变量。要用当前架构来衡量其预期收益；年龄和沉没成本既不能证明价值，也不能证明过时。

在 rebase 或 push 之前先定性：

处置方式	证据与动作
MODERNIZE	目标仍然有用；实现仍然契合。更新、验证，并在被请求时 push。
REWORK	目标仍然有用；设计不再契合。说明最小且自洽的替代方案；仅当用户的范围包含 rework 时才实施。
CLOSE	目标已被解决、被取代，或不再有正当理由。给出证据；建议关闭，但未经明确授权不要关闭。

仅做评估的请求止步于此。对于 REWORK/CLOSE，不要为了让 CI 变绿而机械地 rebase 一个过时的实现。

3. Update without losing intent

3. 更新但不丢失意图

For MODERNIZE, rebase the owned continuation onto the freshly fetched actual base, unless repository policy prescribes merging the base instead. Resolve conflicts using both the original goal and current invariants. If a conflict reveals an unresolved product/design choice, reconsider the disposition before pushing.

Use

git range-diff

on the recorded old and new commit ranges for a rebase, then inspect the final base-to-head diff and relevant callers. Explain dropped commits that were already applied upstream; do not silently drop intended behavior. For a merge update, inspect its resolutions and resulting diff. Run focused repository checks and separate change failures from pre-existing or infrastructure failures.

对于 MODERNIZE，将自己拥有的延续分支 rebase 到刚获取到的实际 base 上，除非仓库策略规定改为 merge base。同时结合原始目标与当前不变量来解决冲突。如果冲突暴露出尚未解决的产品/设计抉择，请在 push 之前重新评估处置方式。

对于 rebase，在记录下来的旧提交区间与新提交区间上使用

git range-diff

，然后检查最终的 base-to-head diff 以及相关调用方。说明那些在上游已被应用的提交为何被丢弃；不要悄然丢弃原本意图的行为。对于 merge 式的更新，检查其冲突解决过程和最终产生的 diff。运行聚焦的仓库检查，并把变更引起的失败与既有的或基础设施导致的失败区分开。

4. Publish only to the intended branch

4. 只发布到预期的分支

Confirm the push target's repository and branch, especially for forks or takeover continuations. When rewriting a remote PR branch is authorized, use an explicit lease pinned to the remote head observed before the update:

git push --force-with-lease=refs/heads/<branch>:<observed-head-sha> <head-remote> HEAD:refs/heads/<branch>

Never use an unqualified force push or refresh the lease just to get past a rejection. If the remote head moved, fetch, inspect, and reconcile the new work. If the base moved materially during verification, reassess and rerun affected checks. Normal fast-forward updates use a normal push.

In T3 Code, immediately link any PR pushed to with

link_pull_request

as the next tool call, including stack layers, and report linking failures. Re-read the PR after pushing, when one exists, and report the actual head and check state. Do not claim the previous head's green CI covers the new head. Do not merge or post a comment unless that action was requested. If an authorized comment is needed, use concise attribution, evidence, and a secret/private-data check.

确认 push 目标的仓库和分支，尤其是 fork 或接管式延续的情况。当授权重写远端 PR 分支时，使用显式 lease 并锁定更新前观测到的远端 head：

git push --force-with-lease=refs/heads/<branch>:<observed-head-sha> <head-remote> HEAD:refs/heads/<branch>

绝不使用无限定条件的 force push，也不要为了绕过拒绝而刷新 lease。若远端 head 已移动，则 fetch、检查并调和新的改动。若在验证期间 base 发生了实质性变动，则重新评估并重跑受影响的检查。普通的 fast-forward 更新使用普通 push。

在 T3 Code 中，任何 push 出去的 PR 都要立即在下一个工具调用中使用

link_pull_request

进行关联，包括栈式分层（stack layers），并报告关联失败。 push 之后重新读取该 PR（若存在），并报告实际的 head 与 checks 状态。不要声称此前 head 的绿色 CI 覆盖了新的 head。除非请求了该动作，否则不要 merge 或发表评论。如果确实需要经授权的评论，使用简洁的署名、证据，并做秘密/私有数据检查。

Output

输出

Lead with MODERNIZE, REWORK, or CLOSE and the reason. Include base changes, conceptual conflicts, old/new heads, update/push status, check evidence, and the remaining action with the PR link. State anything that could not be verified.

以 MODERNIZE、REWORK 或 CLOSE 开头，并给出原因。包含 base 的变更、概念冲突、新旧 head、更新/push 状态、检查证据，以及剩余动作与 PR 链接。说明任何无法验证的内容。

Source

来源

Adapted from Theo Browne's modernize skill (MIT). Upstream notice: LICENSE.

改编自 Theo Browne 的 modernize skill （MIT）。上游声明：LICENSE。