land

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Nothing lands unverified.

Fast path. When there is no spec, the diff is small, and the user already named the path in the invocation (merge, PR, keep, discard): skip the options menu and go. On the merge path, if the merge is a fast-forward, skip the post-merge test re-run; a fast-forward produces the exact tree

verify

just passed. Any divergence from the base branch voids this: diverged merge results are new trees and get the full re-run. The spec question is not part of the fast path: when a spec exists and its fate was not named in the invocation, ask it even here: one line, default keep. Deep mode (the

deep

skill is active) voids the whole fast path: full menu, unconditional re-run, and the spec question asked explicitly rather than inferred.

Run the
```
verify
```
skill. When a spec exists at
```
docs/specs/<slug>.md
```
, the final gate is a fresh subagent that reads only the spec and the diff and reports criterion by criterion, checking the diff against the repo's conventions in CLAUDE.md or AGENTS.md when they exist; the maker does not certify its own work. Failing work does not reach the options menu.
Detect the environment: normal checkout, named-branch worktree, or detached HEAD (externally managed workspace).
Present exactly these options, no essay: merge locally to the base branch / push and open a PR / keep the branch as-is / discard. Detached HEAD drops the merge option. Discard requires the user to type "discard".
On merge and PR paths, close the spec: route durable residue out (a decision worth keeping becomes an ADR, a settled term goes to
```
CONTEXT.md
```
, a change to the system's shape updates
```
ARCHITECTURE.md
```
). Then ask what happens to the spec file itself (keep it, or delete it) and say which is the default in the same breath: keep unless the user asks otherwise. Routing the residue is not optional and happens either way; only the file's fate is the user's call. A named path in the invocation ("land: merge, drop the spec") answers the question already: do not ask twice. Keep path leaves the spec in place without asking; it is still steering.
Write the PR body and the merge commit message from the spec: lead the body with the demo (the
```
verify
```
evidence: what was run and what it showed, or how to exercise the change), then the goal as the summary line, acceptance criteria as the change list, non-goals as scope notes. The reasoning enters the permanent record where
```
git blame
```
points, whether or not the file survives.
Merge path, in this order: from the main checkout merge the branch, re-run the tests on the merged result, remove the worktree, then delete the branch. Branch deletion before worktree removal fails; worktree removal from inside the worktree fails.
PR and keep paths preserve the worktree; the user needs it to iterate.

Rules:

Never force-push, never amend a published commit, and no
```
--no-verify
```
or
```
reset --hard
```
on a dirty tree without an explicit ask.
Never delete a spec the user did not ask to delete. Silence is not consent; unanswered means keep.
Never remove a worktree the harness created; only clean up ones under
```
.worktrees/
```
or
```
worktrees/
```
. Run
```
git worktree prune
```
after removal.
Never merge without re-running tests on the merged result.
Merge conflicts are resolved by intent, hunk by hunk, each side traced to its source;
```
--abort
```
is not a resolution.

未经验证的代码不得合并入库。

快速路径：当没有spec，代码差异很小，且用户在调用时已指定操作路径（合并、PR、保留、丢弃），则跳过选项菜单直接执行。在合并路径中，如果是快进式合并（fast-forward），则跳过合并后的测试重跑；快进式合并会生成与刚刚通过

verify

验证完全一致的代码树。若与基准分支存在分歧，则不适用此规则：存在分歧的合并结果会生成新的代码树，需要完整重跑测试。spec相关问题不属于快速路径范畴：当存在spec且调用时未指定其处理方式时，即使在快速路径中也需询问用户，用一行提问，默认选项为保留。深度模式（

deep

skill激活时）会禁用整个快速路径：显示完整选项菜单、无条件重跑测试，且明确询问spec相关问题而非自行推断。

运行
```
verify
```
skill。当
```
docs/specs/<slug>.md
```
路径下存在spec时，最终验证环节由一个独立的子agent完成，该子agent仅读取spec和代码差异，并逐条核对验收标准；若仓库中存在CLAUDE.md或AGENTS.md约定，还会检查代码差异是否符合这些约定；代码开发者不得自行验证自己的工作。未通过验证的代码无法进入选项菜单。
检测环境：普通检出、命名分支工作区（named-branch worktree）或分离HEAD状态（外部管理的工作区）。
仅展示以下选项，无需额外说明：本地合并到基准分支 / 推送并创建PR / 保留分支原样 / 丢弃分支。分离HEAD状态下不显示合并选项。选择丢弃分支时，用户需手动输入“discard”。
在合并和PR路径下，需归档spec：将有长期价值的内容迁移至对应位置（值得留存的决策转为ADR，已确定的术语加入
```
CONTEXT.md
```
，系统架构的变更更新
```
ARCHITECTURE.md
```
）。随后询问用户如何处理spec文件本身（保留或删除），并同时告知默认选项：除非用户明确要求，否则默认保留。内容迁移是必须执行的操作，无论用户选择保留还是删除文件；仅文件的最终归属由用户决定。若用户在调用时已指定路径（例如“land: merge, drop the spec”），则无需再次询问。选择保留分支路径时，spec文件保持原样，无需询问；它仍将作为后续开发的指导。
根据spec撰写PR正文和合并提交信息：PR正文开头展示验证证据（
```
verify
```
执行的内容及结果，或如何测试该变更），然后将目标作为摘要行，验收标准作为变更列表，非目标作为范围说明。相关推理内容会被记录在
```
git blame
```
可追踪的永久记录中，无论spec文件是否留存。
合并路径的执行顺序：从主工作区合并分支，在合并结果上重跑测试，移除工作区，然后删除分支。先删除分支再移除工作区会失败；在工作区内部执行移除操作也会失败。
PR和保留分支路径会保留工作区；用户需要用它进行迭代开发。

规则：

禁止强制推送，禁止修改已发布的提交，未经明确请求，不得在脏代码树上使用
```
--no-verify
```
或
```
reset --hard
```
命令。
不得删除用户未要求删除的spec。沉默不代表同意；未回复即视为保留。
不得删除由工具创建的工作区；仅清理
```
.worktrees/
```
或
```
worktrees/
```
目录下的工作区。移除后需运行
```
git worktree prune
```
。
合并前必须在合并结果上重跑测试。
合并冲突需根据意图逐块解决，追踪每一块代码的来源；
```
--abort
```
不是有效的冲突解决方式。