quick-edit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Quick edit

快速编辑

What this is for

用途

The developer asked for a change and is looking at the result right now. There is no task to interpret, no report to write, and nobody downstream who needs evidence. What this skill adds over just editing the file is that the team's conventions still apply to a two-line change.

If the request is a prepared task — a tracker id, a statement with acceptance criteria, anything that will be reviewed by someone else — stop and use

implement-task

instead. Say which one you are using in a single clause, so the developer can redirect you before the work rather than after.

开发者提出了改动请求，并且此刻正在查看结果。这里没有需要解读的任务，没有需要撰写的报告，也没有下游人员需要证据。相比直接编辑文件，这个 skill 的额外价值在于：即便是两行改动，团队约定仍然适用。

如果请求是已准备好的任务——tracker ID、包含验收标准的说明，或任何将由他人评审的内容——请停止并改用

implement-task

。用一句简短的话说明你正在使用哪一个，让开发者可以在工作开始前而不是完成后重新指派。

How

操作方式

The standard for the touched stack, by the lookup in standards.md: list
```
<project>/.agents/standards/
```
, then
```
~/.agents/standards/
```
, and find what is in there about the stack you are editing — a document, or a directory of documents, whichever the developer put in the folder. Then the fallback here. Before the edit, three things in this order:
- Name the documents in a message, before you open them: one line of text to the developer,
```
Стандарт: <full path>, <full path>
```
  . For a change to code the stack's code-style document is always on it, because every line you write is subject to it; add architecture, testing or other documents when the change touches what they cover — a new class, an endpoint, a test. Write the line out rather than settling it in your reasoning: the developer sees your messages, not your thinking, and a choice of documents nobody can see is one nobody can correct while it still matters.
- Read them with the Read tool. A short document whole; a long one by its headings (
```
grep -n '^#'
```
  is its table of contents), reading whole every section whose heading covers the change. A keyword grep over the document is not reading it, before the edit or after: it returns the lines containing the words you already had in mind and hides the rule you did not think to look for, which is the one the standard exists to give you.
- Say what the reading found: the rule that governs this change, or that the document has none about it — «правила про это нет». The same line goes into the answer at the end, so the developer sees which bar the change was held to.
Skip this entirely for a change that no standard can have an opinion about — a typo in a comment, a version bump — and say that you skipped it.
Surgical. Touch what the request names and nothing adjacent. Improving code you happened to read is the most common way a two-line change becomes a review.
Reuse before writing. If the codebase already has this, use it. If the language or framework already has it, use that.
Tests that already cover it. Run them when they exist and are cheap to run; say what happened. Do not write new tests here — a change that needs new tests is a task, and belongs to
```
implement-task
```
.
Cheap means the environment is already there: the runtime on the machine, the dependencies installed, the project's own container already up. Pulling an image, starting a container or creating a network to run a test or a syntax check is not cheap, however short the command looks — a running Docker daemon is the ability to build an environment, not an environment, and building one on the developer's machine is their decision. The image stays on their disk, and a container started from a clone of a client project can collide with the real project's compose network and volumes running next to it. So without the developer's word for it, no
```
docker
```
,
```
podman
```
or
```
docker compose
```
command at all, not even one to see whether the daemon is up. When nothing already present can run the check, say in the answer that it was not run and why, and give the exact command the developer can run themselves —
```
php -l <file>
```
,
```
php artisan test --filter=<TestClass>
```
, whatever the project's own check is.
Back to the developer, and nothing they could read off the diff. Name the file and the line so they have somewhere to jump, then only what the diff does not say: an edge case the change leaves open, a test you could not run and why, something nearby that now looks wrong. No headings, no report, no recap of the change — they are about to read it. When there is nothing beyond the diff, one line is the whole answer. Write it in the language the developer is speaking — a Russian request gets a Russian answer — while the code and the comments in it stay in English, as the codebase is.

A conclusion that changes nothing the developer does is either verified or left out. "I read the framework and this case behaves as it did before" costs them a paragraph to learn that nothing happened. Either run the thing and report the result, or say nothing and let the unchanged behaviour stay unchanged. What survives this test is what would make them act differently: stop, look somewhere, decide something.

This replaces a sentence count, which measured the wrong thing: four sentences of substance are not ceremony, and "Done, let me know if you want it committed" is ceremony in two. The count is kept elsewhere in this set of skills only where it bounds one field of a template, never a whole answer.

所涉及技术栈的规范，按照 standards.md 中的查找方式：先列出
```
<project>/.agents/standards/
```
，再列出
```
~/.agents/standards/
```
，并查找其中与正在编辑的技术栈有关的内容——可以是文档，也可以是文档目录，具体取决于开发者放入了什么。然后使用这里的兜底规则。编辑前，按以下顺序完成三件事：
- 在打开文档之前，在消息中列出文档名称：向开发者发送一行文本，
```
规范：<完整路径>，<完整路径>
```
  。对于代码改动，技术栈对应的代码风格文档始终必须列入，因为编写的每一行都受其约束；当改动涉及新 class、endpoint、test 等范围时，还应加入架构、测试或其他相关文档。把这行文字明确写出来，不要只在推理中确定：开发者看到的是你的消息，而不是你的思考；一份没人能看到的文档选择，在它仍然重要时就没人能够纠正。
