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 skills add datit309/supergraph --skill diagnosegit clone --depth 1 https://github.com/datit309/supergraphWrote 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/datit309/supergraph/diagnose)<a href="https://agentmods.dev/skills/datit309/supergraph/diagnose"><img src="https://agentmods.dev/badge/skills/datit309/supergraph/diagnose/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/skills/datit309/supergraph/diagnose"><img src="https://agentmods.dev/badge/skills/datit309/supergraph/diagnose.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00059 | $0.00995 |
| Opus 5.5 | $0.00024 | $0.00398 |
| Sonnet 5.5 | $0.00012 | $0.00199 |
| Haiku 4.5 | $0.00006 | $0.00100 |
Grade A, and why
diagnose 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 — 126 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/supergraph:diagnose
Systematic debugging. Never guess and patch — build a feedback loop, prove the hypothesis, fix once.
Announce: "🐛 /supergraph:diagnose — building feedback loop..."
Setup
Read .supergraph-env for test/lint commands (if exists):
[ -f .supergraph-env ] && source .supergraph-env
This sets $TEST_CMD, $FOCUSED_TEST_CMD, $LINT_CMD. If absent, detect from project config (package.json → jest/vitest, pubspec.yaml → flutter test, etc.) same as /supergraph:scan.
Phases
Phase 1 — Build Feedback Loop
Before touching any code, establish a fast, deterministic way to observe the bug.
# Identify the smallest command that shows the failure
$TEST_CMD --grep "<failing test name>" # focused test run
# or
<minimal repro command>
Goal: failure visible in < 5 seconds. If not, slim down the repro. Do NOT skip this phase. Debugging without a feedback loop is guessing.
Phase 2 — Reproduce Cleanly
- Run the feedback loop 3 times — confirm it fails consistently
- Capture exact error output, stack trace, exit code
- Note any flakiness → treat as separate bug before continuing
- Add a failing regression test if one doesn't exist:
test("<bug description>", () => { ... }) // RED
Phase 3 — Hypothesize (3-5 ranked theories)
List falsifiable hypotheses, ordered most-to-least likely:
1. [Most likely] — [reason] — [how to falsify]
2. [Second] — [reason] — [how to falsify]
3. [Third] — [reason] — [how to falsify]
Rules:
- Each hypothesis must be falsifiable (observable test to disprove it)
- No implementation yet — only theories
- Use graph context if available:
search_graph(project=CBM_PROJECT, name_pattern=<suspect>) trace_path(project=CBM_PROJECT, direction="inbound") trace_path(project=CBM_PROJECT, direction="outbound")
Phase 4 — Instrument (one variable at a time)
Test hypothesis #1 first. Change ONE thing to observe ONE signal:
- Add targeted log/assertion near the suspect code
- Run feedback loop → confirm or refute
- Remove instrumentation after each test — never accumulate debug logs
- If refuted → move to hypothesis #2
- Stop when hypothesis is confirmed
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 · 126 lines · 59 tokens per session scan A 9955c4191ef0
diagnose is a skill published in the GitHub repository datit309/supergraph (21 stars, last pushed yesterday), licensed MIT. It adds 59 tokens to every session and 995 once invoked, about $0.0002 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 skills, from other repositories
diagnose-project
Diagnose .NET SDK, restore, build, test, package, target framework, F# compile-order, C# analyzer, and project-reference failures with concrete next checks.
bug-fix
Use when a bug, regression, or unexpected behaviour is reported and the user wants it fixed end to end — "why is X broken", "this stopped working after Y", "fix this crash". Also use when a symptom is known but its cause is not. Not for building new behaviour, and not for a change whose cause is already proven.
bug-investigate
Use when someone wants to know WHY something is broken and has not asked for it to be fixed — "why is this happening", "what's causing this error", "find out what's wrong", "diagnose this before we decide". Also use before committing to a fix, when the cause is unknown and the decision depends on it. Not for fixing …
xcode-build-run-workflow
Guide build, run, preview-adjacent, workspace-inspection, diagnostics, toolchain, and guarded mutation work in existing Xcode-managed projects and workspaces. Use when Xcode-aware execution is needed and the task is primarily about build, run, or project-integrity work rather than testing.
safari-mcp-workflow
Inspect a scoped live site in Safari through Safari Technology Preview's local MCP server. Use for Safari-specific DOM, console, network, screenshot, accessibility, performance, interaction, responsive, or print-media evidence.
xcode-debugger-mcp-workflow
Diagnose a running Apple app through Xcode’s active LLDB debugging session and assess the experimental Xcode 27 lldb-mcp executable. Use when setting breakpoints, inspecting frames or variables, issuing LLDB commands, or distinguishing a usable Xcode debugger session from an unavailable standalone debugger MCP server.