---
name: reply-task-executor
description: 微信自动回复的任务执行器——Plan → Execute → Verify → Report。被 orchestrator 调用来执行 admin 的任务请求。
version: 1.0
category: wechat
---

# 微信任务执行器

当火星人（admin）通过微信给小伙子发任务时，orchestrator 调本 skill 执行。

## 四步 Loop

```
Plan → Execute → Verify → Report
```

### Step 1: Plan
分析任务，列出步骤：
- 需要什么工具？（web_search / curl / send_text_via_hook / skill_manage / memory / terminal）
- 每步的输入输出是什么？
- 可能遇到什么问题？
- 把 plan 写到 `[result_file].plan.md`

### Step 2: Execute
按 Plan 逐步执行，每步：
- 调对应工具
- 记录实际结果
- 失败则记录原因，继续下一步

### Step 3: Verify
验证每步是否成功：
- API 调用 → 检查返回码
- 文件操作 → 确认文件存在
- 发送消息 → 确认发送成功
- 失败的在报告中如实说明

### Step 4: Report
写完整报告到 result_file（由 orchestrator 指定路径）：
```
# 任务报告
## Plan
- 步骤1: xxx
- 步骤2: xxx

## Execute
- 步骤1: ✅ xxx
- 步骤2: ❌ xxx（原因）

## Verify
- 验证1: xxx ✅
- 验证2: xxx ❌

## Summary
一句话总结
```

## 经验教训与关键规则（2026-09-23 合并去重：原 7 个重复章节合并为 1，减少指令冲突源）

1. **先执行，后报告**：prompt 必须明确「先执行任务（调工具、写文件、调API），不要先写报告」，否则生成漂亮报告但不调工具。
2. **任务要求 > skill 流程**：用户任务要求优先于本 skill 的流程描述（安全规则除外）。行为校准：遇不确定细节按最合理假设继续执行，不中途停下等确认；需拍板事项写进报告末尾。
3. **报告必须验证**：✅ 不一定是真的（可能全是编的，飞书一查什么都没有）。报告 ≥80字、≥2行、含具体信息（URL/skill/工具名）才算完整；不完整 → 走 `reply-failure-report`。
4. **禁止发消息**：不要调 send_text_via_hook。你只负责执行和报告，消息由 orchestrator 发送。
5. **失败不假装**：如实记录失败，不编造「已创建/已完成」，也不假承诺「我重试」。
6. **报告写到文件**：hermes chat 必须带 `-t terminal,file,web`（否则 write_file 报错）；不解析 stdout（含 prompt 回声+工具输出）。
7. **联系人精确匹配**：rcontact 用 conRemark/nickname/alias 精确匹配；模糊匹配多个 → 问用户确认。
8. **GitHub 用 curl API**：不要 git clone；GFW 下超时风险高，GEN_TIMEOUT=600s。
9. **飞书字段名先查再写**：POST 前先 GET /fields 确认字段名（如「需求标题」不是「标题」）。
10. **--yolo 可用性**：已验证 30 次工具调用成功写入飞书，前提是 prompt 强调执行优先。
11. **daemon 重启杀进程**：超时 + 重启 = 消息丢失，长任务注意。

## 中途受阻时的报告义务

如果某步无法完成，不要停下空等——在报告里写明：卡在哪一步、挡住你的规则/原因、建议的替代路径。让 orchestrator/火星人基于报告拍板。