- 使用 Read 工具读取它们。 短文档要完整阅读；长文档则按标题阅读（
```
grep -n '^#'
```
  是它的目录），并完整阅读标题涵盖本次改动的每个章节。对文档执行关键词 grep 不等于阅读，无论是在编辑前还是编辑后：它只返回包含你原本已经想到的词语的行，并隐藏你没有料到的规则，而标准的存在正是为了提供这条规则。
- 说明阅读结果：给出管辖本次改动的规则，或者说明文档中没有相关内容——«关于这一点没有规则»。同一句话也要放进最终回答，让开发者知道此次改动依据了哪条标准。
对于任何标准无法发表意见的改动——例如注释中的拼写错误、版本号递增——完全跳过这一步，并说明你已跳过。
精准改动。 只修改请求明确指出的内容，不触碰相邻部分。顺手改进你恰好读到的代码，是两行改动变成需要评审的最常见原因。
先复用，再编写。 如果代码库中已经存在所需实现，就直接使用。如果语言或框架已经提供，也直接使用。
运行已有测试来覆盖改动。 如果相关测试已经存在且运行成本低，就运行并说明结果。不要在这里编写新测试——需要新测试的改动属于一项任务，应交由
```
implement-task
```
处理。
成本低意味着环境已经就绪：机器上已有运行时、依赖已安装，或项目自己的容器已经启动。拉取镜像、启动容器或创建网络来运行测试或语法检查，无论命令看起来多短，都不属于低成本——Docker daemon 正在运行，只代表具备构建环境的能力，并不等于环境已经就绪，而在开发者自己的机器上构建环境应由他们决定。镜像会留在磁盘上，而从客户端项目副本启动的容器，可能与旁边运行着真实项目的 compose 网络和卷发生冲突。因此，未经开发者明确同意，完全不要执行任何
```
docker
```
、
```
podman
```
或
```
docker compose
```
命令，连检查 daemon 是否运行也不要。当现有条件无法运行检查时，在回答中说明未运行及其原因，并给出开发者可以自行执行的准确命令——
```
php -l <file>
```
、
```
php artisan test --filter=<TestClass>
```
，或项目自己的检查命令。
回到开发者身边，只回答 diff 中看不出的内容。 先指出文件和具体行号，方便开发者跳转查看，然后只补充 diff 没有说明的信息：改动仍然留下的边界情况、无法运行的测试及原因，或附近某个现在看起来不对的地方。不要标题、报告或改动摘要——开发者马上就会查看 diff。如果 diff 之外没有需要说明的内容，一句话就是完整回答。使用开发者正在使用的语言作答——俄罗斯语请求得到俄罗斯语回答——而代码及其中注释保持英文，因为代码库如此。

任何不会改变开发者行动的结论，要么经过验证，要么不要写出来。 “我阅读了框架，这个用例的行为和之前一样”会让他们花一段话了解什么都没发生。要么实际运行并报告结果，要么什么都不说，让未改变的行为保持不变。只有能促使他们采取不同行动的内容才应保留：停下来、查看某处、决定某件事。

这取代了按句子数量计数的做法，因为句子数量衡量错了对象：四句有实质内容的话不算繁文缛节，而“已完成，需要我提交的话告诉我”用两句话就纯属仪式。这套 skill 中只有在模板某个字段需要限定长度时，才保留句子数量限制，绝不会用它限制整个回答。

Committing

提交

Not part of this. When the developer wants the change committed they will say so, and the

commit

skill owns the convention.

不属于本 skill 的范围。开发者希望提交改动时会明确说明，届时由

commit

skill 负责相关约定。

Never

绝不执行

Never improve code you happened to read. The request names what changes; everything adjacent stays as it is, however wrong it looks.
Never write new tests here. A change that needs them is a task, and belongs to
```
implement-task
```
.
Never commit. The developer is watching and commits when they are ready, with
```
commit
```
.
Never pull an image, start a container or create a network to check a change unless the developer said so. What the check needs and does not have goes into the answer as a command for them to run.

绝不改进你恰好读到的代码。请求指定了需要更改的内容；所有相邻内容都保持原样，无论看起来多么不对。
绝不在这里编写新测试。需要新测试的改动属于一项任务，应交由
```
implement-task
```
处理。
绝不提交。开发者正在关注进度，准备好后会使用
```
commit
```
自行提交。
未经开发者同意，绝不拉取镜像、启动容器或创建网络来检查改动。检查所需但当前不具备的条件，应以命令形式写入回答，供开发者运行。