implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement Skill

Quick Ref: Execute single issue end-to-end. Output: code changes + commit + closed issue.

YOU MUST EXECUTE THIS WORKFLOW. Do not just describe it.

Execute a single issue from start to finish.

CLI dependencies: bd (issue tracking), ao (ratchet gates). Both optional — see

skills/shared/SKILL.md

for fallback table. If bd is unavailable, use the issue description directly and track progress via TaskList instead of beads.

快速参考： 端到端执行单个问题。输出：代码变更 + 提交 + 已关闭问题。

你必须执行此工作流，不能仅进行描述。

从头到尾执行单个问题。

CLI依赖： bd（问题跟踪工具）、ao（ratchet gates）。两者均为可选—— fallback表请查看

skills/shared/SKILL.md

。如果bd不可用，请直接使用问题描述，并通过TaskList而非beads跟踪进度。

Execution Steps

执行步骤

Given

/implement <issue-id-or-description>

当输入

/implement <问题ID或描述>

时：

Step 0: Pre-Flight Checks (Resume + Gates)

步骤0：预检检查（恢复 + 门禁）

For resume protocol details, read
skills/implement/references/resume-protocol.md
.

For ratchet gate checks and pre-mortem gate details, read
skills/implement/references/gate-checks.md
.

恢复协议详情请阅读
skills/implement/references/resume-protocol.md
。

ratchet门禁检查和事前分析门禁详情请阅读
skills/implement/references/gate-checks.md
。

Step 1: Get Issue Details

步骤1：获取问题详情

