impl-do

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implementation Workflow

实现工作流

Core Principles

核心原则

Execute tasks by dependency - Pick any task with no unresolved dependencies and execute it
Complete each task fully - Implementation → Verification → Self-review → External review as one unit per task
Complete all tasks without stopping - NEVER stop mid-workflow; continue until all tasks are finished

按依赖关系执行任务 - 选择任何没有未解决依赖的任务并执行
完整完成每个任务 - 针对每个任务，将实现 → 验证 → 自我评审 → 外部评审作为一个整体完成
不间断完成所有任务 - 绝不要在工作流中途停止；持续执行直到所有任务完成

Reference

参考

This workflow uses files from the

.tasks/{YYYY-MM-DD}-{nn}-{slug}/

directory created by impl-plan:

plan.md - Human-readable plan with task descriptions, file paths, and acceptance criteria
plan.json - Machine-readable task list for tracking progress
memory.md - Learnings recorded during task execution (created by this workflow)

See plan-json-schema.md for:

Schema definition of
```
plan.json
```
yq commands to query next executable task and mark tasks complete

此工作流使用由impl-plan创建的

.tasks/{YYYY-MM-DD}-{nn}-{slug}/

目录中的文件：

plan.md - 包含任务描述、文件路径和验收标准的可读计划
plan.json - 用于跟踪进度的机器可读任务列表
memory.md - 任务执行期间记录的经验总结（由此工作流创建）

查看plan-json-schema.md了解：

```
plan.json
```
的Schema定义
查询下一个可执行任务并标记任务完成的yq命令

Documentation Language

文档语言

All documents under

.tasks/

must be written in English.

.tasks/

下的所有文档必须使用英文编写。

Workflow

工作流

Phase 1: Task Planning

阶段1：任务规划

Load the implementation plan and register tasks as todos:

Load the implementation plan from
```
plan.json
```
Register all tasks as todos (all start as "pending")
Ensure review is included after implementation phase

加载实现计划并将任务注册为待办事项：

从
```
plan.json
```
加载实现计划
将所有任务注册为待办事项（初始状态均为“待处理”）
确保在实现阶段后包含评审环节

Loading the Plan

加载计划

Read

plan.json

from the

.tasks/{YYYY-MM-DD}-{nn}-{slug}/

directory.

从

.tasks/{YYYY-MM-DD}-{nn}-{slug}/

目录读取

plan.json

。

Register Todos

注册待办事项

tasks

array using your environment's task management mechanism (e.g., todo tool, task list, or equivalent):

1 task = 1 todo (strict 1:1 mapping)
DO NOT combine multiple tasks into a single todo
Use task prefix as todo ID (e.g.,
```
B1
```
,
```
F2
```
)
Use task title as todo content (e.g.,
```
B1: Create User Model
```
)
If
```
status = "done"
```
, register as "completed" (for resuming interrupted work)
If
```
status = "in_progress"
```
, reset to
```
"pending"
```
in
```
plan.json
```
and register as "pending" (previous execution was interrupted; re-execute from scratch)
If
```
status = "pending"
```
, register as "pending"
Update todo status as each task completes

Example - If

plan.json

has 3 tasks (B1, B2, F1), create exactly 3 todos:

Todo 1: id="B1", content="B1: Create User Model"
Todo 2: id="B2", content="B2: Add API endpoints"
Todo 3: id="F1", content="F1: Build login form"

WRONG: Creating a single todo like "Implement B1, B2, and F1" that combines multiple tasks

使用你的环境中的任务管理机制（如待办工具、任务列表或等效工具）注册并跟踪

tasks

数组中的待办事项：

1个任务 = 1个待办事项（严格1:1映射）
不要将多个任务合并为单个待办事项
使用任务前缀作为待办事项ID（例如
```
B1
```
、
```
F2
```
）
使用任务标题作为待办事项内容（例如
```
B1: Create User Model
```
）
如果
```
status = "done"
```
，注册为“已完成”（用于恢复中断的工作）
如果
```
status = "in_progress"
```
，在
```
plan.json
```
中重置为
```
"pending"
```
并注册为“待处理”（之前的执行被中断；从头重新执行）
如果
```
status = "pending"
```
，注册为“待处理”
随着每个任务完成更新待办事项状态

示例 - 如果

plan.json

有3个任务（B1、B2、F1），请创建恰好3个待办事项：

