القائمة
系统化根因调试:历史搜索→复现→scope lock→模式匹配→假设验证→修复→验证→报告 + 修完扫同类。铁律:无根因不修。Trigger:/omd-debug、debug、调查、排查、为什么挂了、这个bug、根因分析、investigate、stack trace、昨天还好的。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
列出断掉/失败的 DAG run(带 goal)让 owner 挑一个续跑——从磁盘 checkpoint 重载 plan、跳过已绿节点接着跑。Trigger:/omd-resume、续跑、接着跑、断了的图、resume、跑一半挂了、429 断了。Skip:全新任务(/omd-execute 或 dag_run)、查状态不续跑(dag_status)。
锁 plan/SDD 前的对抗式审问:沿决策树走、先给推荐答案、事实自查·技术 Decision 自裁·真 owner 岔口才阻塞问、对标外部实现逼问「为何偏离」;宽解岔口就地开 council;产决策记录表喂 /omd-sdd。审议纪律:只讨论不动手。Trigger:/omd-grill、审问、盘问这个方案、把这事讨论清楚、压测计划、stress-test。
打开/新建/列出 omd pathfinder 决策地图(经 omd MCP server)。大而模糊的多 session 工作先开图:把待决问题变成票,渐进散雾。Trigger:/omd-path、pathfinder、开图、决策地图、这活儿太大先规划。
把已定的 SDD/规划交给 omd DAG 引擎执行(经 MCP dag_run 三段式),完成后按交叉验证 checklist 逐条判、四选一验收。Trigger:/omd-execute、开始执行、按 SDD 干、执行计划。
视频→逐段结构化笔记 (MiMo-v2.5 原生吃画面+音频, 非 whisper 转写; 可重入管线)。讲解/课程视频里 PPT 框架图/代码/提示词是画面独有、音频拿不到的信息。产 ALL-NOTES.md 交 /omd-council 或 dag_research 做综合。Trigger:/omd-video、抖音/B站/YouTube 讲解视频、课程系列、把这些视频学一遍/提炼、画面里有代码/图表/PPT。Skip:文字原文综合→/omd-council;网页内容→dag_research(检索版)。
One table of every routed oh-my-dag skill: name → when to use. The one name to remember. Trigger: /omd / list skills / which skill / 有哪些技能 / 该用哪个技能.
| name | omd-debug |
| description | 系统化根因调试:历史搜索→复现→scope lock→模式匹配→假设验证→修复→验证→报告 + 修完扫同类。铁律:无根因不修。Trigger:/omd-debug、debug、调查、排查、为什么挂了、这个bug、根因分析、investigate、stack trace、昨天还好的。 |
铁律:无根因不修。 修症状 = 打地鼠。找到根因再动手,诊断阶段禁提修复方案。
方法论 skill:单线程串行用 runtime 原生 Grep/Read/git 走完 8 阶段;假设验证需并发多路时派 omd dag_debug(一假设一 leaf + skeptic 跨模型证伪 + codegraph 锁范围 + 三振纪律,见 Phase 5)。
同一消息并行发:git log --oneline -20 -- <相关文件>(近期变更)+ Grep 既有 docs/plan/·NOTES·error 记录搜错误关键词(有先例走 /omd-recall 先召回)。命中已知修复 → 直接引用,跳到修复。
确定性触发 + 存证据(错误信息/堆栈/复现步骤)。信息不足 → 逐个追问(一次一问)。不能稳定复现 → 收集更多证据再继续,别猜。
从症状追到最窄受影响目录,声明范围;此后 Edit 只在范围内,越界先问 owner。危险信号立即停:「顺手修个相关的」(不顺手,记 follow-up)、「既然在改不如重构」(不重构,本 bug 修完再评估)。
先 step-back 自问:这类症状(数据不一致/超时/类型错/竞态/权限泄漏/schema 漂移)在本技术栈通常由哪层引起?建宏观诊断框架再缩范围,别直接跳到最"像"的模式。同文件反复修 bug = 架构问题,不是巧合。
每假设三步推导:观察(引 file:line 我看到什么)→ 推论(若成立还应看到什么)→ 验证(设计能区分成立/不成立的实验)。追踪表标 CONFIRMED/REJECTED。先验证再修(可疑根因处加临时 log/断言,跑复现看证据是否吻合)。三振出局:3 个假设全败 → STOP 问 owner(A 继续有新假设 / B 升级人工 / C 埋点观察)。危险信号:还没追数据流就提修复 = 在猜。
并发扇出 → 派
dag_debug:假设多、想并行验(一假设一 leaf + skeptic 证伪 + judge 收敛)而非单线程串行时,派 omddag_debug(failure 必填,repro/oracleCmd可选)。它把本阶段的假设验证 DAG 化,同守本 skill 铁律(无根因不修 / 默认只提议不改文件 / 三振停升 owner)。复现拿 red + codegraph 锁范围由引擎代跑;finding≠ground truth,回来仍你终裁。
根因确认后最小改动:最少文件、最少行,不顺手重构相邻代码。写回归测试(不修 FAIL、修后 PASS),跑测试套件贴输出。改 >5 文件 → 问 owner(bugfix 爆炸半径偏大:继续 / 拆分 / 重想)。
复现原始场景确认已修 + 跑变更相关验证。不说"应该能修好",验证并证明。
报告:症状 / 根因(为什么)/ 模式 / 修复(file:line)/ 证据 / 回归测试 / 状态(DONE · DONE_WITH_CONCERNS · BLOCKED)。修完扫一片:用根因反推同类——Grep 同 pattern(根因是"缺 scope 过滤" → 全仓找所有 db 访问点;"未校验入参" → 找所有 untrusted 入口)。>5 处别一次全修,修 1-2 关键,其余记 NOTES 留 follow-up。
