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/datit309/supergraph/diagnosenpx skills add datit309/supergraph --skill diagnosegit clone --depth 1 https://github.com/datit309/supergraphWhat 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 | $0.00059 | $0.00995 |
| Opus 5 | $0.00030 | $0.00498 |
| Sonnet 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 2d 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.
- 2d 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 5d ago), licensed MIT. It adds 59 tokens to every session and 995 once invoked, about $0.0003 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-30.
Other skills, from other repositories
playwright-cli
Automates browser interactions for testing and validating your own web applications using playwright-cli. Use when you need terminal-first browser control for navigation, form filling, screenshots, tracing, bound browser sessions, debugging, or generating Playwright test code. Only use against applications you own or…
migrate
Inventory an existing spec-driven project and apply bounded migrations to jig defaults: report, adopt-layout, rename-decisions, split-slices, slice-to-spec, seed-decisions, and copy-machinery. Use when the user says migrate this project to jig, adopt jig here, this repo already has specs — set up jig, scaffold-init…
adr-workflow
Scaffold, accept, index, and link Architectural Decision Records (ADRs). Use when the user says "write an ADR", "record this decision", "resolve [deferred item] with an ADR", "supersede ADR-NNNN", or otherwise wants to capture a hard-to-reverse decision in docs/decisions/. Also use when a refinement-todo entry needs…
bug-fix
Drive the teeth-gated lifecycle for reported defects: diagnose root cause, prove it, and prevent regression through REPORTED → DIAGNOSING → ROOTCAUSED → FIXING → REVIEWED → DONE, with VERIFIED, ESCALATED, and RESOLVEDONMAIN paths where needed. Auto-fires on fix this bug, debug this, root-cause this, this regressed…
vision-elicitation
Lightweight baseline elicitation pass that fills in docs/product-vision.md and the five docs/architecture.md elicitation slots after scaffold-init. Auto-triggers when you say set up project vision, elicit architecture, define what we're building, run the vision wizard, refresh the project pitch, or capture product…
analyze
Cross-artifact consistency report for jig specs — a non-destructive six-category audit at CRITICAL/HIGH/MEDIUM/LOW severity, covering duplication, ambiguity, underspecification, principle violations, coverage gaps, and terminology drift. Auto-triggers when you say analyze this spec, check for inconsistencies, audit…