Todo 1: id="B1", content="B1: Create User Model"
Todo 2: id="B2", content="B2: Add API endpoints"
Todo 3: id="F1", content="F1: Build login form"

错误示例：创建单个待办事项如“Implement B1, B2, and F1”，将多个任务合并

Phase 2: Task Execution

阶段2：任务执行

Execute tasks based on dependency resolution. For each task, perform implementation, self-review, and external review as a single unit.

Task Execution Loop:

Get next task: Find the next executable task from
```
plan.json
```
- Task has
```
status = "pending"
```
- All tasks in
```
dependsOn
```
  have
```
status = "done"
```
  (or
```
dependsOn
```
  is empty)
Mark task as in progress: Set
```
status: "in_progress"
```
in
```
plan.json
```
Read task details: Get task details from
```
plan.md
```
(description, file paths, acceptance criteria, etc.)
Implement: Execute the task implementation
Verify: Run verification checks (see Verification below)
Self-review: Review and fix issues (see Self-Review below)
External review: Request external review via subagent (see External Review below)
Complete task:
- Mark task as complete in
```
plan.json
```
  (set
```
status: "done"
```
  )
- Record learnings in memory.md (see Memory Recording below)
- Git commit all changes (see Git Commit below)
- Update todo status
Repeat: Go to step 1 until all tasks are complete

基于依赖解析执行任务。针对每个任务，将实现、自我评审和外部评审作为一个单元完成。

任务执行循环：

获取下一个任务：从
```
plan.json
```
中找到下一个可执行任务
- 任务的
```
status = "pending"
```
- ```
dependsOn
```
  中的所有任务的
```
status = "done"
```
  （或
```
dependsOn
```
  为空）
标记任务为进行中：在
```
plan.json
```
中设置
```
status: "in_progress"
```
读取任务详情：从
```
plan.md
```
获取任务详情（描述、文件路径、验收标准等）
实现：执行任务实现
验证：运行验证检查（见下方“验证”部分）
自我评审：评审并修复问题（见下方“自我评审”部分）
外部评审：通过子agent请求外部评审（见下方“外部评审”部分）
完成任务：
- 在
```
plan.json
```
  中标记任务为完成（设置
```
status: "done"
```
  ）
- 在memory.md中记录经验总结（见下方“经验记录”部分）
- Git提交所有更改（见下方“Git提交”部分）
- 更新待办事项状态
重复：回到步骤1，直到所有任务完成

Verification

验证

After implementing each task, run verification checks:

Static Analysis
- Run linter (eslint, ruff, golangci-lint, etc.)
- Run type checker if applicable (tsc, mypy, etc.)
Test Execution
- Run existing tests to detect regressions
- Run new tests for implemented features
Build Check
- Verify the project builds successfully
Acceptance Criteria
- Verify all acceptance criteria defined in
```
plan.md
```
  for this task are met
- Each criterion must be explicitly checked and confirmed

Verification Loop (MUST complete before proceeding):

Run all verification checks (including acceptance criteria)
If ANY check fails or ANY acceptance criterion is not met:
- Fix the issues (do NOT just report them)
- Return to step 1 and re-run ALL checks
Only proceed to self-review when ALL checks pass and ALL acceptance criteria are met

CRITICAL: Reporting issues without fixing them is NOT acceptable. The verification loop MUST continue until all checks pass and all acceptance criteria are satisfied.

完成每个任务的实现后，运行验证检查：

静态分析
- 运行代码检查工具（eslint、ruff、golangci-lint等）
- 如有必要，运行类型检查工具（tsc、mypy等）
测试执行
- 运行现有测试以检测回归问题
- 为已实现的功能运行新测试
构建检查
- 验证项目构建成功
验收标准
- 验证
```
plan.md
```
  中为此任务定义的所有验收标准均已满足
- 每个标准必须被明确检查并确认

验证循环（必须完成后才能继续）：

运行所有验证检查（包括验收标准）
如果任何检查失败或任何验收标准未满足：
- 修复问题（不要仅报告问题）
- 返回步骤1并重新运行所有检查
仅当所有检查通过且所有验收标准均满足时，才能进入自我评审环节

关键提示：仅报告问题而不修复是不可接受的。验证循环必须持续到所有检查通过且所有验收标准都满足为止。

Self-Review

自我评审

After verification passes, perform self-review:

