4-step-program

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

The 4 Step Program

四步流程法

A coordinator workflow for orchestrating dockeragents. You delegate, they implement. You enforce the loop until quality is achieved.

用于编排dockeragents的协调工作流。你负责委派任务，agents负责执行。你需要监督这个循环，直到达到要求的质量标准。

⚠️ MANDATORY: GitHub PR Posting

⚠️ 强制要求：GitHub PR 提交

Every code review MUST be posted to GitHub as a PR comment. This is NOT optional.

The code-reviewer agent MUST post their review to the PR
A review that is not posted to GitHub means the task has FAILED
The human needs to see the review on the PR page to evaluate quality before merging
If the agent reports completion without posting to GitHub, send them back to post it

每一次代码审查都必须作为PR评论发布到GitHub，这是硬性要求，没有例外。

代码审查agent必须将审查结果发布到PR中
未发布到GitHub的审查视为任务失败
人类需要在PR页面查看审查结果，才能在合并前评估质量
如果agent报告任务完成但未发布到GitHub，需将其退回重新发布

The Loop

循环流程

┌─────────────────────────────────────────────────────┐
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│  │ 1. FIX   │───►│ 2. REVIEW│───►│ 3. 10/10?   │  │
│  │ (agent)  │    │ (agent)  │    │ (you check) │  │
│  └──────────┘    └──────────┘    └──────┬───────┘  │
│       ▲                                 │          │
│       │                                 │          │
│       │ NO                              │ YES      │
│       └─────────────────────────────────┤          │
│                                         ▼          │
│                                 ┌──────────────┐   │
│                                 │ 4. PRESENT   │   │
│                                 │ (you + URLs) │   │
│                                 └──────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────┐
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────────┐  │
│  │ 1. 修复  │───►│ 2. 审查│───►│ 3. 是否10/10?│  │
│  │ (agent)  │    │ (agent)  │    │ (你负责检查) │  │
│  └──────────┘    └──────────┘    └──────┬───────┘  │
│       ▲                                 │          │
│       │                                 │          │
│       │ 否                              │ 是      │
│       └─────────────────────────────────┤          │
│                                         ▼          │
│                                 ┌──────────────┐   │
│                                 │ 4. 展示成果   │   │
│                                 │ (你+链接地址) │   │
│                                 └──────────────┘   │
│                                                     │
└─────────────────────────────────────────────────────┘

Step 1: Delegate FIX to Agent

步骤1：将修复任务委派给Agent

Assign the implementation task to a dockeragent:

assign_task(agent_id, task_description)

The task description MUST include:

Clear action to perform
Context (issue numbers, file paths, errors)
ALL requirements from the issue/task (100% must be implemented)
Success criteria
Instruction to self-review using
```
Skill(code-reviewer)
```
and POST to GitHub when done

CRITICAL: 100% Issue Coverage Requirement

When delegating, you MUST:

Read the full issue:
```
gh issue view <number>
```
Extract EVERY requirement, acceptance criterion, and edge case
Include ALL of them in the delegation prompt
Make it clear that 100% of requirements must be implemented

Example delegation:

