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/ReviewToolkits/cpython-review-toolkitWrote 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/commands/reviewtoolkits/cpython-review-toolkit/reproduce)<a href="https://agentmods.dev/commands/reviewtoolkits/cpython-review-toolkit/reproduce"><img src="https://agentmods.dev/badge/commands/reviewtoolkits/cpython-review-toolkit/reproduce.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.1 | $0.00016 | $0.00801 |
| Opus 5 | $0.00008 | $0.00400 |
| Sonnet 5 | $0.00003 | $0.00160 |
| Haiku 4.5 | $0.00002 | $0.00080 |
Grade A, and why
reproduce 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 7d 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 — 77 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Reproduce a Crash (dense OOM injection)
Take a static candidate — from uninitialized-dealloc-auditor, pyerr-clear-auditor, null-safety-scanner, error-path-analyzer, or a known-issues present verdict — and try to turn it into a reproduced crash with evidence on a locally-built CPython.
Arguments: "$ARGUMENTS"
Phase 0: Find a usable interpreter
The harness needs a CPython build providing _testcapi.set_nomemory. Check, in order:
- An explicit
--python <path>argument. - A source checkout's
./python(e.g.~/projects/cpython/python). - A build matrix (e.g.
~/projects/python_build_matrix/builds/*/python) — prefer a debug or ASan build; they turn silent corruption into loud assertions.
Verify: <python> -c "import _testcapi; print(hasattr(_testcapi,'set_nomemory'))".
If none is available, report that and stop — do not fabricate a result.
Phase 1: Choose the target
If the argument names a finding (file:line, function, or a scanner finding id), read that code and write the smallest stdlib-only snippet that reaches it. If the argument is already a snippet or a script path, use it directly.
State explicitly which line you are trying to reach — Phase 4 depends on it.
Phase 2: Sweep
Dispatch the oom-reproducer agent, or run directly:
python <plugin_root>/scripts/run_oom_sweep.py --python <build> --code '<snippet>' --max-n 300
Dense by default. Use --stop-after 1 for existence proof, --start-n to skip startup allocations, --script for a longer payload.
Phase 3: Confirm and minimize
On a crash: re-run to confirm determinism, then shrink the payload to the minimum that still crashes, and capture the faulthandler traceback and the crash index.
Phase 4: Report honestly
# Reproduction Report
## Target
[static finding + file:line + which agent surfaced it]
## Interpreter
[path, build flavor, version]
## Sweep
- Range: 0..N (dense) | Outcomes: {...}
- **Verdict**: REPRODUCED at index K / not reproduced in this range
## Evidence
[exit code + faulthandler traceback]
## Assessment
[Did the payload reach the flagged line? What is proven / not proven?]
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.
- 7d ago First seen · 77 lines · 16 tokens per session scan A 3a04166178b3
reproduce is a command published in the GitHub repository ReviewToolkits/cpython-review-toolkit (10 stars, last pushed 1mo ago), licensed MIT. It adds 16 tokens to every session and 801 once invoked, about $0.0001 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 commands, from other repositories
bugfix
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD.
verify-bug
Post-merge UAT verification workflow. Walks JIRA reproduce steps, performs comparative audits (Before/After), attaches evidence to JIRA, and transitions status on PASS.
timeout-fix
A procedure for diagnosing and fixing tests that exceed their time limit by finding causes such as slow processing, hanging network calls, deadlocks, heavy setup, or leaked resources.
ui-aqa-flow-test-report-analysis
Phase 7 Test Report Analysis of ui-aqa-flow.
api-aqa-flow-execution-and-report-analysis
Phase 6 Execution & Report Analysis of api-aqa-flow (USER INTERACTION REQUIRED).
qa-changes
This skill should be used when the user asks to "QA a pull request", "test PR changes", "verify a PR works", "functionally test changes", or when an automated workflow triggers QA validation of code changes. Provides a structured methodology for setting up the environment, exercising changed behavior, and reporting…