Review implemented code for:
- Correctness and adherence to requirements
- Code quality and best practices
- Potential bugs and edge cases
- Security concerns
- Performance issues
Based on review findings, determine response based on fix complexity (NOT issue severity):
- Simple/Moderate fixes: Fix autonomously without user confirmation
- Complex fixes requiring significant changes: Consult user before proceeding
For autonomous fixes:
- Apply fixes directly
- Re-run verification
- Re-run self-review
- Repeat until all issues are resolved
Proceed to External Review ONLY when self-review passes with no issues

Fix Autonomously (regardless of issue severity):

Localized code changes within a few files
Bug fixes and error corrections
Code style and formatting issues
Missing error handling
Performance improvements within current architecture
Documentation improvements
Test coverage additions
Refactoring within existing patterns

Require User Confirmation:

Changes requiring significant architectural restructuring
Modifications spanning many files or modules
Changes that fundamentally alter the implementation approach
Trade-offs between conflicting requirements

验证通过后，执行自我评审：

评审已实现的代码，检查：
- 正确性和对需求的遵循情况
- 代码质量和最佳实践
- 潜在的bug和边缘情况
- 安全问题
- 性能问题
根据评审结果，根据修复复杂度（而非问题严重程度）决定处理方式：
- 简单/中等修复：无需用户确认，自主修复
- 需要重大更改的复杂修复：在进行前咨询用户
对于自主修复：
- 直接应用修复
- 重新运行验证
- 重新执行自我评审
- 重复直到所有问题解决
仅当自我评审无问题通过后，才能进入外部评审

自主修复（无论问题严重程度）：

少数文件内的本地化代码更改
Bug修复和错误纠正
代码风格和格式问题
缺失的错误处理
当前架构内的性能改进
文档改进
测试覆盖率补充
现有模式内的重构

需要用户确认：

需要重大架构调整的更改
跨多个文件或模块的修改
从根本上改变实现方式的更改
冲突需求之间的权衡

External Review

外部评审

After self-review passes, perform external review using a subagent:

IMPORTANT: External review is high-cost. Resolve all self-review issues BEFORE requesting external review.

Launch or resume review subagent
- If no review subagent exists yet, launch one and store the agent ID in session memory
- If a review subagent already exists, resume it using the stored agent ID
- If the subagent has been terminated for any reason, launch a new one and store the new agent ID
Provide task context
- Pass the current task ID (UUID) and task prefix
- Instruct the subagent to read the corresponding section in
```
plan.md
```
  for acceptance criteria, target files, and design intent
- Provide the list of files changed in this task
- Instruct the subagent to read the relevant codebase (changed files and their surrounding context)
Process review findings
- Identify all issues and suggestions from subagent response
If issues exist:
- Fix all identified issues
- Re-run verification
- Perform self-review again
- Resume the same subagent using the stored agent ID
- Repeat until external review passes
If no issues:
- External review passed
- Mark task as complete and proceed to next task
- Do NOT terminate the subagent (it will be reused for the next task)

自我评审通过后，使用子agent执行外部评审：

重要提示：外部评审成本高。在请求外部评审前，解决所有自我评审发现的问题。

启动或恢复评审子agent
- 如果还没有评审子agent，启动一个并将agent ID存储在会话内存中
- 如果评审子agent已存在，使用存储的agent ID恢复它
- 如果子agent因任何原因被终止，启动一个新的并存储新的agent ID
提供任务上下文
- 传递当前任务ID（UUID）和任务前缀
- 指示子agent读取
```
plan.md
```
  中的对应部分，了解验收标准、目标文件和设计意图
- 提供此任务中更改的文件列表
- 指示子agent读取相关代码库（更改的文件及其周围上下文）
处理评审结果
- 从子agent的响应中识别所有问题和建议
如果存在问题：
- 修复所有已识别的问题
- 重新运行验证
- 再次执行自我评审
- 使用存储的agent ID恢复同一个子agent
- 重复直到外部评审通过
如果没有问题：
- 外部评审通过
- 标记任务为完成并进入下一个任务
- 不要终止子agent（它将被重用于下一个任务）

Memory Recording

经验记录

After external review passes, record learnings from this task in

.tasks/{YYYY-MM-DD}-{nn}-{slug}/memory.md

Create or update memory.md in the task directory

Title: Use

# {Plan Title} Implementation

