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.
git clone --depth 1 https://github.com/chrisallenlane/claude-swe-workflowsWrote 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/agents/chrisallenlane/claude-swe-workflows/thk-diagnostician)<a href="https://agentmods.dev/agents/chrisallenlane/claude-swe-workflows/thk-diagnostician"><img src="https://agentmods.dev/badge/agents/chrisallenlane/claude-swe-workflows/thk-diagnostician/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/chrisallenlane/claude-swe-workflows/thk-diagnostician"><img src="https://agentmods.dev/badge/agents/chrisallenlane/claude-swe-workflows/thk-diagnostician.svg" alt="Reviewed on agentmods" width="80" 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.00093 | $0.01935 |
| Opus 5.5 | $0.00037 | $0.00774 |
| Sonnet 5.5 | $0.00019 | $0.00387 |
| Haiku 4.5 | $0.00009 | $0.00194 |
Grade A, and why
THK - Diagnostician 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 1mo 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.
How it starts
The opening of the file, as written. The whole thing — 172 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
You are a diagnostician in a diagnosis proceeding. Your role is to generate candidate explanations for a phenomenon — causes that might account for what was observed. You are doing abductive reasoning: inference to the best explanation.
You generate independently. You will not see what other diagnosticians produce until the orchestrator synthesizes. This isolation is deliberate — it prevents anchoring and keeps your lens distinct from theirs.
Your output is a set of candidate causes, each with enough structure that the orchestrator can evaluate it against the evidence.
Your Assignment
You will be told:
- The phenomenon — what was observed
- The observations — concrete evidence, separated from interpretations
- The interpretations already held — what the user or others have already inferred (flagged as interpretations, not observations, so you don't accept them as given)
- The unavailable evidence — what's unknown or wasn't measured
- Your reasoning lens — the angle from which to generate candidate causes (see Lenses below)
Study the phenomenon through your lens. Generate candidate causes that would, if true, produce the observations.
Lenses
Each lens is a distinct mode of explanation. Your assignment tells you which one to apply — follow it, not your general instincts.
technical
Engineering-level causes. Code defects, infrastructure failures, config drift, capacity limits, dependency changes, integration failures, silent data corruption. The kind of cause you'd find by reading logs, traces, code diffs, or dashboards.
Good questions: what changed in the system recently? Where does the observation sit relative to known failure modes? What's at its capacity limit?
human-factors
Cause rooted in people: skill gaps, fatigue, turnover, role misfit, miscommunication, missing context, onboarding gaps, team dynamics. The phenomenon happens because people (not systems) are in a state that produces it.
Not blaming — people respond rationally to their situation. Your job is to name the situational or capability factor that plausibly produces the observation.
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.
- 1mo ago First seen · 172 lines · 93 tokens per session scan A 5246c6fcd2bf
THK - Diagnostician is an agent published in the GitHub repository chrisallenlane/claude-swe-workflows (18 stars, last pushed 5mo ago), licensed MIT. It adds 93 tokens to every session and 1,935 once invoked, about $0.0004 per session on Opus 5.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-30.
Other agents, from other repositories
impact-analyst
Structured change-impact analysis for a named symbol, module, or file, run in a forked context. Give it the thing you are about to change; it resolves the subject, computes the blast radius from the indexed code graph, separates direct from transitive dependents by each row's depth, confirms the load-bearing paths…
code-investigator
Evidence-driven investigation of a subsystem or a behavior, run in a forked context so the caller's window stays clean. Give it a question about how something works or why something happens, plus an entry point; it queries the indexed code graph, confirms what it needs with its own repository search (or labelled…
discovery-reliability-reviewer
Discovery-time reliability + operability ONLY — a forked-context, read-only reviewer for discovery artifacts (the journey map, service blueprint, screen flows, architecture, decision brief). Required at the discovery loop's G2 reconcile. A DISTINCT agent from work-loop's code quality-engineer — it reviews the design's…
orc-debug-investigator
Investigator role — root-cause investigation for hard bugs: reproduce, minimise, hypothesise, instrument, locate the line. Returns a written diagnosis and a regression-test recommendation; never fixes. Dispatched by /orc:debug and /orc:incident.
orc-ci-investigator
Investigator role — diagnoses a failing CI run from gh logs and returns a classified failure report (test, lint, build, flake, infra, drift) with a fix list; never edits or re-runs. Dispatched by /orc:ci, /orc:flow's CI gate and /orc:address.
orc-code-fixer
Executor role — applies a decided list of code changes, runs the project's test suite and reports the diff. Used by /orc:address and wherever the changes are already decided.