"Fix the authentication bug in
src/auth.ts
(Issue #45).
Requirements from issue (ALL must be implemented):

Session token expires correctly after 24 hours

Refresh token works when session token expires

Error message shown when both tokens expire

User redirected to login page on auth failure

Success: ALL 4 requirements implemented, tests pass, bug no longer reproducible.
When complete, run
Skill(code-reviewer)
on your changes, POST the review to GitHub, and report the results with the PR link."

IMPORTANT: The agent MUST ALWAYS create PR for work, or update the existing PR with the work they've done.

CRITICAL: PR Must Link and Close Issues

When creating PR, agent MUST:

Use
```
Closes #X
```
or
```
Fixes #X
```
in PR body for each issue being addressed
Include "Related Issues" section listing all related issues

Verify issue links with

gh pr view --json closingIssuesReferences

Example PR body must include:

markdown

undefined

将实现任务分配给dockeragent：

assign_task(agent_id, task_description)

任务描述必须包含：

明确的执行动作
上下文信息（问题编号、文件路径、错误信息）
需求的完整覆盖（必须100%实现所有需求）
成功标准
完成后使用
```
Skill(code-reviewer)
```
进行自我审查并发布到GitHub的指令

关键要求：100%需求覆盖

委派任务时，你必须：

完整阅读问题：
```
gh issue view <number>
```
提取所有需求、验收标准和边缘情况
将所有内容包含在委派提示中
明确要求必须100%实现所有需求

委派示例：

"修复
src/auth.ts
中的认证漏洞（问题#45）。
问题中的所有需求（必须全部实现）：

Session令牌在24小时后正确过期

Session令牌过期后刷新令牌可正常工作

双令牌均过期时显示错误提示

认证失败时将用户重定向到登录页面

成功标准：所有4项需求均已实现，测试通过，漏洞不再复现。
完成后，对变更执行
Skill(code-reviewer)
审查，将审查结果发布到GitHub，并附带PR链接报告结果。"

重要提示：Agent必须始终为工作内容创建PR，或在现有PR中更新已完成的工作。

关键要求：PR必须关联并关闭问题

创建PR时，Agent必须：

在PR正文中使用
```
Closes #X
```
或
```
Fixes #X
```
来关联每个要解决的问题
包含“相关问题”部分，列出所有相关问题

使用

gh pr view --json closingIssuesReferences

验证问题关联

PR正文示例必须包含：

markdown

undefined

Related Issues

Step 2: Agent Performs REVIEW (MUST POST TO GITHUB)

步骤2：Agent执行审查（必须发布到GitHub）

The dockeragent MUST invoke the code-reviewer skill on their own work:

Skill(code-reviewer)

This triggers the 6-pass ultra-critical methodology:

Technical Issues - Runtime failures, type errors, null handling
Code Consistency - Style, patterns, naming conventions
Architecture - Design, dependencies, complexity, coupling
Environment - Compatibility, security, performance risks
Verification - Run build, tests, linting - actual commands
Synthesis - Overall assessment with suggestion counts

dockeragent必须对自己的工作调用代码审查技能：

Skill(code-reviewer)

这会触发六轮超严格审查方法：

技术问题 - 运行时错误、类型错误、空值处理
代码一致性 - 风格、模式、命名规范
架构设计 - 设计方案、依赖关系、复杂度、耦合度
环境兼容性 - 兼容性、安全性、性能风险
验证环节 - 执行构建、测试、代码检查的实际命令
综合评估 - 整体评估及建议统计

CRITICAL: Review MUST Be Posted to GitHub

关键要求：审查结果必须发布到GitHub

The review is NOT complete until it is posted to GitHub as a PR review/comment.

The code-reviewer skill will:

Analyze the PR changes
Generate the ultra-critical review
POST the review to GitHub using
mcp__github__create_pull_request_review

The human needs to see the review on the PR page. A local-only review that isn't posted to GitHub is useless - the human won't see it and can't evaluate the quality before merging.

Delegation must include:

"After reviewing, POST your review to GitHub. The human must be able to see your review on the PR page."

The agent reports back with:

Their review results
Confirmation that the review was posted to GitHub
Link to the PR where the review can be seen

IMPORTANT: The agent MUST ALWAYS post the Review as comment on the PR.

只有当审查结果作为PR评论发布到GitHub后，审查才算完成。

代码审查技能会：

分析PR中的变更
生成超严格的审查报告
使用
mcp__github__create_pull_request_review
将审查结果发布到GitHub

人类需要在PR页面查看审查结果。仅在本地完成的审查毫无意义——人类无法看到结果，也无法在合并前评估质量。

委派任务时必须包含：

"审查完成后，将结果发布到GitHub。人类必须能在PR页面看到你的审查内容。"

Agent需反馈以下内容：

审查结果
确认审查已发布到GitHub
可查看审查内容的PR链接

重要提示：Agent必须始终将审查结果作为评论发布到PR中。

Step 3: You CHECK - Is the review 10/10 AND 100% Issue Coverage?

步骤3：检查——审查是否达到10/10且需求100%覆盖？

When the agent reports back, evaluate: Is the review 10/10 AND does it cover 100% of issue requirements?

当Agent反馈结果后，评估以下两点：审查是否达到10/10，且是否100%覆盖了问题中的所有需求？

100% Issue Coverage Check (MANDATORY)

100%需求覆盖检查（强制要求）

BEFORE checking review quality, verify the implementation covers ALL requirements from the original issue/task:

Identify ALL requirements from the original issue:
- Read the issue:
```
gh issue view <number>
```
- Extract every acceptance criterion
- Note every edge case mentioned
- List every functional requirement
Verify each requirement is implemented:
- ✅ Implemented: Code exists that fulfills this requirement
- ❌ NOT Implemented: Requirement missing from implementation
Coverage must be 100%:
- If ANY requirement is missing → Send agent back immediately
- Do NOT proceed to review quality check until coverage is 100%

在检查审查质量之前，必须先验证实现是否覆盖了原始问题中的所有需求：

提取问题中的所有需求：
- 阅读问题：
```
gh issue view <number>
```
- 提取所有验收标准
- 记录所有提到的边缘情况
- 列出所有功能需求
验证每个需求是否已实现：
- ✅ 已实现：存在满足该需求的代码
- ❌ 未实现：需求未在实现中体现
必须达到100%覆盖：
- 如果任何需求缺失→立即将Agent退回
- 在覆盖达到100%之前，不得进行审查质量检查

10/10 Review Quality Check

10/10审查质量检查

A 10/10 review means ALL of the following:

100% of issue/task requirements implemented (verified above)
ZERO items in "Suggest Fixing" section
ZERO items in "Possible Simplifications" section
ZERO items in "Consider Asking User" section
ZERO further notes
All verification commands executed and passing
DO NOT ACCEPT POTENTIAL WORK IN REVIEW FOR A LATER PR (this is still a suggestion)
Review MUST be posted to GitHub PR - if not posted, task is incomplete

10/10的审查意味着满足以下所有条件：

100%实现了问题/任务中的所有需求（已通过上述验证）
“建议修复”部分无任何内容
“可能的简化”部分无任何内容
“考虑询问用户”部分无任何内容
无其他补充说明
所有验证命令均已执行且通过
不得接受审查中提到的“后续PR再处理”的潜在工作（这仍属于建议）
审查结果必须已发布到GitHub PR - 若未发布，任务视为未完成

If NOT 10/10 (any suggestions exist):

如果未达到10/10（存在任何建议）：

Send the agent back to fix:

send_message_to_agent(agent_id, "Review shows X suggestions. Fix all of them, then re-review with Skill(code-reviewer) and POST to GitHub.")

→ Loop back to Step 1

将Agent退回进行修复：

send_message_to_agent(agent_id, "审查结果显示有X项建议。请修复所有问题，然后使用Skill(code-reviewer)重新审查并发布到GitHub。")

→ 回到步骤1循环

If YES 10/10 (zero suggestions):

如果达到10/10（无任何建议）：

→ Proceed to Final Coverage Gate

→ 进入最终覆盖验证环节

Step 3.5: FINAL COVERAGE GATE (Before Presenting)

步骤3.5：最终覆盖验证环节（展示前的最后检查）

MANDATORY: Before presenting to human, perform one final 100% coverage verification using LINE-BY-LINE requirement checking.

强制要求：在向人类展示成果前，必须通过逐行需求检查进行最后一次100%覆盖验证。

Final Coverage Check Process

最终覆盖检查流程

Step 1: Extract ALL Requirements from Issue

步骤1：提取问题中的所有需求

bash

undefined

bash

undefined

Get ALL checklist items from issue

获取问题中的所有 checklist 项

gh issue view <number> --json body --jq '.body' | grep -E "^- ["

Also check for requirements in prose (not just checkboxes)

同时检查 prose 中的需求（不仅仅是复选框）

gh issue view <number>


**Don't rely on memory** - actually parse the issue text.

gh issue view <number>


**不要依赖记忆** - 实际解析问题文本。

Step 2: Create Line-by-Line Verification Table

步骤2：创建逐行验证表格

MANDATORY - You MUST create this exact table:

markdown

undefined

强制要求 - 你必须创建如下格式的表格：

markdown

undefined

Issue #X - Full Requirements Check

问题#X - 完整需求检查

Requirement	PR Status	Evidence
[exact text from issue]	✅	`file.ts:line` - [implementation]
[exact text from issue]	❌ MISSING	Not found in PR
[exact text from issue]	⚠️ PARTIAL	`file.ts:line` - [what's missing]
[exact text from issue]	⚠️ MANUAL	Requires [runtime/editor]


Status meanings:
- ✅ = Fully implemented, can cite exact code
- ❌ MISSING = Not implemented at all
- ⚠️ PARTIAL = Partially implemented (counts as NOT done)
- ⚠️ MANUAL = Requires manual verification

需求内容	PR状态	证据
[问题中的原文]	✅	`file.ts:line` - [实现说明]
[问题中的原文]	❌ 缺失	PR中未找到
[问题中的原文]	⚠️ 部分实现	`file.ts:line` - [缺失内容]
[问题中的原文]	⚠️ 手动验证	需要[运行时/编辑器]验证


状态含义：
- ✅ = 完全实现，可引用具体代码
- ❌ 缺失 = 完全未实现
- ⚠️ 部分实现 = 仅实现了部分内容（视为未完成）
- ⚠️ 手动验证 = 需要人工进行运行时/编辑器验证

Step 3: Calculate Honest Coverage

步骤3：计算真实覆盖率

Implemented (✅ only) / Total Requirements = Coverage %

Be brutally honest:

⚠️ PARTIAL = NOT implemented
⚠️ MANUAL items that CAN be automated MUST be
State your confidence explicitly

已实现项（仅✅）/ 总需求数 = 覆盖率 %

务必实事求是：

⚠️ 部分实现 = 未实现
⚠️ 手动验证项若可自动化则必须自动化
明确说明你的置信度

Step 4: Honest Assessment

步骤4：真实评估

markdown

**Honest Assessment**:
- Coverage: X% (Y of Z requirements fully implemented)
- Missing: [list]
- Partial: [list with gaps]
- Manual: [list items needing runtime/editor]

markdown

**真实评估**:
- 覆盖率：X%（Y项需求已完全实现，共Z项）
- 缺失项：[列表]
- 部分实现项：[列表及缺失内容]
- 手动验证项：[需要运行时/编辑器验证的内容]

Coverage Decision

覆盖率决策

Coverage	Action
100%	✅ Proceed to Step 4 (Present)
< 100%	❌ DO NOT PRESENT - Loop back to Step 1

覆盖率	操作
100%	✅ 进入步骤4（展示成果）
< 100%	❌ 不得展示 - 回到步骤1循环

If Coverage < 100%:

如果覆盖率 < 100%:

send_message_to_agent(agent_id, "FINAL COVERAGE CHECK FAILED.

Issue #X - Full Requirements Check:

| Requirement | Status | Evidence |
|-------------|--------|----------|
| [requirement 1] | ✅ | file.ts:45 |
| [requirement 2] | ❌ MISSING | Not in PR |
| [requirement 3] | ⚠️ PARTIAL | Missing X |

Honest Assessment:
- Coverage: W% (Z of Y requirements)
- Missing: [requirement 2]
- Partial: [requirement 3] - needs X

Implement ALL items marked ❌ or ⚠️, then re-review with Skill(code-reviewer) and POST to GitHub.

Do not return until 100% coverage achieved.")

→ Loop back to Step 1

send_message_to_agent(agent_id, "最终覆盖检查未通过。

问题#X - 完整需求检查:

| 需求内容 | 状态 | 证据 |
|-------------|--------|----------|
| [需求1] | ✅ | file.ts:45 |
| [需求2] | ❌ 缺失 | PR中未找到 |
| [需求3] | ⚠️ 部分实现 | 缺失X功能 |

真实评估:
- 覆盖率：W%（Y项需求已实现，共Z项）
- 缺失项：[需求2]
- 部分实现项：[需求3] - 缺少X功能

请实现所有标记为❌或⚠️的项，然后使用Skill(code-reviewer)重新审查并发布到GitHub。

未达到100%覆盖率前不得返回。")

→ 回到步骤1循环

If Coverage = 100%:

如果覆盖率 = 100%:

→ Proceed to Step 4

→ 进入步骤4

Step 4: PRESENT to Human

步骤4：向人类展示成果

Report to the human with:

Summary of what was done
Confirmation of 100% issue coverage (list all requirements met)
PR number with FULL URL link
Related issue links
Mermaid diagrams for complex changes (optional but recommended)

向人类报告以下内容：

工作内容总结
确认100%覆盖了问题需求（列出所有已满足的需求）
PR编号及完整URL链接
相关问题链接
复杂变更的Mermaid图表（可选但推荐）

CRITICAL: URL Formatting

关键要求：URL格式

ALWAYS link PR and issue numbers to URLs. This is mandatory.

始终将PR和问题编号链接到URL，这是强制要求。

Correct:

正确格式:

markdown

[PR #243](https://github.com/owner/repo/pull/243) is ready for review. Resolves [Issue #100](https://github.com/owner/repo/issues/100).

markdown

[PR #243](https://github.com/owner/repo/pull/243) 已准备好审查，解决了[问题 #100](https://github.com/owner/repo/issues/100)。

WRONG:

错误格式:

markdown

PR #243 is ready for review. Resolves Issue #100.

Never write bare

PR #42

Issue #100

. ALWAYS include the full clickable URL.

markdown

PR #243已准备好审查，解决了问题#100。

永远不要只写

PR #42

或

Issue #100

。必须包含可点击的完整URL。

Iteration Limits

迭代限制

Maximum 5 iterations before escalating to human
If agent isn't converging, something is fundamentally wrong
Escalate: "After 5 iterations, agent still has X suggestions. Need guidance."

最多迭代5次，之后需升级给人类处理
如果Agent无法收敛，说明存在根本性问题
升级话术："经过5次迭代后，Agent仍存在X项建议，需要指导。"

Anti-Patterns

反模式

Anti-Pattern	Why It's Wrong
Accepting incomplete issue coverage	Issue had 10 requirements, only 8 implemented = NOT DONE. Send back.
Accepting "mostly done"	Not 10/10 = not done. Send back.
Skipping PR before review	We need a PR BEFORE review.
Skipping review step	Every task gets reviewed. No exceptions.
Reviewing code yourself	You coordinate. Agent reviews with skill.
Bare PR/issue numbers	URLs are mandatory. Always link.
Presenting before 10/10	Loop isn't done. Keep iterating.
Review not posted to GitHub	TASK FAILS. Human can't see local-only reviews. Must be on PR page.
Accepting completion without GitHub post	Send agent back. Review isn't done until posted.

反模式	错误原因
接受不完整的需求覆盖	问题有10项需求，仅实现8项=未完成，需退回。
接受“基本完成”	未达到10/10=未完成，需退回。
审查前跳过PR创建	审查前必须先有PR。
跳过审查步骤	所有任务都必须经过审查，无例外。
自行审查代码	你负责协调，Agent使用技能进行审查。
仅写PR/问题编号	必须使用URL链接，这是强制要求。
未达到10/10就展示	循环未完成，需继续迭代。
审查结果未发布到GitHub	任务失败。人类无法看到本地审查结果，必须发布到PR页面。
接受未发布到GitHub的完成报告	将Agent退回。审查未发布即视为未完成。

❌ Antipattern Examples: What NOT To Do

❌ 反模式示例：切勿这样做

EXECUTIVE SUMMARY: ANY SCORE BELOW 10/10 → DO NOT APPROVE, DO NOT PRESENT EXECUTIVE SUMMARY: ANY COVERAGE BELOW 100% → DO NOT APPROVE, DO NOT PRESENT

执行摘要：任何低于10/10的评分→不得批准，不得展示 执行摘要：任何低于100%的覆盖率→不得批准，不得展示

Antipattern 0: Incomplete Issue Coverage

反模式0：不完整的需求覆盖

❌ WRONG:
"Issue #45 requested 5 features. Agent implemented 4 of them.
Review is 10/10. Ready to present!"

"The main bug is fixed. The edge case mentioned in the issue
can be handled in a follow-up. Presenting to human."

"Agent addressed the core requirements. Minor items from the
issue can be done later."

✅ CORRECT:
"Issue #45 has 5 requirements. Agent implemented 4.
Missing: Requirement 5 (handle timeout errors).
Sending agent back: 'Implement requirement 5 from issue #45 -
handle timeout errors as specified in the acceptance criteria.'"

"Review shows 10/10 quality BUT issue coverage is only 80%.
NOT presenting until 100% of issue requirements are implemented."

Why this is wrong: The issue exists because the user needs ALL the requirements. Presenting partial work means the issue is still not fixed. The user will have to open another issue for the missing requirements.

❌ 错误做法:
"问题#45要求实现5个功能，Agent实现了4个。
审查为10/10，准备展示！"

"主要漏洞已修复，问题中提到的边缘情况可在后续PR中处理，现在向人类展示。"

"Agent处理了核心需求，问题中的次要项可稍后完成。"

✅ 正确做法:
"问题#45有5项需求，Agent实现了4项。
缺失项：需求5（处理超时错误）。
将Agent退回：'实现问题#45中的需求5 - 按照验收标准处理超时错误。'"

"审查为10/10，但需求覆盖率仅为80%。
未达到100%需求覆盖前，不得向人类展示。"

错误原因：问题存在的目的是让用户获得所有需求的解决方案。展示部分完成的工作意味着问题仍未解决，用户将不得不为缺失的需求重新提交问题。

Antipattern 1: "CI Passes, Ready to Merge"

反模式1："CI通过，可合并"

❌ WRONG:
"CI is green and all tests pass. Ready to merge!"
"Build successful, linting passed. Good to go!"

✅ CORRECT:
"CI passes. Now awaiting 10/10 review with all suggestions fixed before presenting to human."

Why this is wrong: CI passing is necessary but NOT sufficient. The loop requires a 10/10 review with ZERO suggestions. CI green + review suggestions = NOT DONE.

❌ 错误做法:
"CI已通过，所有测试通过，可合并！"
"构建成功，代码检查通过，没问题！"

✅ 正确做法:
"CI已通过，现在等待达到10/10的审查结果（所有建议已修复），再向人类展示。"

错误原因：CI通过是必要条件但不充分。循环要求审查达到10/10且无任何建议。CI通过但审查有建议=未完成。

Antipattern 2: "Review 82/100 APPROVED"

反模式2："审查得分82/100，已批准"

❌ WRONG:
"Review: 82/100. Overall solid implementation. APPROVED."
"Review score: 9/10. Verdict: Ready to merge."
"Great work! 95/100, approved with minor notes."

✅ CORRECT:
"Review: 82/100. NOT APPROVED. Agent must fix all 18 points before re-review."
"Review: 9/10. NOT APPROVED. Loop back to Step 1 until 10/10."

Why this is wrong: ANY score below 10/10 means there are issues. Issues mean NOT DONE. Send the agent back. The loop continues until ZERO suggestions remain.

❌ 错误做法:
"审查得分82/100，整体实现扎实，已批准。"
"审查得分9/10，结论：可合并。"
"做得好！95/100，已批准，附带少量说明。"

✅ 正确做法:
"审查得分82/100，未批准。Agent必须修复所有18项问题后重新审查。"
"审查得分9/10，未批准。回到步骤1循环，直到达到10/10。"

错误原因：任何低于10/10的评分都意味着存在问题，有问题即视为未完成。需将Agent退回，直到无任何建议为止。

Antipattern 3: "Agent Needs Push Access / Cherry Pick"

反模式3："Agent需要推送权限/ Cherry Pick"

❌ WRONG:
"Agent completed the work but needs push access to main."
"Changes ready, please cherry-pick commit abc123 to main."
"Work done locally, someone needs to push it."

✅ CORRECT:
"Agent creates branch → Agent creates PR → Review posted as PR comment → 10/10 achieved → Present PR link to human"

Why this is wrong: Agents ALWAYS create a new branch and open a PR. The review goes ON the PR as a comment. No cherry-picking, no manual pushes, no special access needed. The PR IS the deliverable.

❌ 错误做法:
"Agent已完成工作，但需要main分支的推送权限。"
"变更已准备好，请将提交abc123 cherry pick到main分支。"
"工作已在本地完成，需要有人推送。"

✅ 正确做法:
"Agent创建分支→Agent创建PR→审查结果作为PR评论发布→达到10/10→向人类展示PR链接"

错误原因：Agent必须始终创建新分支并打开PR。审查结果需作为评论发布到PR中。无需cherry pick、手动推送或特殊权限。PR就是交付成果。

Antipattern 4: "Good News, Everything Done!" (No Links)

反模式4："好消息，所有工作已完成！"（无链接）

❌ WRONG:
"Good news! Everything is already done! See PR #243 and #244."
"Fixed in PR #100, related to issue #50."
"All tasks complete - check PRs #10, #11, #12."

✅ CORRECT:
"All tasks complete:
- [PR #243](https://github.com/owner/repo/pull/243) - Auth fix
- [PR #244](https://github.com/owner/repo/pull/244) - Test coverage
Related: [Issue #50](https://github.com/owner/repo/issues/50)"

Why this is wrong: Bare numbers are not clickable. The human must be able to click directly to the PR. ALWAYS format as

[PR #N](full-url)

❌ 错误做法:
"好消息！所有工作已完成！查看PR#243和#244。"
"已在PR#100中修复，关联问题#50。"
"所有任务完成 - 查看PR#10、#11、#12。"

✅ 正确做法:
"所有任务已完成：
- [PR #243](https://github.com/owner/repo/pull/243) - 认证修复
- [PR #244](https://github.com/owner/repo/pull/244) - 测试覆盖
关联问题：[问题 #50](https://github.com/owner/repo/issues/50)"

错误原因：仅写编号无法点击。人类必须能直接点击链接跳转到PR。始终使用

[PR #N](完整URL)

格式。

Antipattern 5: "Open Items" Without Links

反模式5："待处理项"无链接

❌ WRONG:
"Open items:
- #535 Nix CI implementation (orphan spacetime branch)
- #102 Database migration pending
- Issue #88 still needs review"

✅ CORRECT:
"Open items:
- [#535](https://github.com/owner/repo/issues/535) - Nix CI implementation (orphan spacetime branch)
- [#102](https://github.com/owner/repo/issues/102) - Database migration pending
- [Issue #88](https://github.com/owner/repo/issues/88) - Still needs review"

Why this is wrong: Every reference to a PR or issue MUST be a clickable link. No exceptions. The human should never have to manually construct a URL.

❌ 错误做法:
"待处理项:
- #535 Nix CI实现（孤立时空分支）
- #102 数据库迁移待处理
- 问题#88仍需审查"

✅ 正确做法:
"待处理项:
- [#535](https://github.com/owner/repo/issues/535) - Nix CI实现（孤立时空分支）
- [#102](https://github.com/owner/repo/issues/102) - 数据库迁移待处理
- [问题 #88](https://github.com/owner/repo/issues/88) - 仍需审查"

错误原因：所有PR或问题的引用都必须是可点击的链接，无例外。人类无需手动构造URL。

Mermaid Diagrams in Reviews and PRs

审查和PR中的Mermaid图表

Agents posting reviews to GitHub SHOULD include Mermaid diagrams when helpful.

Reviews and PRs benefit from visual representation:

Before/after flow changes
Architecture modifications
State machine changes
API interaction sequences

Agent在GitHub发布审查结果时，如有帮助应包含Mermaid图表。

审查和PR可通过可视化表示获益：

变更前后的流程变化
架构修改
状态机变更
API交互序列

When Agents Should Include Diagrams

Agent应包含图表的场景

Change Type	Diagram Recommendation
Bug fix with flow change	`flowchart` showing before/after
New API endpoint	`sequenceDiagram` of request flow
State handling change	`stateDiagram-v2`
Component refactor	`flowchart` with component relationships

变更类型	图表推荐
涉及流程变化的漏洞修复	`flowchart` 展示变更前后的流程
新增API端点	`sequenceDiagram` 展示请求流程
状态处理变更	`stateDiagram-v2`
组件重构	`flowchart` 展示组件关系

Example Review with Diagram

带图表的审查示例

markdown

undefined

markdown

undefined

Review Summary

审查总结

The token refresh implementation correctly handles expiration.

令牌刷新实现可正确处理过期逻辑。

New Flow

新流程

mermaid

sequenceDiagram
    Client->>Server: Request (expired token)
    Server-->>Client: 401
    Client->>Server: POST /refresh
    Server-->>Client: New token
    Client->>Server: Retry request
    Server-->>Client: 200 Success

Score: 10/10 - All requirements met, clean implementation.

---

mermaid

sequenceDiagram
    Client->>Server: 请求（令牌已过期）
    Server-->>Client: 401
    Client->>Server: POST /refresh
    Server-->>Client: 新令牌
    Client->>Server: 重试请求
    Server-->>Client: 200 成功

评分：10/10 - 所有需求已满足，实现简洁。

---

Quick Reference

快速参考

1. DELEGATE   → assign_task with ALL issue requirements + review + GitHub posting instruction
2. WAIT       → Agent fixes + runs Skill(code-reviewer) + POSTS to GitHub
3. CHECK      → TWO gates must pass:
                GATE 1: Is 100% of issue/task requirements implemented?
                        NO  → send_message_to_agent with missing requirements, go to 2
                GATE 2: Is report 10/10 with ZERO suggestions? Is review on PR page?
                        NO  → send_message_to_agent, go to 2
                        YES → go to 3.5
3.5 FINAL GATE → Re-verify 100% coverage one last time before presenting
                 NO (< 100%)  → send_message_to_agent, go to 1
                 YES (100%)   → go to 4
4. PRESENT    → Tell human + CONFIRM 100% coverage + LINK the PR URL + Mermaid diagrams (if complex)

Remember: You don't implement. You orchestrate the loop until 100% coverage AND 10/10. Final gate catches any missed requirements.

After completing the review loop, follow handbook

15.04

to create

tk

tickets for all surfaced issues.

1. 委派任务   → 使用包含所有问题需求+审查+GitHub发布指令的assign_task
2. 等待反馈   → Agent修复+运行Skill(code-reviewer)+发布到GitHub
3. 检查验证   → 必须通过两个关卡：
                关卡1：是否100%实现了问题/任务的所有需求？
                        否  → 向Agent发送缺失需求的消息，回到步骤2
                关卡2：报告是否为10/10且无任何建议？审查是否已发布到PR页面？
                        否  → 向Agent发送消息，回到步骤2
                        是  → 进入步骤3.5
3.5 最终关卡 → 展示前最后一次验证100%覆盖率
                 否（<100%）  → 向Agent发送消息，回到步骤1
                 是（100%）   → 进入步骤4
4. 展示成果   → 告知人类+确认100%覆盖率+附上PR URL+复杂变更可提供Mermaid图表

记住：你无需实现代码，只需编排循环直到达到100%覆盖率和10/10的质量标准。最终关卡可捕获任何遗漏的需求。

完成审查循环后，请按照手册

15.04

为所有发现的问题创建

tk

工单。

4-step-program

Original

Translation

The 4 Step Program

四步流程法

⚠️ MANDATORY: GitHub PR Posting

⚠️ 强制要求：GitHub PR 提交

The Loop

循环流程

Step 1: Delegate FIX to Agent

步骤1：将修复任务委派给Agent

Related Issues

相关问题

Step 2: Agent Performs REVIEW (MUST POST TO GITHUB)

步骤2：Agent执行审查（必须发布到GitHub）

CRITICAL: Review MUST Be Posted to GitHub

关键要求：审查结果必须发布到GitHub

Step 3: You CHECK - Is the review 10/10 AND 100% Issue Coverage?

步骤3：检查——审查是否达到10/10且需求100%覆盖？

100% Issue Coverage Check (MANDATORY)

100%需求覆盖检查（强制要求）

10/10 Review Quality Check

10/10审查质量检查

If NOT 10/10 (any suggestions exist):

如果未达到10/10（存在任何建议）：

If YES 10/10 (zero suggestions):

如果达到10/10（无任何建议）：

Step 3.5: FINAL COVERAGE GATE (Before Presenting)

步骤3.5：最终覆盖验证环节（展示前的最后检查）

Final Coverage Check Process

最终覆盖检查流程

Step 1: Extract ALL Requirements from Issue

步骤1：提取问题中的所有需求

Get ALL checklist items from issue

获取问题中的所有 checklist 项

Also check for requirements in prose (not just checkboxes)

同时检查 prose 中的需求（不仅仅是复选框）

Step 2: Create Line-by-Line Verification Table

步骤2：创建逐行验证表格

Issue #X - Full Requirements Check

问题#X - 完整需求检查

Step 3: Calculate Honest Coverage

步骤3：计算真实覆盖率

Step 4: Honest Assessment

步骤4：真实评估

Coverage Decision

覆盖率决策

If Coverage < 100%:

如果覆盖率 < 100%:

If Coverage = 100%:

如果覆盖率 = 100%:

Step 4: PRESENT to Human

步骤4：向人类展示成果

CRITICAL: URL Formatting

关键要求：URL格式

Correct:

正确格式:

WRONG:

错误格式:

Iteration Limits

迭代限制

Anti-Patterns

反模式

❌ Antipattern Examples: What NOT To Do

❌ 反模式示例：切勿这样做

Antipattern 0: Incomplete Issue Coverage

反模式0：不完整的需求覆盖

Antipattern 1: "CI Passes, Ready to Merge"

反模式1："CI通过，可合并"

Antipattern 2: "Review 82/100 APPROVED"

反模式2："审查得分82/100，已批准"

Antipattern 3: "Agent Needs Push Access / Cherry Pick"

反模式3："Agent需要推送权限/ Cherry Pick"

Antipattern 4: "Good News, Everything Done!" (No Links)

反模式4："好消息，所有工作已完成！"（无链接）

Antipattern 5: "Open Items" Without Links

反模式5："待处理项"无链接

Mermaid Diagrams in Reviews and PRs

审查和PR中的Mermaid图表

When Agents Should Include Diagrams