as the document title (e.g.,

# User Authentication Implementation

)

Write in English - memory.md is a structured data source for generating other artifacts
Add a new section for this task using the task prefix as heading (e.g.,
```
## B1: Create User Model
```
)
Use the entry template for each learning (see below)

外部评审通过后，在此任务的

.tasks/{YYYY-MM-DD}-{nn}-{slug}/memory.md

中记录经验总结：

在任务目录中创建或更新memory.md

标题：使用

# {Plan Title} Implementation

作为文档标题（例如

# User Authentication Implementation

）

使用英文编写 - memory.md是用于生成其他工件的结构化数据源
为此任务添加新章节，使用任务前缀作为标题（例如
```
## B1: Create User Model
```
）
每个经验总结使用条目模板（见下方）

Entry Template

条目模板

Each learning MUST use the following structure:

markdown

undefined

每个经验总结必须使用以下结构：

markdown

undefined

<Category>: <Title>

Context: What situation triggered this (1-2 sentences)

Problem: What specifically went wrong or was unexpected

Resolution: How it was resolved (MUST include concrete examples: code snippets, config values, commands, error messages, etc.)

Scope:

codebase

task-specific


- **`codebase`**: Applies to any development in this codebase → candidate for agent instruction files (AGENTS.md / CLAUDE.md)
- **`task-specific`**: Specific to this implementation → stays only in memory.md, valuable for future maintenance and debugging of this feature

Context: 触发此情况的场景（1-2句话）

Problem: 具体出现的问题或意外情况

Resolution: 解决方式（必须包含具体示例：代码片段、配置值、命令、错误消息等）

Scope:

codebase

task-specific


- **`codebase`**：适用于此代码库中的任何开发 → 可作为agent指令文件（AGENTS.md / CLAUDE.md）的候选内容
- **`task-specific`**：仅针对此实现 → 仅保留在memory.md中，对未来此功能的维护和调试有价值

What to Record

记录内容

Both codebase-wide and task-specific learnings:

Technical insights specific to this codebase (
```
codebase
```
)
Workarounds for library/framework quirks (
```
codebase
```
)
Configuration or environment discoveries (
```
codebase
```
)
Code patterns that worked well or didn't (
```
codebase
```
)
Testing strategies that proved effective (
```
codebase
```
)
Deviations from the original plan and why (
```
task-specific
```
)
Implementation decisions and their rationale (
```
task-specific
```
)
Integration details specific to this feature (
```
task-specific
```
)
Edge cases encountered and how they were handled (
```
task-specific
```
)

适用于代码库范围和任务特定的经验总结：

此代码库特有的技术见解（
```
codebase
```
）
库/框架 quirks 的解决方法（
```
codebase
```
）
配置或环境发现（
```
codebase
```
）
有效或无效的代码模式（
```
codebase
```
）
被证明有效的测试策略（
```
codebase
```
）
与原始计划的偏差及原因（
```
task-specific
```
）
实现决策及其理由（
```
task-specific
```
）
此功能特有的集成细节（
```
task-specific
```
）
遇到的边缘情况及其处理方式（
```
task-specific
```
）

What NOT to Record

不记录内容

Generic programming knowledge (not specific to this codebase)
Information already documented elsewhere (README, docs, etc.)

See memory.md for example format.

通用编程知识（非此代码库特有）
已在其他地方记录的信息（README、文档等）

查看memory.md了解示例格式。

Git Commit

Git提交

After recording learnings, commit all changes for this task:

Check for commit message rules
- Look for project-specific commit conventions (e.g.,
```
.gitmessage
```
  ,
```
CONTRIBUTING.md
```
  , or repository rules)
- If rules exist, follow them
Default to Conventional Commits
- If no project-specific rules exist, use Conventional Commits format:
```
<type>(<scope>): <description>
```
- Common types:
```
feat
```
  ,
```
fix
```
  ,
```
refactor
```
  ,
```
test
```
  ,
```
docs
```
  ,
```
chore
```
- Scope: affected module (e.g.,
```
auth
```
  ,
```
api
```
  ,
```
database
```
  )
- Example:
```
feat(auth): add user authentication endpoint
```
Stage and commit
- Stage all changes (if
```
plan.json
```
  is not gitignored, include it as well)
- Create commit with appropriate message
- Do NOT push (user will decide when to push)

Note: If