If beads issue ID provided (e.g.,

gt-123

bash

bd show <issue-id> 2>/dev/null

If plain description provided: Use that as the task description.

If no argument: Check for ready work:

bash

bd ready 2>/dev/null | head -3

如果提供了beads问题ID（例如：

gt-123

）：

bash

bd show <issue-id> 2>/dev/null

如果提供的是普通描述： 将其作为任务描述。

如果没有参数： 查看可处理的工作：

bash

bd ready 2>/dev/null | head -3

Step 2: Claim the Issue

步骤2：认领问题

bash

bd update <issue-id> --status in_progress 2>/dev/null

bash

bd update <issue-id> --status in_progress 2>/dev/null

Step 3: Gather Context

步骤3：收集上下文

USE THE TASK TOOL to explore relevant code:

Tool: Task
Parameters:
  subagent_type: "Explore"
  description: "Gather context for: <issue title>"
  prompt: |
    Find code relevant to: <issue description>

    1. Search for related files (Glob)
    2. Search for relevant keywords (Grep)
    3. Read key files to understand current implementation
    4. Identify where changes need to be made

    Return:
    - Files to modify (paths)
    - Current implementation summary
    - Suggested approach
    - Any risks or concerns

使用任务工具探索相关代码：

工具：Task
参数：
  subagent_type: "Explore"
  description: "为以下内容收集上下文：<问题标题>"
  prompt: |
    查找与以下内容相关的代码：<问题描述>

    1. 搜索相关文件（Glob语法）
    2. 搜索相关关键词（Grep）
    3. 阅读关键文件以理解当前实现
    4. 确定需要修改的位置

    返回：
    - 需要修改的文件（路径）
    - 当前实现概述
    - 建议的实现方案
    - 任何风险或注意事项

Step 4: Implement the Change

步骤4：实现变更

Based on the context gathered:

Edit existing files using the Edit tool (preferred)
Write new files only if necessary using the Write tool
Follow existing patterns in the codebase
Keep changes minimal - don't over-engineer

基于收集到的上下文：

优先使用编辑工具修改现有文件（推荐）
仅在必要时使用写入工具创建新文件
遵循代码库中的现有模式
最小化变更 - 不要过度设计

Step 5: Verify the Change

步骤5：验证变更

Success Criteria (all must pass):

All existing tests pass (no new failures introduced)
New code compiles/parses without errors
No new linter warnings (if linter available)
Change achieves the stated goal

Check for test files and run them:

bash

undefined

成功标准（必须全部满足）：

所有现有测试通过（未引入新的失败）
新代码编译/解析无错误
无新的代码检查警告（如果有代码检查工具）
变更达到预期目标

查找测试文件并运行：

bash

undefined

Find tests

查找测试文件

ls test tests/ test/ tests/ 2>/dev/null | head -5

Run tests (adapt to project type)

运行测试（根据项目类型调整）

Python: pytest

Go: go test ./...

Node: npm test

Rust: cargo test


**If tests exist:** All tests must pass. Any failure = verification failed.

**If no tests exist:** Manual verification required:
- [ ] Syntax check passes (file compiles/parses)
- [ ] Imports resolve correctly
- [ ] Can reproduce expected behavior manually
- [ ] Edge cases identified during implementation are handled

**If verification fails:** Do NOT proceed to Step 5a. Fix the issue first.


**如果存在测试：** 所有测试必须通过。任何失败都意味着验证不通过。

**如果没有测试：** 需要手动验证：
- [ ] 语法检查通过（文件可编译/解析）
- [ ] 依赖导入解析正确
- [ ] 可手动复现预期行为
- [ ] 实现过程中识别的边缘案例已处理

**如果验证失败：** 不要进入步骤5a。先修复问题。

Step 5a: Verification Gate (MANDATORY)

步骤5a：验证门禁（强制要求）

THE IRON LAW: NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

Before reporting success, you MUST:

IDENTIFY - What command proves this claim works?
RUN - Execute the FULL command (fresh, not cached output)
READ - Check full output AND exit code
VERIFY - Does output actually confirm the claim?
ONLY THEN - Make the completion claim

Forbidden phrases without fresh verification evidence:

"should work", "probably fixed", "seems to be working"
"Great!", "Perfect!", "Done!" (without output proof)
"I just ran it" (must run it AGAIN, fresh)

铁律：没有最新验证证据，不得宣称完成

在报告成功前，你必须：

确定 - 用什么命令能证明该功能正常工作？
执行 - 完整运行该命令（最新的，非缓存输出）
查看 - 检查完整输出和退出码
验证 - 输出是否确实能证明功能正常？
只有此时 - 才能宣称完成

无最新验证证据时禁止使用以下表述：

“应该能工作”、“可能修复了”、“看起来正常”
“太棒了！”、“完美！”、“完成了！”（无输出证明）
“我刚运行过”（必须重新运行，获取最新结果）

Rationalization Table

合理化借口对照表

Excuse	Reality
"Too simple to verify"	Simple code breaks. Verification takes 10 seconds.
"I just ran it"	Run it AGAIN. Fresh output only.
"Tests passed earlier"	Run them NOW. State changes.
"It's obvious it works"	Nothing is obvious. Evidence or silence.
"The edit looks correct"	Looking != working. Run the code.

Store checkpoint:

bash

bd update <issue-id> --append-notes "CHECKPOINT: Step 5a verification passed at $(date -Iseconds)" 2>/dev/null

借口	实际情况
“太简单了不需要验证”	简单代码也会出错。验证只需要10秒。
“我刚运行过”	再运行一次。只接受最新输出。
“之前测试通过了”	现在就运行测试。状态会变化。
“显然它能正常工作”	没有什么是显然的。要么拿证据，要么闭嘴。
“修改看起来是对的”	看起来对不代表能运行。运行代码验证。

存储检查点：

bash

bd update <issue-id> --append-notes "CHECKPOINT: Step 5a verification passed at $(date -Iseconds)" 2>/dev/null

Step 6: Commit the Change

步骤6：提交变更

If the change is complete and verified:

bash

git add <modified-files>
git commit -m "<descriptive message>

Implements: <issue-id>"

如果变更已完成且验证通过：

bash

git add <modified-files>
git commit -m "<描述性提交信息>

Implements: <issue-id>"

Step 7: Close the Issue

步骤7：关闭问题

bash

bd update <issue-id> --status closed 2>/dev/null

bash

bd update <issue-id> --status closed 2>/dev/null

Step 7a: Record Implementation in Ratchet Chain

步骤7a：在Ratchet Chain中记录实现

After successful issue closure, record in ratchet:

bash

undefined

成功关闭问题后，在ratchet中记录：

bash

undefined

Check if ao CLI is available

检查ao CLI是否可用

if command -v ao &>/dev/null; then

Get the commit hash as output artifact

COMMIT_HASH=$(git rev-parse HEAD 2>/dev/null || echo "") CHANGED_FILES=$(git diff --name-only HEAD~1 2>/dev/null | tr '\n' ',' | sed 's/,$//')

if [ -n "$COMMIT_HASH" ]; then # Record successful implementation ao ratchet record implement
--output "$COMMIT_HASH"
--files "$CHANGED_FILES"
--issue "<issue-id>"
2>&1 | tee -a .agents/ratchet.log

if [ $? -eq 0 ]; then
  echo "Ratchet: Implementation recorded (commit: ${COMMIT_HASH:0:8})"
else
  echo "Ratchet: Failed to record - chain.jsonl may need repair"
fi

else echo "Ratchet: No commit found - skipping record" fi else echo "Ratchet: ao CLI not available - implementation NOT recorded" echo " Run manually: ao ratchet record implement --output <commit>" fi


**On failure/blocker:** Record the blocker in ratchet:

```bash
if command -v ao &>/dev/null; then
  ao ratchet record implement \
    --status blocked \
    --reason "<blocker description>" \
    2>/dev/null
fi

Fallback: If ao is not available, the issue is still closed via bd but won't be tracked in the ratchet chain. The skill continues normally.

if command -v ao &>/dev/null; then

获取提交哈希作为输出产物

COMMIT_HASH=$(git rev-parse HEAD 2>/dev/null || echo "") CHANGED_FILES=$(git diff --name-only HEAD~1 2>/dev/null | tr '\n' ',' | sed 's/,$//')

if [ -n "$COMMIT_HASH" ]; then # 记录成功的实现 ao ratchet record implement
--output "$COMMIT_HASH"
--files "$CHANGED_FILES"
--issue "<issue-id>"
2>&1 | tee -a .agents/ratchet.log

if [ $? -eq 0 ]; then
  echo "Ratchet: Implementation recorded (commit: ${COMMIT_HASH:0:8})"
else
  echo "Ratchet: Failed to record - chain.jsonl may need repair"
fi

else echo "Ratchet: No commit found - skipping record" fi else echo "Ratchet: ao CLI not available - implementation NOT recorded" echo " 手动运行：ao ratchet record implement --output <commit>" fi


**如果遇到失败/阻塞：** 在ratchet中记录阻塞信息：

```bash
if command -v ao &>/dev/null; then
  ao ratchet record implement \
    --status blocked \
    --reason "<阻塞原因>" \
    2>/dev/null
fi

Fallback方案： 如果ao不可用，问题仍通过bd关闭，但不会在ratchet chain中跟踪记录。该Skill将正常继续执行。

Step 7b: Post-Implementation Ratchet Record

步骤7b：实现完成后在Ratchet中记录

After implementation is complete:

bash

if command -v ao &>/dev/null; then
  ao ratchet record implement --output "<issue-id>" 2>/dev/null || true
fi

Tell user: "Implementation complete. Run /vibe to validate before pushing."

实现完成后：

bash

if command -v ao &>/dev/null; then
  ao ratchet record implement --output "<issue-id>" 2>/dev/null || true
fi

告知用户：“实现已完成。推送前请运行/vibe验证。”

Step 8: Report to User

步骤8：向用户报告

Tell the user:

What was changed (files modified)
How it was verified (with actual command output)
Issue status (closed)
Any follow-up needed
Ratchet status (implementation recorded or skipped)

Output completion marker:

<promise>DONE</promise>

If blocked or incomplete:

<promise>BLOCKED</promise>
Reason: <why blocked>

<promise>PARTIAL</promise>
Remaining: <what's left>

告知用户：

变更内容（修改的文件）
验证方式（附带实际命令输出）
问题状态（已关闭）
任何后续操作需求
Ratchet状态（实现已记录或已跳过）

输出完成标记：

<promise>DONE</promise>

如果遇到阻塞或未完成：

<promise>BLOCKED</promise>
Reason: <阻塞原因>

<promise>PARTIAL</promise>
Remaining: <剩余工作>

Key Rules

核心规则

Explore first - understand before changing
Edit, don't rewrite - prefer Edit tool over Write tool
Follow patterns - match existing code style
Verify changes - run tests or sanity checks
Commit with context - reference the issue ID
Close the issue - update status when done

先探索 - 变更前先理解现有代码
编辑而非重写 - 优先使用Edit工具而非Write工具
遵循现有模式 - 匹配现有代码风格
验证变更 - 运行测试或 sanity检查
带上下文提交 - 引用问题ID
关闭问题 - 完成后更新状态

Without Beads

无Beads的情况

If bd CLI not available:

Skip the claim/close status updates
Use the description as the task
Still commit with descriptive message
Report completion to user

如果bd CLI不可用：

跳过认领/关闭状态更新
使用描述作为任务内容
仍需提交带描述性信息的commit
向用户报告完成情况

Distributed Mode: Agent Mail Coordination

分布式模式：Agent Mail协作

For full distributed mode details, read
skills/implement/references/distributed-mode.md
.

Distributed mode enhances /implement with real-time coordination via MCP Agent Mail when

--mode=distributed

--agent-mail

, or

$OLYMPUS_DEMIGOD_ID

is set.

分布式模式详情请阅读
skills/implement/references/distributed-mode.md
。

当设置

--mode=distributed

、

--agent-mail

或

$OLYMPUS_DEMIGOD_ID

时，分布式模式通过MCP Agent Mail的实时协作增强/implement功能。

References

参考资料

Agent Mail Protocol: See
```
skills/shared/agent-mail-protocol.md
```
for message format specifications
Parser (Go):
```
cli/internal/agentmail/
```
- shared parser for all message types

Agent Mail协议： 消息格式规范请查看
```
skills/shared/agent-mail-protocol.md
```
解析器（Go）：
```
cli/internal/agentmail/
```
- 所有消息类型的共享解析器