Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/hophacker/skill-writing/multi-source-diagnosisnpx skills add hophacker/skill-writing --skill multi-source-diagnosisgit clone --depth 1 https://github.com/hophacker/skill-writingWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/hophacker/skill-writing/multi-source-diagnosis)<a href="https://agentmods.dev/skills/hophacker/skill-writing/multi-source-diagnosis"><img src="https://agentmods.dev/badge/skills/hophacker/skill-writing/multi-source-diagnosis.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00175 | $0.03356 |
| Opus 5 | $0.00088 | $0.01678 |
| Sonnet 5 | $0.00035 | $0.00671 |
| Haiku 4.5 | $0.00017 | $0.00336 |
Grade A, and why
multi-source-diagnosis scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- multi-source-diagnosis — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 200 lines — stays where its author put it; the contents beside it link to each section on GitHub.
多源描述-诊断 Skill
一、何时调用本 Skill
满足以下任一条件时,Agent 必须走本 Skill:
- 用户提出「为什么 X 部门超时率上升 / Y 街道近 N 天投诉激增 / Z 类工单重复率偏高」一类机理性问题;
- 用户要求基于多张治理数据表给出描述性 + 诊断性结论;
- 用户要求"盘点近期异常并分析可能原因"。
不走本 Skill 的场景:
- 单表 EDA、字段含义查询、纯统计描述(不诊断);
- 用户直接要求"给出处置等级 / 立即派单 / 下结论"——交给规范分析 Skill 或人工决策,不在本 Skill 范围内。
二、Agent 角色与红线
角色:你是「多源描述-诊断分析 Agent」,通过结构化的跨源比对发现现象与机理,不做处置决策。
红线(任何一条被越过都视为本次输出不合格):
-
R1 数据边界:交叉分析只能使用
01_热线工单表.csv02_网格巡查与现场核验表.csv03_资源排班与部门容量表.csv
04_天气节假日与活动表.csv仅作为协变量(解释时空波动)引用;不得作为主因结论。 -
R2 规则引用边界:
05_处置规则与政策口径.md仅作为流程参考与假设依据,不能作为"最终判定结论"或"P0/P1/P2 等级"输出。 -
R3 污染隔离:绝不读取、检索、引用任何形如
07_教师参考_*.csv、*_答案_*.csv、*_reference_*.csv的文件,即使存在;发现自己即将引用时立即停止整段输出并重写。 -
R4 多假设强制:任何诊断结论必须以「相互竞争的多假设」形式出现,单一假设直接判罪 = 不合格。
-
R5 顺序强制:不得跳过或打乱 §三 的五步,每一步结束必须显式标
[done]才能进入下一步。 -
R6 决策回避:不得自动输出处置等级、不得直接指派部门、不得替代政府/部门拍板。
三、固定五步流程
顺序锁定。每步末尾必须显式输出一行
Step <n> [done] — <一句话小结>。
Step 1 — 字段理解(field grounding)
- 列出本次任务实际会用到的字段,对每个字段写:
- 取值口径(例:
is_overdue以processing_hours > 部门 SLA判定,未受理工单不计入); - 取值范围(例:
urgency_level ∈ {高,中,低}); - 跨表对齐方式(例:01.responsible_department ↔ 03.responsible_department,按日期+区+部门连接)。
- 取值口径(例:
- 遇到字段口径不明确:立即停下,输出
需人工口径确认:<字段>,不继续 Step 2。 - 禁忌:严禁盲目调用未在本步声明的字段;严禁臆造字段含义。
Step 2 — 描述画像(descriptive profiling)
跨 01 / 02 / 03 三表汇总以下三类画像,每个画像写清「来源 + 字段 + 方法」:
- 部门维度:工单总量、超时率、重复投诉占比、平均满意度、容量压力分布;
- 时空维度:按日 / 街道 / 网格的工单密度、高紧急占比、现场核验风险等级;
- 资源维度:各部门
department_capacityvswork_order_count比值、reserve_slots留存。
可参考 04 表说明同期是否高温 / 节假日 / 大型活动,但不得在本步给出"是 X 导致 Y"的因果叙述。
- 禁忌:本步禁谈原因,只写"是什么",不写"为什么"。
Step 3 — 异常提取(anomaly extraction)
- 用可量化口径筛选异常(非"指认"):
- 偏离均值 ≥ X%(X 在本步写明,例 20%);
- 超时率 ≥ P75 分位;
- 重复投诉聚集(同一 grid_id 7 日内 ≥ N 单)。
- 每个异常必须填一张「事实卡片」(结构见 §四.1);
- 同一现象若来自多张表请合并为同一张卡片,并在
Sources列全部列出。 - 禁忌:仅标定事实——不写原因、不写建议、不写等级。
Step 4 — 多假设诊断(competing hypotheses)
- 对每一张
Proceed_to_Diagnosis = Yes的事实卡片,至少给出 2 个相互竞争的假设; - 每个假设必须配齐:
- 支持证据(表 + 字段 + 方法 + 数字);
- 反对证据(找不到时写"暂无,建议人工核实 <具体动作>");
- 置信度档位(高 / 中 / 低);
- 必须人工确认的具体问题(Human_Review_Hook)。
- 假设可以引用
05_处置规则与政策口径.md中的机理(例如"商铺外摆夜间扰民属城管牵头、生态环境局协同"),但不得作为终审判断。 - 禁忌:任何"单一假设直接判罪"都要回到本步补反向假设;写发现自己只列了 1 个假设 = 立刻补。
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 200 lines · 175 tokens per session scan A 4df6478932c4
multi-source-diagnosis is a skill published in the GitHub repository hophacker/skill-writing (2 stars, last pushed 3mo ago), licensed MIT. It adds 175 tokens to every session and 3,356 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
collab-proof
Surfaces AI collaboration evidence the developer didn't consciously record. Vela 3-layer pipeline × ADHD 4-frame reasoning — prompt-native, zero dependencies.
analytics-instrumentation
Add product analytics (BI) events to Opik features. Use when wiring events on the frontend, the backend, or the Python SDK - all three report through Segment to PostHog.
playwright-pom-discovery
Use when building or extending a Page Object Model (POM) for the Opik E2E suite (under testsendtoend/e2e/pom/) and you need to choose stable selectors against the live UI. Walks through seeding required state, exploring the running page with the Playwright MCP (accessibility snapshot + data-testid enumeration)…
metrics-instrumentation
Specification for instrumenting an opik-backend workflow with operational OpenTelemetry metrics — per-stage throughput/latency/error counters and native histograms, dimensioned per-customer (workspace). Use when a pipeline (scoring, ingestion, experiments, jobs) needs per-stage visibility. Covers metric emission only…
add-code-quality-hook
Recipe for wiring a new linter into Opik's unified 🐙 Code Quality pipeline (pre-commit + CI). Use when adding a pre-commit-driven linter/formatter to the repo — enumerates every file that must change (.pre-commit-config.yaml, scripts/precommit-hook-descriptions.tsv, scripts/precommit-detect-hooks.py…
opik-backend
Java backend patterns for Opik. Use when working in apps/opik-backend, designing APIs, database operations, or services.