plan.json

is not gitignored, including it in the commit ensures consistency when resuming interrupted work. If it is gitignored, it will be automatically excluded and the commit will proceed normally.

记录经验总结后，提交此任务的所有更改：

检查提交消息规则
- 查找项目特定的提交约定（例如
```
.gitmessage
```
  、
```
CONTRIBUTING.md
```
  或仓库规则）
- 如果存在规则，遵循它们
默认使用Conventional Commits
- 如果没有项目特定规则，使用Conventional Commits格式：
```
<type>(<scope>): <description>
```
- 常见类型：
```
feat
```
  、
```
fix
```
  、
```
refactor
```
  、
```
test
```
  、
```
docs
```
  、
```
chore
```
- 范围：受影响的模块（例如
```
auth
```
  、
```
api
```
  、
```
database
```
  ）
- 示例：
```
feat(auth): add user authentication endpoint
```
暂存并提交
- 暂存所有更改（如果
```
plan.json
```
  未被git忽略，也将其包含在内）
- 使用合适的消息创建提交
- 不要推送（用户将决定何时推送）

注意：如果

plan.json

未被git忽略，将其包含在提交中可确保恢复中断工作时的一致性。如果它被git忽略，将自动被排除，提交将正常进行。

Phase 3: Completion

阶段3：完成

Before reporting completion to user:

Verify all tasks in
```
plan.json
```
have
```
status = "done"
```
Verify all todos are marked as completed
If any task is incomplete, return to Phase 2 and complete remaining tasks
Update agent instruction files with learnings (see below)
External review of agent instruction updates: Resume the review subagent and request review of the updated agent instruction files (see below)

Git commit the updates (use commit message:

docs: update agent instructions with learnings from {slug}

)

Terminate review subagent: If a review subagent was used and a terminate function is available, terminate it by specifying the stored agent ID. If termination is not supported, do nothing.
Provide summary of completed work

向用户报告完成前：

验证
```
plan.json
```
中的所有任务的
```
status = "done"
```
验证所有待办事项均标记为已完成
如果有任何任务未完成，返回阶段2完成剩余任务
使用经验总结更新agent指令文件（见下方）
agent指令更新的外部评审：恢复评审子agent并请求评审更新后的agent指令文件（见下方）

Git提交更新（使用提交消息：

docs: update agent instructions with learnings from {slug}

）

终止评审子agent：如果使用了评审子agent且有终止功能可用，通过指定存储的agent ID终止它。如果不支持终止，无需操作。
提供已完成工作的摘要

Update Agent Instruction Files

更新Agent指令文件

Integrate universally applicable learnings from

memory.md

