debug-prompt-driven-cron-agent-zero-output
用于排查“定时任务成功执行但结果全为 0 / 未检索到样本 / 明明有数据却日报为空”这类问题,尤其适合 Discord、Obsidian、cron、agentTurn、prompt 驱动任务、日整理、复盘脚本、采样漏扫、thread starter 漏计、主频道消息未纳入、Snowflake 字符串比较、时区时间窗边界等场景。只要用户提到“任务跑通了但产物为空”“怀疑不是分类错而是采样漏了”“想确认 prompt job 是否没有固定源码”“想定位检索链路断点”,就应触发此技能。
Install via CLI (Recommended)
clawhub install openclaw/skills/skills/can4hou6joeng4/debug-prompt-driven-cron-agent-zero-output排查纯 Prompt 驱动定时任务为何产出全 0
这个技能帮助你把“任务执行成功但结果为空”的问题快速定位到实现入口、采样链路和高风险断点,从而区分是检索漏扫还是后续分类清零。
When to use this skill
- 当你需要判断一个 cron / agent 任务为什么“跑成功了,但日报、复盘、统计结果全为 0”,并且怀疑问题出在上游检索而不是下游分类。
- 当你面对的是自然语言 prompt 驱动的任务,想确认它是否其实没有固定脚本实现、导致采样方式由模型临场决定。
- 当用户提到 Discord 线程、主频道消息、thread starter、mention、reply、Snowflake、Asia/Shanghai 昨日时间窗等关键词,并想排查样本是否被漏掉。
- 当你需要给出“有证据的根因判断 + 明确边界 + 最小修复建议”,而不是只做泛泛猜测。
Steps
-
先定位任务的真实实现入口
- 打开 cron 配置文件,确认 job 的定义位置与执行类型:
/Users/can4hou6joeng4/.openclaw/cron/jobs.json
- 在目标案例中确认到的关键字段是:
id: "c6e92d09-5ff6-4079-b839-a9c4fe6d2e10"name: "obsidian-discord-guild-daily-review-final"schedule.expr: "0 5 * * *"schedule.tz: "Asia/Shanghai"payload.kind: "agentTurn"payload.message: "你是“小笔(Writer)”执行每日复盘整理..."
- 为什么这一步重要: 先搞清楚它到底是显式脚本任务还是 prompt 任务,才能决定后续排查应该审源码还是审 prompt 与运行痕迹。
- 打开 cron 配置文件,确认 job 的定义位置与执行类型:
-
确认是否存在独立源码、技能或模板实现
- 在工作区与相关目录做关键词检索,目标不是“多找点文件”,而是确认有没有真正负责读取 Discord 数据的固定代码:
/Users/can4hou6joeng4/.openclaw/workspace/Users/can4hou6joeng4/.openclaw/Users/can4hou6joeng4/Documents/code/Ours
- 已实际使用的检索关键词包括:
obsidian-discord-guild-daily-review-finalc6e92d09-5ff6-4079-b839-a9c4fe6d2e101478785297784373490Conversation infothread startermessage_referencementionsdispatch
- 目标案例的结论是:
- 找到了
jobs.json - 找到了 run 记录
- 找到了 Obsidian 产物
- 没找到对应 JS/TS 脚本、skill 实现、模板源码
- 找到了
- 为什么这一步重要: 如果没有独立实现代码,就不能假设“读取 API、分页、样本源覆盖”这些逻辑被明确写死;它们可能完全依赖模型临场决定。
- 在工作区与相关目录做关键词检索,目标不是“多找点文件”,而是确认有没有真正负责读取 Discord 数据的固定代码:
-
把 prompt 中“声明的筛选口径”与“缺失的机械实现”分开看
- 在同一个 job 配置里提取已声明的业务口径:
仅处理 guild: 1478785964896817267仅采集:用户 1478785297784373490 本人发言 + @该用户/回复该用户消息。时间窗:昨日 00:00:00~23:59:59(Asia/Shanghai)。
- 同时明确记录:配置里没有这些可执行级约束:
- 必须调用哪种 Discord read API
- 必须先扫主频道,再扫 thread
- 是否包含 thread starter
- 是否读取 thread replies
- mentions 如何判定
- reply 如何判定
message_reference.message_id/referenced_message.author.id author.id是否强制按字符串比较- 是否做分页 / limit
- 为什么这一步重要: 很多“口径写得很清楚”的任务,真正的问题在于采样实现并没有被固定;只审口径会误判成“逻辑没问题”。
- 在同一个 job 配置里提取已声明的业务口径:
-
读取最终产物,判断“是样本为空,还是分类后归零”
- 检查实际输出文件:
/Users/can4hou6joeng4/Documents/Obsidian/Second Brain/01-Daily/2026-03-13.md/Users/can4hou6joeng4/Documents/Obsidian/Second Brain/00-Inbox/Daily Sync Digest - 2026-03-13.md
- 目标案例中看到的关键措辞是:
当日未检索到符合筛选条件的 Discord 发言、@提及或回复记录。代表性线程 - 无- 分类统计全 0
昨日 Discord 在目标用户与关联互动口径下无有效样本
- 将这类措辞归类为:上游直接认定没有检索到样本,而不是“有样本但分类阶段把它们清成了 0”。
- 为什么这一步重要: 这是判断断点位置的核心证据,能直接把排查重心从分类逻辑转移到检索链路。
- 检查实际输出文件:
Metadata
Not sure this is the right skill?
Describe what you want to build — we'll match you to the best skill from 16,000+ options.
Find the right skillPaste this into your clawhub.json to enable this plugin.
{
"plugins": {
"official-can4hou6joeng4-debug-prompt-driven-cron-agent-zero-output": {
"enabled": true,
"auto_update": true
}
}
}Related Skills
diagnose-openclaw-model-routing-and-fallback-usage
用于分析 OpenClaw 中“某个 provider/模型为什么看起来没被用上”、主模型与 fallback 实际是否生效、以及 ClaudeCodeCLI 协作任务为何中断。遇到这些情况就应触发:用户提到“没请求打到 local-router”“明明注册了模型却没流量”“Agent 到底在用哪个模型”“fallback 有没有发生”“为什么日志里看不到候选切换”“code 143 / SIGTERM / Exec failed”“需要结合当前配置和日志做严谨归因”。也适用于区分“provider 被调用”与“provider 下某个特定模型被调用”这两类常见混淆。
configure-openclaw-anyrouter-model-and-fix-baseurl
用于在 OpenClaw 中新增或覆盖 anyrouter 模型配置、把小肠 Agent 默认模型切到 `anyrouter/claude-opus-4-6`,并结合运行日志判断是不是 `baseUrl`、网关兼容、鉴权或协议端点导致不可用。遇到“把某个供应商模型写进 openclaw.json”“切换默认模型”“为什么配置生效了但实际没调用上”“查看 fallback 日志”“排查 403/500/invalid claude code request”“同步 ClaudeCode 配置”这类需求时,就应启用本技能;即使用户没明确说 OpenClaw,只要描述的是本地 Agent 模型路由切换与调用异常排查,也适用。
diagnose-scheduled-job-trigger-vs-execution-failure
用于排查“定时任务没执行”这类问题,并区分到底是未触发、已触发但执行失败,还是运行环境/授权失效导致的假象。遇到 cron 异常、任务未跑、自动任务失灵、网关重启后要验证恢复、怀疑是模型导致任务失败、需要查看日志作证、需要给出证据口径、要确认 `deactivated_workspace` / OAuth token 失效 / timeout 是否为根因时,都应触发本技能。也适用于“任务其实有 run 记录,但结果是 error”“想确认调度正常还是执行链路坏了”“修复授权后要做回归验证”等场景。
discord-thread-naming-backstop-workflow
用于执行 Discord 线程命名兜底(backstop)巡检与改名,专门处理某个 guild 下指定 parent channel 中“最近新建但未命名规范”的线程,补上 prehook 漏网,而不是批量回扫历史。遇到“线程重命名兜底”“dispatch 线程命名规范”“只检查最近 20 分钟线程”“JSON 污染标题”“长标题截断”“按规则静默改名或告警”“Discord thread-list / channel-edit / channel-info 重试与一致性检查”等场景时就应触发。即使用户没说 backstop,只要意图是低扰动修正新线程标题,也应使用此技能。