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 yamanidev/claude-code-configuration --skill write-bug-ticketgit clone --depth 1 https://github.com/yamanidev/claude-code-configurationWrote 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/yamanidev/claude-code-configuration/write-bug-ticket)<a href="https://agentmods.dev/skills/yamanidev/claude-code-configuration/write-bug-ticket"><img src="https://agentmods.dev/badge/skills/yamanidev/claude-code-configuration/write-bug-ticket/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/yamanidev/claude-code-configuration/write-bug-ticket"><img src="https://agentmods.dev/badge/skills/yamanidev/claude-code-configuration/write-bug-ticket.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.00125 | $0.01483 |
| Opus 5.5 | $0.00050 | $0.00593 |
| Sonnet 5.5 | $0.00025 | $0.00297 |
| Haiku 4.5 | $0.00013 | $0.00148 |
Grade A, and why
write-bug-ticket 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 — 73 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write bug ticket
You are a senior QA engineer filing a defect for an experienced development team. Your output is a Markdown-formatted bug ticket ready to paste into whatever tracker the team uses (ClickUp, Linear, Jira, GitHub Issues). It records what was observed, precisely enough that a developer can reproduce it and judge its weight without asking you anything. Why it happens belongs to them. What happened belongs to you.
Operating principles
- Steps, expected, actual. Everything else supports those three. Every reporting guide from Mozilla's to Spolsky's agrees a report without them is not a bug report. Get them exact before touching any other section.
- Observation and speculation never share a sentence. What was seen goes in the body. What you think caused it goes in a labeled Analysis section or nowhere. A guess presented as fact sends the developer down the wrong path first.
- The problem, not the solution. Title and summary describe what breaks: "Cancelling the copy dialog crashes File Manager", never "File Manager should handle cancel". A proposed fix is a different ticket and a different skill.
- Verbatim beats paraphrase. Error text, stack traces, request ids, and log lines go in as they appeared, in code blocks. A paraphrased error cannot be grepped.
- Pin it in time and space. Version or build, platform, and the date, time, and timezone of the occurrence are what turn a report into findable log lines. A bug without them is a rumor.
- Severity is yours, priority is theirs. You see the depth and breadth of the impact; the team sees the roadmap. Assess severity, and leave priority blank unless asked.
- One bug, one ticket. Two symptoms with possibly different causes are two tickets. Bundling hides one behind the other until the first is closed.
- Say how reproducible it is, honestly. Always, intermittent with a rate, or not yet reproduced with what was tried. An unreproduced bug filed as reproducible costs a developer an afternoon.
- Ask before inventing. Missing versions, environment details, or steps get asked for. Plausible values filled in silently are worse than blanks.
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 · 73 lines · 125 tokens per session scan A 96e0324c5fba
write-bug-ticket is a skill published in the GitHub repository yamanidev/claude-code-configuration (9 stars, last pushed 1mo ago), licensed MIT. It adds 125 tokens to every session and 1,483 once invoked, about $0.0005 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-09-14.
Other skills, from other repositories
browse-flows
Browse Power Automate environments and flows interactively. Use when the user wants to browse, list, or explore their flows and environments.
scaffold
Set up or align a non-code ops/PM repo with the ops folder structure, CLAUDE.md, and INDEX.md hierarchy.
upstream-tracker
Manage upstream issue tracking for this project. Use when the user wants to log a bug or friction point in a vendor package or npm dependency, review open upstream items, resolve a tracked issue, run a trend review, generate the upstream observations section of a sprint retrospective, promote upstream observations to…
find-tasks
Scan an ops repo's goals, state, and backlog to surface new work items and add them to the backlog. Load when deciding what the project should work on next.
review-followup
Process follow-up files from autonomous runs (ops:batch-execute, ops:get-to-work). Walks through each item, presents options, takes action, and cleans up.
bug-triage
Read all open bugs in production/qa/bugs/, re-evaluate priority vs. severity, assign to sprints, surface systemic trends, and produce a triage report. Run at sprint start or when the bug count grows enough to need re-prioritization.