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/whenpoem/aiscientist/debug-sopnpx skills add whenpoem/aiscientist --skill debug-sopgit clone --depth 1 https://github.com/whenpoem/aiscientistWrote 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/whenpoem/aiscientist/debug-sop)<a href="https://agentmods.dev/skills/whenpoem/aiscientist/debug-sop"><img src="https://agentmods.dev/badge/skills/whenpoem/aiscientist/debug-sop.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 | $0.00068 | $0.00946 |
| Opus 5 | $0.00034 | $0.00473 |
| Sonnet 5 | $0.00014 | $0.00189 |
| Haiku 4.5 | $0.00007 | $0.00095 |
Grade A, and why
debug-sop 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 4d 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Debug SOP
Inputs and output
Capture the exact symptom, expected behavior, reproduction command, relevant inputs, environment, first known bad state, and whether fixing is authorized. Return a compact incident report with reproduction, root cause or surviving hypotheses, evidence, changed files if any, verification commands, and the failure-ledger id.
1. Recover history before guessing
- Call
mcp__memory__match_signatureswith the exact error plus the operation that triggered it. Read matching resolutions, but verify they still apply. - Inspect recent relevant changes, logs, configuration, and run manifests.
- Distinguish the visible symptom from a proposed cause. Do not edit merely because a familiar exception suggests an easy fix.
2. Reproduce and bound the failure
- Run the smallest safe command that should reproduce the symptom.
- Record whether it is deterministic, intermittent, machine-specific, data-specific, or dependent on ordering/timing.
- If reproduction would be destructive, costly, or use reserved data, stop and request the needed authority or choose a non-mutating probe.
- If the failure cannot be reproduced, compare environment, command, inputs, Git state, and dependency locks before declaring it gone.
3. Build and eliminate hypotheses
List plausible causes and, for each, the cheapest observation that would distinguish it. Prefer direct evidence in this order:
- exact traceback, exit code, or incorrect output;
- minimal reproduction;
- focused logging or state inspection;
- controlled input/config variation;
- history or non-destructive bisection.
Change one explanatory variable at a time. Do not use destructive Git reset or discard unrelated user work during bisection.
4. Isolate the root cause
Reduce the case until removing one condition removes the failure. For data or statistical failures, also check leakage, seed sensitivity, stale code/config, and baseline-budget mismatch. For integration failures, verify each boundary separately: executable discovery, configuration loading, process startup, protocol exchange, shared workspace/state path, then UI behavior.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 4d ago First seen · 108 lines · 68 tokens per session scan A 31945a1727cd
debug-sop is a skill published in the GitHub repository whenpoem/aiscientist (8 stars, last pushed 1mo ago), licensed MIT. It adds 68 tokens to every session and 946 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-31.
Other skills, from other repositories
generate-inputs
Interactively generate all required EUREKA problem input files (INSTRUCTION.md, SUBMISSIONFORMAT.md, evaluate.py) and the launch script (run.sh) from a researcher's natural language description, then validate the evaluation pipeline.
implement-approach
Run a grader-driven experiment from an assigned initial hypothesis. Reads the hypothesis brief, writes code, submits candidates through the grading service, and iterates on official scores within one approach directory.
prepare-workspace
Validate problem setup, test the evaluation pipeline, and configure the environment before the propose-implement loop begins.
propose-approaches
Propose initial hypotheses for an optimization problem. Reads problem and submission format from workspace inputs, generates diverse starting strategies, and writes a manifest for parallel grader-driven experiments.
connect-required-verification-information
Use this skill when the user asks what information a Stripe Connect connected account must provide for verification, onboarding, KYC, or account requirements; when they need to compare requirements between connected-account setups; or when they ask which verification fields, documents, or business details are required…
connect-recommend
Use this skill when the user asks about Stripe Connect configuration, charge patterns, Dashboard access, or how to get started with Connect, is building a marketplace, platform, multi-vendor store, gig platform, or subscription platform, needs to pay out sellers, vendors, or providers, mentions split payments, revenue…