into agent instruction files (

AGENTS.md

and/or

CLAUDE.md

将

memory.md

中具有普遍适用性的经验总结整合到agent指令文件（

AGENTS.md

和/或

CLAUDE.md

）中。

Step 1: Determine Update Targets

步骤1：确定更新目标

Scan the repository for

AGENTS.md

and

CLAUDE.md

files (they can exist at root AND in subdirectories). Then determine which files to update:

Condition	Update target
Only `AGENTS.md` exists	`AGENTS.md`
Only `CLAUDE.md` exists	`CLAUDE.md`
Both exist independently	Both `AGENTS.md` and `CLAUDE.md`
One references the other (e.g., contains `@CLAUDE.md` or `@AGENTS.md` )	Only the file with actual content (skip the reference-only file)

Reference detection: A file is considered a reference-only file if its primary content is a reference to the other file (e.g.,

See @CLAUDE.md

@AGENTS.md

). Such files should NOT be updated — only the file with substantive content is the update target.

If neither file exists anywhere, create

AGENTS.md

at repository root.

扫描仓库查找

AGENTS.md

和

CLAUDE.md

文件（它们可以存在于根目录和子目录中）。然后确定要更新的文件：

条件	更新目标
仅存在 `AGENTS.md`	`AGENTS.md`
仅存在 `CLAUDE.md`	`CLAUDE.md`
两者独立存在	`AGENTS.md` 和 `CLAUDE.md`
一个引用另一个（例如包含 `@CLAUDE.md` 或 `@AGENTS.md` ）	仅更新包含实际内容的文件（跳过仅引用的文件）

引用检测：如果文件的主要内容是对另一个文件的引用（例如

See @CLAUDE.md

或

@AGENTS.md

），则该文件被视为仅引用文件 —— 不应更新此类文件，仅更新包含实质性内容的文件。

如果两者都不存在，在仓库根目录创建

AGENTS.md

。

Step 2: Find All Target Files

步骤2：查找所有目标文件

Target files can exist at repository root AND in subdirectories
Each file applies to its directory and descendants

Example locations:

./AGENTS.md

./backend/CLAUDE.md

./frontend/AGENTS.md

示例位置：

./AGENTS.md

、

./backend/CLAUDE.md

、

./frontend/AGENTS.md

Step 3: Read and Understand Existing Structure

步骤3：阅读并理解现有结构

Read the entire target file before making changes
Identify existing sections and their purposes
Understand the organizational pattern used in the file

在进行更改前，阅读整个目标文件
识别现有章节及其用途
理解文件中使用的组织模式

Step 4: Review and Filter Learnings

步骤4：评审并筛选经验总结

Review ALL entries in

memory.md

and determine which belong in agent instruction files:

```
Scope
```
is a hint, not a definitive filter — the agent that wrote it may have misclassified entries
```
Scope: codebase
```
entries are strong candidates, but still verify they are truly universal
```
Scope: task-specific
```
entries should also be reviewed — some may contain patterns, conventions, or gotchas that apply beyond the current task
Apply the include/exclude criteria in Step 6 as the final decision basis

评审

memory.md

中的所有条目，确定哪些应纳入agent指令文件：

```
Scope
```
是提示，而非绝对筛选条件 —— 编写它的agent可能对条目分类错误
```
Scope: codebase
```
的条目是强候选，但仍需验证它们是否真正具有普遍性
```
Scope: task-specific
```
的条目也应被评审 —— 其中一些可能包含超越当前任务的模式、约定或注意事项
以步骤6中的包含/排除标准作为最终决策依据

Step 5: Match Learnings to Appropriate File

步骤5：将经验总结匹配到合适的文件

Review each selected learning
Determine which directory scope the learning applies to
Update the target file closest to the relevant code
Example: Backend database learnings →
```
./backend/AGENTS.md
```
(if exists) or
```
./AGENTS.md
```

评审每个选定的经验总结
确定该经验总结适用于哪个目录范围
更新最接近相关代码的目标文件
示例：后端数据库经验总结 →
```
./backend/AGENTS.md
```
（如果存在）或
```
./AGENTS.md
```

Step 6: Integrate into Existing Structure

步骤6：整合到现有结构中

DO NOT create a "Learnings" section:

Find the most appropriate existing section for each learning
If a section for that topic exists, add to it or update existing content
If no suitable section exists, create a descriptive section name that matches the topic (e.g., "Database Patterns", "API Conventions", "Testing Guidelines")
Merge related information rather than duplicating
Keep entries concise and actionable
Focus on "what every developer should know"

Include:

Codebase-specific conventions discovered
Non-obvious configuration requirements
Integration patterns with external systems
Common pitfalls and how to avoid them
Testing patterns specific to this codebase

Do NOT include:

Implementation details that only matter for this specific task and have no broader applicability
Temporary workarounds
Information already documented in README or other docs
Generic best practices (not codebase-specific)
A generic "Learnings" or "Learning" section (integrate into topic-specific sections instead)

不要创建“经验总结”章节：

为每个经验总结找到最合适的现有章节
如果存在相关主题的章节，添加到其中或更新现有内容
如果没有合适的章节，创建一个与主题匹配的描述性章节名称（例如“数据库模式”、“API约定”、“测试指南”）
合并相关信息，避免重复
保持条目简洁且可操作
聚焦于“每个开发人员都应知道的内容”

包含：

发现的代码库特定约定
非显而易见的配置要求
与外部系统的集成模式
常见陷阱及避免方法
此代码库特有的测试模式

不包含：

仅对当前任务重要、无更广泛适用性的实现细节
临时解决方法
已在README或其他文档中记录的信息
通用最佳实践（非代码库特有）
通用的“经验总结”章节（而是整合到特定主题章节中）

External Review of Agent Instruction Updates

Agent指令更新的外部评审

After updating agent instruction files, request external review using the same review subagent:

Resume or re-launch the review subagent — if the stored agent ID is still valid, resume it; otherwise launch a new one and store the new agent ID
Provide the updated files for review — include the diff or full content of each updated agent instruction file
Review criteria for agent instruction files:
- Are the learnings correctly scoped (codebase-wide, not task-specific)?
- Are entries placed in appropriate sections?
- Are entries concise, actionable, and useful for other developers?
- Is there any duplication with existing content?
- Does the content read naturally within the existing document structure?
If issues exist: Fix all identified issues, then resume the subagent for re-review
If no issues: Proceed to git commit

更新agent指令文件后，使用同一个评审子agent请求外部评审：

恢复或重新启动评审子agent —— 如果存储的agent ID仍然有效，恢复它；否则启动一个新的并存储新的agent ID
提供更新后的文件供评审 —— 包含每个更新的agent指令文件的差异或完整内容
agent指令文件的评审标准：
- 经验总结的范围是否正确（代码库范围，非任务特定）？
- 条目是否放置在合适的章节中？
- 条目是否简洁、可操作且对其他开发人员有用？
- 是否与现有内容重复？
- 内容在现有文档结构中是否自然？
如果存在问题：修复所有已识别的问题，然后恢复子agent进行重新评审
如果没有问题：继续进行git提交

Important Rules

重要规则

NEVER stop mid-workflow - Complete ALL tasks from start to finish without interruption
Execute tasks by dependency - Pick any task where all dependencies are complete; no strict execution order
Complete each task fully before moving to next - Implementation → Verification → Self-review → External review → Memory → Commit → Mark complete
Run verification after implementation - Execute lint, tests, and build checks; fix all issues before self-review
Resolve ALL self-review issues before external review - External review is high-cost; do not waste it on issues you can find yourself
Use single subagent for external review - Launch at first external review, reuse across ALL tasks in Phase 2 and for agent instruction file review in Phase 3
Re-launch subagent if terminated - If the subagent has been terminated unexpectedly, launch a new one, store the new agent ID, and have it read plan.md and relevant codebase before proceeding
Keep subagent ID in session memory - Store the agent ID to resume the same subagent for all external reviews throughout the workflow
Terminate subagent only after Phase 3 review - Do NOT terminate the review subagent until agent instruction file review is complete
Record learnings in memory.md - After each task, document discoveries, gotchas, and patterns in memory.md
Update appropriate agent instruction files - AGENTS.md / CLAUDE.md can exist in root and subdirectories; determine update targets per Step 1 rules and match learnings to the closest relevant file
Create AGENTS.md if neither exists - If no AGENTS.md or CLAUDE.md exists in the repository, create AGENTS.md at root with universal learnings
Fix review findings autonomously based on fix complexity - do NOT ask user permission for simple/moderate fixes
Only consult user when fixes require significant architectural changes or widespread modifications

绝不要在工作流中途停止 - 从头到尾完成所有任务，不要中断
按依赖关系执行任务 - 选择所有依赖都已完成的任务；无严格执行顺序
完成每个任务后再进行下一个 - 实现 → 验证 → 自我评审 → 外部评审 → 经验记录 → 提交 → 标记完成
实现后运行验证 - 执行代码检查、测试和构建检查；自我评审前修复所有问题
外部评审前解决所有自我评审问题 - 外部评审成本高；不要浪费在你自己可以发现的问题上
使用单个子agent进行外部评审 - 在第一次外部评审时启动，在阶段2的所有任务和阶段3的agent指令文件评审中重复使用
如果子agent被终止，重新启动 - 如果子agent意外终止，启动一个新的，存储新的agent ID，并让它读取plan.md和相关代码库后再继续
在会话内存中保留子agent ID - 存储agent ID以在整个工作流中恢复同一个子agent进行所有外部评审
仅在阶段3评审完成后终止子agent - 不要终止评审子agent，直到agent指令文件评审完成
在memory.md中记录经验总结 - 每个任务完成后，在memory.md中记录发现、注意事项和模式
更新适当的agent指令文件 - AGENTS.md / CLAUDE.md可以存在于根目录和子目录中；根据步骤1的规则确定更新目标，并将经验总结匹配到最接近的相关文件
如果两者都不存在，创建AGENTS.md - 如果仓库中没有AGENTS.md或CLAUDE.md，在根目录创建AGENTS.md并添加通用经验总结
根据修复复杂度自主修复评审发现的问题 - 简单/中等修复无需询问用户权限
仅当修复需要重大架构更改或广泛修改时才咨询用户