multi-source-diagnosis

multi-source-diagnosis is a skill for Claude Code, Codex from hophacker/skill-writing. It costs 175 tokens per session (3,356 once invoked), scanned A, original, MIT.

A structured analysis workflow for diagnosing unusual patterns in city-government service tickets. It compares hotline tickets, field inspections, staffing data, and selected weather or holiday information while keeping multiple possible explanations open.

In plain words
What is it for?
Use it to investigate rising delays, complaint spikes, repeated tickets, or other anomalies across the specified datasets. It produces fact summaries, competing hypotheses, and a checklist for further verification.
Why use it?
It makes cross-checking several public-service data tables more consistent and reduces the risk of treating one guess as proven. It also separates evidence and review tasks from decisions about priority or departmental action.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/hophacker/skill-writing/multi-source-diagnosis
Any agent
npx skills add hophacker/skill-writing --skill multi-source-diagnosis
Clone the repo
git clone --depth 1 https://github.com/hophacker/skill-writing

Made for: Claude Code, Codex.

Wrote 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.

agentmods badge for multi-source-diagnosis

README.md
[![agentmods](https://agentmods.dev/badge/skills/hophacker/skill-writing/multi-source-diagnosis.svg)](https://agentmods.dev/skills/hophacker/skill-writing/multi-source-diagnosis)
Your own site
<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>
Per session 175 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 3,356 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce 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

Measured 5d ago against content hash 4df6478932c4, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-05, from the pricing page.

Security

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.

Origin

Copies of this mod

1 near-identical copy found in the catalogue:

skills/multi-source-diagnosis/SKILL.md · 200 lines

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_热线工单表.csv
    • 02_网格巡查与现场核验表.csv
    • 03_资源排班与部门容量表.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_overdueprocessing_hours > 部门 SLA 判定,未受理工单不计入);
    • 取值范围(例:urgency_level ∈ {高,中,低});
    • 跨表对齐方式(例:01.responsible_department ↔ 03.responsible_department,按日期+区+部门连接)。
  • 遇到字段口径不明确:立即停下,输出 需人工口径确认:<字段>继续 Step 2。
  • 禁忌:严禁盲目调用未在本步声明的字段;严禁臆造字段含义。

Step 2 — 描述画像(descriptive profiling)

跨 01 / 02 / 03 三表汇总以下三类画像,每个画像写清「来源 + 字段 + 方法」:

  • 部门维度:工单总量、超时率、重复投诉占比、平均满意度、容量压力分布;
  • 时空维度:按日 / 街道 / 网格的工单密度、高紧急占比、现场核验风险等级;
  • 资源维度:各部门 department_capacity vs work_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 个假设 = 立刻补。

Read the full file on GitHub · 200 lines

Changes

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.

  1. 5d ago First seen · 200 lines · 175 tokens per session scan A 4df6478932c4

Subscribe to this mod's changes

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.

Related

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.

dong7812/collab-proof · 0 tokens

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.

comet-ml/opik · 43 tokens

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)…

comet-ml/opik · 112 tokens

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…

comet-ml/opik · 93 tokens

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…

comet-ml/opik · 0 tokens

opik-backend

Java backend patterns for Opik. Use when working in apps/opik-backend, designing APIs, database operations, or services.

comet-ml/opik · 31 tokens