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