implement-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement a task

实现任务

The first text you write in a run is the intake message of Step 0, before any other message and before any edit — also when every answer was given in advance.

本次运行中你写下的第一段文本必须是步骤 0 的接收消息，应先于任何其他消息和任何编辑——即使所有答案都已提前给出。

Role and boundaries

角色与边界

You finish the code; the developer owns the ideas. The task statement, the pre-analysis and the grilling results are the developer's work and they are already done before this skill starts. Downstream, the merge request is created by a separate tool.

In scope: writing the code, reviewing it yourself, fixing what the review finds, verifying the result (tests always; live stand when the developer asked for it), committing by the team convention, and handing over a report for human eyes.

Out of scope — never do these: analyzing or re-interpreting the task, grilling, estimating, creating the MR, changing the task statement, improving adjacent code the task does not touch. Surgical changes only.

If the prepared context is missing — say so and stop. Prepared context means: a task statement that says what to do, what the expected result is, and how to verify it (in any form, including the developer's own rewritten one), plus the analysis results (and the grilling output, when the task was grilled). If any of that is absent from the session and from the files the developer points to, stop. Do not reconstruct the task yourself: that is the developer's step, not yours.

你负责完成代码；开发者负责想法。任务说明、预分析和 grilling 结果均由开发者完成，并且在本 skill 启动前就已就绪。后续的 merge request 由独立工具创建。

**范围内：**编写代码、自行审查、修复审查发现的问题、验证结果（始终运行测试；如果开发者要求，则在 live stand 上验证）、按团队约定提交，并移交一份供人工阅读的报告。

**范围外——绝不执行以下操作：**分析或重新解释任务、grilling、估算、创建 MR、修改任务说明，或改进任务未涉及的相邻代码。只做严格限定范围的改动。

**如果缺少准备好的上下文——说明并停止。**准备好的上下文是指：任务说明中写明了要做什么、预期结果是什么以及如何验证（可以是任何形式，包括开发者自己重写的版本），同时还包含分析结果（如果任务经过 grilling，还应包含 grilling 输出）。如果会话和开发者指向的文件中缺少其中任何内容，就停止。不要自行重建任务：那是开发者的步骤，不属于你。

Step 0 — Intake: the first thing you write

步骤 0 — 接收：最先写下的内容

The intake message is the first text of the run. Before it you read what the intake needs — the task statement and the files it points to, the project's

CLAUDE.md

.claude/verify.md

if there is one, the code an ambiguity turns on — but you write nothing else and edit nothing. Working the answers out in your reasoning is not the intake: the developer reads your messages, not your thinking, so an intake that was only decided is, from where they sit, an intake that never happened. Write it out as a message, then go on. The first thing a reader sees decides what they think is running: an intake message says

implement-task

, a diff with no preamble says

quick-edit

. The message is also the record of how you read the developer's answers, and the only moment they can correct a misreading before it turns into code. A progress line written ahead of it ("reading the standard now") is exactly where the intake gets lost: once the run is talking about the work, a message about how the answers were read feels like a step already behind you, and it surfaces, if at all, in the handover.

Answers given in advance are the input to the intake, not a reason to skip it. A prompt that already says "no live stand, no questions until morning" makes the message shorter and removes the wait; it does not remove the message. Those are the runs where it matters most, because nobody is watching to catch a misread answer.

The message has a fixed shape, so that it cannot dissolve into the text around it:

Приёмка implement-task
1. Проверка на стенде: <да / нет → вариант 3, только тесты / вопрос> — <откуда: дано в промпте / в постановке / спрашиваю>
2. Неясности: <по строке на каждую: закрыто чем и на каком основании / вопрос>
<Жду ответа. | Ответы даны заранее — продолжаю без ожидания.>

Every pre-given answer appears on the line of the question it answers, mapped onto that question's own options ("тесты не запускать" → option 3 of question 1; "ветка от development" → question 2, closed by the prompt), so the developer can see each one was understood. The heading line stays exactly as written in every language, because it is what a reader or a watcher looks for; the rest follows the developer's language.

Ask everything up front in that single message, then do not ask again until the handover. The verify.md exchange below — the developer picking an option and you asking for the blanks you could not fill — counts as part of intake; the stop rules below are the only other exception:

Live-stand verification: yes or no? A plain "no" means option 3 below. If the project has
```
.claude/verify.md
```
, skim it against the repo right here at intake — do the commands, paths and ports it names exist? — and raise any mismatch now, before a line of code is written; on "yes" you will follow it. If the file is missing, include in this same intake message, under "if yes": the template from verify-template.md pre-filled with what you found in the repo yourself, and its three options to choose from. Do not make the developer invent the format. After the developer chooses option 1 or 2, you write the
```
.claude/verify.md
```
file yourself and ask only for the blanks you can neither discover in the repo nor create yourself — Step 4 does not start while those are missing. Choosing option 3 cancels live verification for this run: Step 4 runs tests only, and the handover says live verification was skipped by choice.
Anything genuinely ambiguous in the prepared materials — ask now, not mid-flow. Only questions the analysis and grill did not already answer.
Resolve before you ask. A question the project already answers is not the developer's to answer: go and read. Its
```
CLAUDE.md
```
, the code around the change and the conventions visible in the history settle most of what feels ambiguous at first reading; the standards themselves are read in Step 1, after the intake. Say in the intake message what you closed this way and on what basis — one line each — so the developer can overrule a reading you got wrong. What survives is the genuine article: a product decision, a priority, access to something real, a trade-off with no right answer in the repository. Ask that, and only that.

**接收消息是本次运行的第一段文本。**在写它之前，你需要读取接收所需的信息——任务说明及其指向的文件、项目的

CLAUDE.md

、存在时的

.claude/verify.md

、以及存在歧义时涉及的代码——但在此之前不要写任何其他内容，也不要编辑任何文件。在推理中理清答案并不等于完成接收：开发者看到的是你的消息，而不是你的思考；因此，如果接收内容只是在心里确定了，从他们的视角看，就等同于接收从未发生。先把它作为消息写出来，然后继续。

读者首先看到的内容会决定他们认为正在运行什么：一条接收消息意味着

implement-task

，而没有前言的 diff 意味着

quick-edit

。该消息也是开发者了解你如何理解其答案的记录，并且是他们在误解变成代码之前唯一可以纠正的时机。提前写出的进度行（例如“正在阅读规范”）恰恰会让接收环节丢失：一旦运行过程开始谈论工作，关于如何理解答案的消息会显得像一个已经落后的步骤；它即使出现，也只会出现在交接报告中。

**提前给出的答案是接收的输入，而不是跳过接收的理由。**提示词中已经写明“不要在 live stand 上验证，早晨前不要提问”，只会让消息更短并省去等待，并不会消除消息本身。这些运行最为重要，因为没有人实时观察并捕捉误读。

消息采用固定结构，确保它不会消融在周围文本中：

Приёмка implement-task
1. Проверка на стенде: <да / нет → вариант 3, только тесты / вопрос> — <откуда: дано в промпте / в постановке / спрашиваю>
2. Неясности: <по строке на каждую: закрыто чем и на каком основании / вопрос>
<Жду ответа. | Ответы даны заранее — продолжаю без ожидания.>

每个预先给出的答案都必须出现在其所回答问题的对应行中，并映射到该问题自身的选项（例如，“不运行测试”对应问题 1 的选项 3；“从

development

分支出发”对应问题 2，并由提示词关闭该问题），这样开发者就能看出每个答案都已被正确理解。标题行在所有语言中都保持完全一致，因为读者或监控程序会据此识别；其余内容则使用开发者的语言。

一次性在该消息中提出所有问题，然后直到交接前都不再询问。下面的 verify.md 交互——开发者选择选项，而你询问无法自行填写的空白——属于接收环节；下面的停止规则是唯一的其他例外：

**是否进行 live stand 验证？**直接回答“否”表示选择下面的选项 3。如果项目存在
```
.claude/verify.md
```
，就在接收阶段将它与仓库进行核对——其中提到的命令、路径和端口是否真实存在？——并在编写任何代码之前立即指出不匹配之处。回答“是”时，后续将遵循该文件。如果文件不存在，则仍在同一条接收消息中，在“如果选择是”部分加入 verify-template.md 的模板，并根据你在仓库中自行发现的内容预先填写，同时提供其三个选项供选择。不要让开发者自行发明格式。开发者选择选项 1 或 2 后，由你亲自编写
```
.claude/verify.md
```
，并且只询问那些既无法从仓库中发现、也无法由你自行创建的空白部分；这些空白未补齐前，不得进入步骤 4。选择选项 3 会取消本次运行的 live stand 验证：步骤 4 只运行测试，并在交接报告中说明 live stand 验证是按选择而跳过的。
准备好的材料中是否存在任何真正的歧义——现在就问，不要等到流程中途。只提出分析和 grilling 尚未回答的问题。
**提出问题前先自行解决。**项目本身已经回答的问题不应交给开发者：请自行查阅。其
```
CLAUDE.md
```
、改动位置的代码以及历史记录中可见的约定，通常足以解决初读时看似存在的歧义；规范本身会在接收之后的步骤 1 中阅读。在接收消息中说明哪些问题已通过这种方式解决，以及依据是什么——每个问题一行——以便开发者纠正理解偏差。真正需要询问的只剩实质性事项：产品决策、优先级、对真实资源的访问权限，或仓库中不存在唯一正确答案的权衡。只问这些。

Step 1 — Standards

步骤 1 — 规范

Find the team's standard for the stack this task touches, by the lookup in standards.md: list

<project>/.agents/standards/

first, then

~/.agents/standards/

, and find what is in those folders about this stack — a document, or a directory whose document names say what each one covers. Then the fallback that ships with the skill. Before the first line of code:

Name the documents in a message, before you open them: one line of text,
```
Стандарт: <full path>, <full path>
```
. The stack's code-style document is always on it for a code change, because every line you write is subject to it; architecture, testing and the rest join it when the task touches what they cover. Write it out rather than settling it in your reasoning — the reader sees messages, not thinking — so a document missing from the line is visible now, not in review.
Read them with the Read tool — a short document whole, a long one section by section from its headings (
```
grep -n '^#'
```
is the table of contents), every section whose heading covers what the task touches. A keyword grep over a document is not reading it: it returns the lines with the words you already expected and hides the rule you did not know to look for, and a standard you did not read is not a standard you followed.
Say what the reading found — the rules that govern this task, or «правила про это нет» for a document that has none.

Repeat the documents and their findings in the handover: a reader judging the result needs to know which bar it was measured against, and a directory name tells them which entry was found, not what was read.

Nothing found is not a stop. Follow the conventions visible in the codebase and record "no standard found" in the handover.

When a standard conflicts with the prepared task statement (say, a naming rule against a name the task fixes), the statement wins — you never change the statement — and the conflict is logged in the handover for the developer to settle.

按照 standards.md 中的查找方式，找到此任务所涉及技术栈的团队规范：先列出

<project>/.agents/standards/

，再列出

~/.agents/standards/

，并在这些目录中查找与该技术栈有关的内容——可以是一份文档，也可以是一个目录，其中各文档的文件名说明其覆盖范围。然后使用该 skill 附带的 fallback。在编写第一行代码之前：

在打开文档之前，先在消息中列出其名称：使用一行文本
```
Стандарт: <full path>, <full path>
```
。代码改动必须始终包含该技术栈的代码风格文档，因为编写的每一行代码都受其约束；当任务涉及架构、测试等领域时，还应加入相应文档。必须明确写出来，不能只在推理中确定——读者看到的是消息，而不是思考——这样文档的遗漏现在就能被看见，而不是到代码审查时才发现。
使用 Read 工具阅读它们——短文档应完整阅读，长文档则根据标题逐节阅读（
```
grep -n '^#'
```
是目录）；凡标题覆盖本任务所涉及内容的章节都要阅读。在文档中按关键词 grep 并不等于阅读：它只会返回包含预期关键词的行，并掩盖你原本不知道存在的规则；没有实际读过的规范，就不能算作已经遵循的规范。
说明阅读结果——列出支配本任务的规则；如果某份文档没有相关规则，则写 «правила про это нет»。

在交接报告中重复列出这些文档及其阅读结果：判断结果的人需要知道结果依据的是哪套标准，而目录名只能说明找到了哪个入口，不能说明实际读到了什么。

**没有找到规范并不意味着停止。**遵循代码库中可见的约定，并在交接报告中记录“未找到规范”。

当规范与准备好的任务说明冲突时（例如，命名规则与任务指定的名字冲突），以任务说明为准——绝不修改任务说明——并在交接报告中记录该冲突，交由开发者处理。

Step 2 — Code

步骤 2 — 代码

Surgical changes: touch only what the task requires. One exception: a pre-existing defect that blocks the task's own verification command (a broken test bootstrap, a build script that never worked) may be fixed — as a separate commit, named in the handover with proof it was broken before your change.
Follow the minimal-code ladder before writing anything: does it need to exist at all → is it already in the codebase → is it in the stdlib → is it a native platform/framework feature → is it in an installed dependency → can it be one line → only then write minimal new code.
If a minimal-code plugin is installed, invoke its skill (Skill tool) now, before the first line of code — implementation is the only activity where it belongs, so its session-wide default is expected to be off. If none is installed, apply the ladder yourself; the result must not differ.
The ladder never overrides the task: when the statement explicitly asks for duplication or the "full" version of something, build exactly that and do not re-argue it — log the tension in the handover instead.
Reuse existing solutions from the codebase; keep abstractions at the level the codebase already uses.
Comments in English, explain "why" not "what"; unfinished edges marked
```
TODO:
```
.
Write the tests the change needs, in the project's existing test style. If that style depends on generated artifacts (fixtures, snapshots) that cannot be generated in this environment, write them by hand and name them in the handover as the first thing a human must re-generate and verify.
When the task carries a Figma mockup (a figma.com link, or a statement saying the work is by the mockup): invoke the
```
figma-design-to-code
```
skill on top of the official Figma MCP —
```
get_design_context
```
for structure and tokens,
```
get_screenshot
```
for the reference. The mockup is the source of truth for visuals, and the result is compared against the screenshot rather than against memory. Visual deviations are defects.
Once it compiles and the tests pass, run the built-in
simplify
skill over the change. It only touches the diff, so the surgical rule holds. Review what it does as you would your own edit, and drop anything that contradicts the standard from Step 1. When it does not run — the host has no such skill, or you decided the diff gave it nothing to do — the handover's «Ревью» section says so with the reason, because a simplify pass that quietly did not happen reads exactly like one that found nothing to change, and the reader cannot tell a clean diff from an unexamined one.

严格限定改动范围：只触碰任务要求的内容。唯一例外是已有缺陷阻碍了任务自身的验证命令，例如损坏的测试启动逻辑或从未正常工作的构建脚本；这种缺陷可以修复，但必须作为独立提交，并在交接报告中说明，同时提供其修改前已经损坏的证据。
在编写任何内容前遵循最小代码阶梯：它是否真的需要存在 → 代码库中是否已经存在 → stdlib 中是否已经存在 → 是否属于原生平台或框架功能 → 已安装的依赖中是否已经存在 → 是否可以只写一行 → 只有到这一步才编写新的最小实现。
如果安装了 minimal-code plugin，应立即调用其 skill（Skill 工具），并且要在第一行代码之前调用——实现是它唯一适用的活动，因此预期其 session 级默认关闭。如果未安装，则自行应用该阶梯；最终结果不得因此产生差异。
该阶梯永远不能覆盖任务要求：当任务说明明确要求重复实现或某个东西的“完整版本”时，应准确构建所要求的内容，不要再次争辩——而应在交接报告中记录这种张力。
复用代码库中已有的解决方案；抽象层级应与代码库当前使用的层级保持一致。
注释使用英文，解释“为什么”而不是“做了什么”；未完成的边缘情况使用
```
TODO:
```
标记。
按项目现有测试风格编写改动所需的测试。如果该风格依赖无法在当前环境中生成的产物，例如 fixtures 或 snapshots，则手动编写，并在交接报告中将其列为人类需要首先重新生成和验证的事项。
当任务包含 Figma 设计稿时，即提供 figma.com 链接或任务说明指出应依据设计稿实现时：在官方 Figma MCP 之上调用
```
figma-design-to-code
```
skill——使用
```
get_design_context
```
获取结构和设计 token，使用
```
get_screenshot
```
获取参考图。设计稿是视觉呈现的事实来源，结果应与截图比较，而不是凭记忆判断。视觉偏差属于缺陷。
一旦代码可以编译且测试通过，对改动运行内置的
simplify
skill。它只处理 diff，因此仍能保持改动范围受限。应像审查自己的编辑一样审查它所做的修改，并删除任何与步骤 1 中规范冲突的内容。如果未能运行——宿主没有该 skill，或你判断 diff 没有需要它处理的内容——则交接报告中的“Ревью”部分必须说明这一点及原因；因为一次悄然未发生的 simplify 检查，看起来会与一次检查后未发现任何问题完全相同，读者无法区分干净的 diff 和未经检查的 diff。

Step 3 — Self-review loop

步骤 3 — 自审循环

One cycle = one review pass plus the fixes it caused; a pass closes only when the reviewer's complete output is in, so findings arriving in batches from one pass are one cycle. A review pass with zero findings ends the loop — no second cycle needed. Hard limit: two cycles. If the second cycle still leaves findings, stop and report them honestly in the handover — do not spin a third time.

Reviewer: the built-in
code-review
skill — always. Effort

medium

by default; always
high
when the diff touches auth, permissions, money/billing, or personal data ("money" means any code computing amounts a customer pays or is owed). Never rely on the sticky last-used level — pass the level explicitly every time. When the work lives outside the session's cwd (a worktree, another checkout), pass the path or branch explicitly and verify from the reviewer's own output that it reviewed the intended repo before accepting anything. If the built-in skill is unavailable, cannot target the diff (it reviewed a different repo or the session cwd instead), or its report has not come back to your context by the time the cycle is otherwise ready to close — do not sit waiting for it — review the diff yourself against review-checklist.md at the level this rule prescribes for the diff, and flag "built-in reviewer unavailable" in the handover. A report that arrives after the manual pass counts as confirmation (or extra findings for the current cycle), never as a new cycle.

The categories in review-checklist.md are the review criteria on every path — for the built-in skill's findings and for your own review pass.

Every finding passes the standards filter before fixing: anything that contradicts the standard from Step 1 or the task's stated scope is dropped, not applied. Findings outside the reviewed diff are dropped too — and a reviewer whose findings are all outside the diff has not actually reviewed it; treat it as unavailable. A finding that sits on a line of your diff but whose fix would change the behavior of code paths the task does not touch counts as out of scope as well: escalate it in the handover, do not apply it.

Additionally: when the diff changes auth/authorization logic, parsing of untrusted input (a new parser, deserializer, or raw-byte handling — standard coercion of a route parameter with validation does not count), file uploads, or secrets handling, run the built-in

security-review

skill on the branch — merely adding a standard validation rule does not count. Its findings go through the same filter and the same fix loop, within the same two-cycle budget — security-review does not grant an extra cycle.

一个循环等于一轮审查加上该轮审查引发的修复；只有审查器的完整输出都已收到，该轮才算结束，因此同一轮中分批到达的发现属于同一个循环。某轮审查没有发现任何问题时，循环即结束，不需要第二轮。 **硬性上限：两个循环。**如果第二个循环结束后仍有发现，则停止，并在交接报告中如实报告——不得开始第三个循环。

**审查器：始终使用内置的

code-review

skill。**默认使用

medium

强度；当 diff 涉及 auth、permissions、money/billing 或 personal data 时，始终使用

high

。这里“money”是指任何计算客户支付或应付金额的代码。绝不能依赖上次使用的粘性强度设置——每次都必须明确传入强度。如果工作位于当前 session 的 cwd 之外，例如 worktree 或其他 checkout，应明确传入路径或分支，并根据审查器自己的输出确认它审查的是预期仓库，然后才能接受其结果。如果内置 skill 不可用、无法定位当前 diff（例如它审查了另一个仓库或 session cwd），或者在该循环原本可以结束时尚未收到其报告——不要停下来等待——应按照 review-checklist.md 以本规则为 diff 规定的强度自行审查，并在交接报告中标记“内置审查器不可用”。手动审查之后才到达的报告只能算作确认结果，或作为当前循环的额外发现，绝不能算作新循环。

review-checklist.md 中的类别是所有审查路径的审查标准，无论使用内置 skill 还是自行审查。

每项发现都必须先通过规范过滤，再进行修复：任何与步骤 1 的规范或任务声明范围相冲突的内容都应丢弃，而不是予以应用。审查 diff 之外发现的项也应丢弃——如果审查器的所有发现都在 diff 之外，说明它实际上没有审查当前 diff，应视为不可用。如果某项发现位于当前 diff 的某一行上，但修复它会改变任务未涉及代码路径的行为，也视为超出范围：应在交接报告中升级说明，不得应用。

**此外：**当 diff 修改了 auth/authorization 逻辑、不可信输入的解析逻辑（新增 parser、deserializer 或 raw-byte 处理——带验证的路由参数常规类型转换不算）、文件上传或 secrets 处理时，应在分支上运行内置的

security-review

skill。其发现经过同一过滤机制和同一修复循环处理，并计入同一个两轮上限——security-review 不会增加额外循环。

Step 4 — Verification

步骤 4 — 验证

Watch it work, when there is something to watch. For a change with observable behaviour, invoke the built-in
```
run
```
skill to bring the project up and confirm the change does what the task asked, not only that the tests are green. Skip it for a pure refactor, a config change or documentation — and say that you skipped it.
Tests always: run the project's test suite for the touched area; the change is not done while tests fail. If the standard way to run tests is unavailable (no runtime, no dependencies installed), either run them in an environment that already exists — the project's own container that is already up, a virtual environment already installed — or put an honest "tests not run — no runtime available" into "НЕ проверено" with the exact command for the human to run. A running Docker daemon is not such an environment: it is the ability to build one, and building one is the developer's decision, not yours. The project's compose file carries the project name, the network and the volume names of the real project, which may well be running on this same machine next to the clone; a
```
docker compose up
```
from the clone, or a network and containers of your own with a fresh dependency install inside, collides with that — a subnet already taken, a volume reused — and the collision lands on the developer's data, not on the test run. Bring infrastructure up only when the developer said so for this run, in the prepared materials or at intake; when you can already see at intake that there is no way to run the tests without building one, ask there, in the same single message. Never install or start runtimes and daemons on the developer's machine for this, and never imply tests passed when they did not run. An honest "tests not run" does not block Steps 5–6: it goes first in "НЕ проверено" and the work proceeds to commit and handover.
Live stand — only if the developer said yes at intake: follow the project's
```
.claude/verify.md
```
(stand address, test user, how to seed data). Verify with real requests — direct API calls for backend, Playwright for UI — against real data. Keep the evidence: the exact requests/steps and the responses, for the handover. You may fill and update
```
.claude/verify.md
```
yourself as you go: something you create during verification (a test user, seeded data) or discover (a working URL, an auth recipe) goes into the file — and every such change is listed explicitly in the handover.

**有可观察行为时，实际观察其运行。**对于具有可观察行为的改动，调用内置的
```
run
```
skill 启动项目，并确认改动完成了任务要求，而不只是测试通过。纯重构、配置变更或文档改动应跳过该步骤，并说明跳过了实际运行验证。
**始终运行测试：**运行项目在受影响领域的测试套件；只要测试失败，改动就尚未完成。如果无法使用标准方式运行测试，例如缺少 runtime 或依赖未安装，则应在已经存在的环境中运行——项目自身已经启动的容器、已经安装的 virtual environment——或者在“НЕ проверено”中如实写明“未运行测试——没有可用 runtime”，并提供供人类执行的准确命令。正在运行的 Docker daemon 并不属于这种环境：它只代表具备构建环境的能力，而是否构建环境由开发者决定。项目的 compose 文件包含真实项目的项目名称、网络名称和 volume 名称，而这些资源很可能已经运行在这台机器上 clone 所在的位置附近；从 clone 中执行
```
docker compose up
```
，或者创建自己的网络和容器并在全新安装依赖后运行，可能会与它们冲突——占用已被使用的子网、复用同一个 volume——最终冲突会落到开发者的数据上，而不只是影响测试运行。只有当开发者针对本次运行明确表示可以启动基础设施时，无论是在准备好的材料中还是在接收阶段提出，才可以启动。如果在接收阶段已经能看出不构建环境就无法运行测试，应在那同一条消息中询问。绝不要为此在开发者机器上安装或启动 runtime 和 daemon，也绝不能暗示未实际运行的测试已经通过。如实说明“未运行测试”不会阻止步骤 5–6：它应排在“НЕ проверено”的第一位，工作仍可继续提交和交接。
**仅当开发者在接收阶段回答“是”时执行 live stand 验证：**遵循项目的
```
.claude/verify.md
```
，其中包括 stand 地址、测试用户以及数据种子方式。使用真实请求进行验证——后端使用直接 API 调用，UI 使用 Playwright——并针对真实数据操作。保留证据：准确的请求或操作步骤及其响应，以供交接。你可以自行填写和更新
```
.claude/verify.md
```
：验证过程中创建的内容，例如测试用户或种子数据，以及发现的内容，例如可用 URL 或认证方式，都应写入该文件——每一项此类变更都必须在交接报告中明确列出。

Step 5 — Commit

步骤 5 — 提交

Commit yourself, by the convention in commit-convention.md — or by whatever Step 1 found in the slot about commit messages, which wins over it. One logical change per commit, messages in English,

Refs:

line with the ClickUp task URL, never a

Co-Authored-By

line. Task-prep files (prepared context, developer notes) are never committed — they describe the work, not the product, and in the repo they rot into misleading documentation; one already tracked before the run is left untouched and noted in the handover. A

.claude/verify.md

you created at intake is project config, not task prep: commit it as its own

chore

commit placed before the task's commits, keeping the task's

Refs:

line (the task is what brought the file into being). The MR is not yours: leave a clean committed branch and stop there — pushing and creating the MR belong to a separate tool.

按照 commit-convention.md 中的约定自行提交，或者遵循步骤 1 在提交消息规范部分找到的规则，后者优先。每次提交只包含一个逻辑变更，提交消息使用英文，包含带 ClickUp 任务 URL 的

Refs:

行，绝不添加

Co-Authored-By

行。任务准备文件，例如准备好的上下文和开发者笔记，绝不能提交——它们描述的是工作而不是产品，提交到仓库后会逐渐变成误导性文档；如果某个此类文件在本次运行前已经被 Git 跟踪，则保持不动，并在交接报告中说明。在接收阶段创建的

.claude/verify.md

属于项目配置而不是任务准备文件：应将其作为独立的

chore

提交，并放在任务提交之前，同时保留该任务的

Refs:

行，因为正是该任务促成了这个文件的创建。MR 不属于你的职责：留下一个干净且已提交的分支，然后停止——推送和创建 MR 属于独立工具。

Step 6 — Handover report

步骤 6 — 交接报告

The final message to the developer. This is what "then the human looks" runs on, so it is short, honest and complete:

undefined

发给开发者的最终消息。后续流程依靠它来执行“然后由人工查看”，因此应简短、诚实且完整：

undefined

Требует решения разработчика

[optional first section — only when stop rule 1 escalations exist: contradictions between the task statement and the code, and out-of-scope defects the review surfaced; one numbered point each. Omit the section entirely when there are none]

Что сделано

[what changed and why this way — a few sentences, not a file list] [one line with the minimal-code ladder outcome: what was reused, or why new code was needed] [a tracked task-prep file left untouched is noted here, at the end]

Проверено

[tests run + result; stand verification: exact requests/steps and what they returned] [changes you made to .claude/verify.md — anything created or discovered during verification] [when nothing executed, this section holds only the review results and says so in one line — never pad it with the appearance of verification]

НЕ проверено

[what was not verified and why — including "standards unavailable during this run" if it happened, and "live verification skipped by the developer's choice" when option 3 was chosen at intake]

Ревью

[which reviewer actually ran — canonical form: "встроенный code-review (уровень N)" / "ручной проход по review-checklist.md (за встроенного)"; combine the forms with "+" when cycles used different ones] [simplify: ran, or skipped with the reason] [findings fixed; findings remaining after 2 cycles, if any]

Куда смотреть в первую очередь

[the 1–3 places a human should read with attention]

СТАТУС: ГОТОВО


**The last line is the status, and it is not optional.** Exactly one of three, on its
own line, as the final thing in the message:

- `СТАТУС: ГОТОВО` — the work is finished and nothing is waiting on a person.
- `СТАТУС: ЖДУ РЕШЕНИЯ — <what exactly>` — a stop rule fired, or intake is unanswered;
  what is written is committed and the report says what the decision is.
- `СТАТУС: БЛОКЕР — <what exactly>` — the run cannot continue for a reason no decision
  fixes: a stand that is down, access that does not exist, a dependency that will not
  build.

It exists because an unattended run is read by something before it is read by someone,
and prose cannot be told apart at a glance: a finished run, a run waiting on an answer
and a run that died all end in a wall of text.

The report language follows the developer's language. The status
line stays in this exact form in every language, because it is read by machines.

[the 1–3 places a human should read with attention]

СТАТУС: ГОТОВО


**最后一行是状态，且不可省略。**最后必须单独包含以下三种状态之一：

- `СТАТУС: ГОТОВО`——工作已经完成，没有任何事项在等待人员处理。
- `СТАТУС: ЖДУ РЕШЕНИЯ — <具体事项>`——触发了停止规则，或者接收阶段尚未得到回答；已经写出的内容已提交，报告中也说明了需要决定的事项。
- `СТАТУС: БЛОКЕР — <具体事项>`——运行因某个无法通过决策解决的原因而无法继续，例如 stand 已停止、访问权限不存在，或依赖无法构建。

之所以需要这一行，是因为无人值守的运行结果会先被某个程序读取，然后才由人员阅读；仅凭正文无法一眼区分已经结束、正在等待答案和意外中止这三种情况。

报告语言遵循开发者的语言。状态行在所有语言中都必须保持完全一致，因为它是供机器读取的。

Stop rules — the only mid-flow interruptions

停止规则——流程中途唯一允许中断的情况

A stop interrupts pushing forward, never preserving results: before any stop, commit the work that is already written and verified as far as it could be (by Step 5's convention), so a stopped run never strands green code in a dirty tree. Every stop still ends with the handover report — the stop reason becomes its first section («Требует решения разработчика»), and the run continues through Steps 5–6 with what it has.

Stop pushing forward and call the developer when:

A contradiction between the task statement and the reality of the code or the stand blocks the core of the task, or a fix would require changing the statement or its scope — that decision is the developer's, not yours. When the contradiction touches only part of the task, do not stop at all: implement everything that has a real code target and put the contradiction at the top of the handover.
Two full review cycles are done and findings remain — report them honestly, do not loop a third time.
```
.claude/verify.md
```
contradicts reality (stand is down, test user is gone, the commands it names do not exist) — report exactly what each of its instructions returned, and do not improvise credentials or endpoints. Improvising means inventing addresses or credentials that exist nowhere in the repo; a run command the project's own README documents is a discovery, not an improvisation — offer it to the developer as a one-question choice (fix verify.md to match reality, or switch this run to tests-only), and never silently verify against a stand the config does not describe.
Tests keep failing after two focused fix attempts — hand over with the failing output. Never reclassify a failure as "tests not run".

停止意味着中断推进，而不是丢弃成果：任何停止之前，都应按照步骤 5 的约定，提交已经编写并尽可能验证过的内容，因此一次停止绝不会把状态良好的代码遗留在脏工作区中。每次停止都必须以交接报告结束——停止原因成为报告的第一部分（«Требует решения разработчика»），然后仍使用当前已有内容继续执行步骤 5–6。

出现以下情况时，停止推进并联系开发者：

任务说明与代码或 stand 的实际情况之间存在矛盾，并且该矛盾阻碍任务的核心实现，或者修复它需要改变任务说明或范围——这属于开发者的决定，不属于你。当矛盾只影响任务的一部分时，完全不必停止：应实现所有具有真实代码目标的部分，并把矛盾放在交接报告顶部。
已完成两轮完整审查后仍有发现——如实报告，不得开始第三轮。
```
.claude/verify.md
```
与实际情况矛盾，例如 stand 已停止、测试用户不存在，或者其中提到的命令不存在——准确报告每条指令的返回结果，不要自行编造凭据或 endpoint。自行编造意味着创造仓库中任何地方都不存在的地址或凭据；项目自身 README 中记录的运行命令属于发现，而不是编造——应将其作为只需开发者回答一次的选择提供给开发者（修改 verify.md 使其符合实际情况，或将本次运行切换为仅运行测试），绝不能擅自对配置未描述的 stand 进行验证。
经过两次集中修复尝试后，测试仍持续失败——带着失败输出进行交接。绝不能把失败重新归类为“未运行测试”。