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 yarlson/yarstack --skill bug-report-reproducegit clone --depth 1 https://github.com/yarlson/yarstackWrote 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/yarlson/yarstack/bug-report-reproduce)<a href="https://agentmods.dev/skills/yarlson/yarstack/bug-report-reproduce"><img src="https://agentmods.dev/badge/skills/yarlson/yarstack/bug-report-reproduce/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/yarlson/yarstack/bug-report-reproduce"><img src="https://agentmods.dev/badge/skills/yarlson/yarstack/bug-report-reproduce.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.00102 | $0.01776 |
| Opus 5.5 | $0.00041 | $0.00710 |
| Sonnet 5.5 | $0.00020 | $0.00355 |
| Haiku 4.5 | $0.00010 | $0.00178 |
Grade A, and why
bug-report-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 yesterday.
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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Bug Report Reproduction
Turn one reported problem into a reproduction, a proven cause, and visual evidence that a teammate can review. Leave the repository as it was unless the user asks for a fix.
Workflow
1. Read the report
Read the report and its attachments through the available connector. If you cannot read the report, ask the user to paste it. Record:
- the symptom in the reporter's words and in observable terms;
- exact messages, errors, outputs, and screenshots;
- the affected area, environment, input shape, and plan already agreed in the report.
Do not write to the report's source. Draft any reply for the user to send.
Record git status --short before you change anything. Cleanup in step 8 restores this state.
2. Trace the symptom to the code
Start from the most specific observable detail in the report and follow the code that produces it, across process and service boundaries, to the decision that causes it. Record each step with file:line.
State the working hypothesis and the strongest alternative. Keep the observed symptom separate from its cause; the place where a problem shows is often not where it starts.
3. Build synthetic input
Never copy customer data, files, or identifiers into the repository, tests, recordings, or reports. Create a synthetic input with the same structure, format, and size class as the reported one, and keep it in the scratch directory.
4. Choose the environment
Ask which environment to use only when the report and repository do not settle it. Respect organization policy and tool blocks: when tools or access are blocked for an environment, do not work around the block. Fall back to the closest local harness and record the gap as a limit.
5. Prove the behavior with a focused test
Before any recording, write one temporary test at the narrowest unit that owns the behavior. Control inputs, timing, and external replies at the system boundary. Assert the observed sequence of states, including repeated paths. A passing test that shows the reported sequence proves the symptom; the recording only shows it.
What ships with it
2 files 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.
- yesterday Changed · +6 lines 4463afdca66d
- 8d ago First seen · 80 lines · 102 tokens per session scan A d91ae5e49e78
bug-report-reproduce is a skill published in the GitHub repository yarlson/yarstack (3 stars, last pushed today), licensed MIT. It adds 102 tokens to every session and 1,776 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-10-10.
Other skills, from other repositories
ring:test-driven-development
Enforcing the RED-GREEN-REFACTOR loop: write one failing test and watch it fail, write minimal code to pass, then refactor green. Use when starting implementation of a new feature or bugfix, or writing any new production code. Requires pasted failure output as proof of RED; code written before its test must be…
ring:detecting-goroutine-leaks
Detecting goroutine leaks in Go: greps for goroutine patterns, audits goleak coverage (VerifyTestMain/VerifyNone), runs goleak, and dispatches ring:backend-go to fix leaks and add regression tests. Use after implementation or during review when code spawns goroutines or a leak is suspected. Runs before…
qa
Use to verify that code works correctly — browser-based testing with Playwright, native app testing with computer use, CLI testing, API testing, or root-cause debugging. Supports --quick, --standard, --thorough modes. Triggers on /qa.
pasteurize
Diagnose and fix a hard bug. Build a reliable reproduction, name the cause, add a regression test, and apply the minimum fix. Use when the user reports a bug, a failure, a flaky test, a performance regression, an error, or a wrong result whose cause is unknown. Use when the user pastes a symptom, a stack trace, or…
debug
Systematic bug investigation with a five-phase framework: reproduce, narrow, diagnose, fix, verify. Supports automated regression bisect via --regression flag. Produces a structured debug report with root cause analysis, regression test, and CQ/Q self-evaluations.
fixing-code
Fix code defects with a reproducible feedback loop, root-cause diagnosis, minimal patch, regression test, and clean verification. Use when debugging, diagnosing, or resolving lint/test/build failures. NOT for test-suite cleanup without a production bug (use improving-tests), or code review findings without fixes (use…