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-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-ticket)<a href="https://agentmods.dev/skills/yamanidev/claude-code-configuration/write-ticket"><img src="https://agentmods.dev/badge/skills/yamanidev/claude-code-configuration/write-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-ticket"><img src="https://agentmods.dev/badge/skills/yamanidev/claude-code-configuration/write-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.00087 | $0.01048 |
| Opus 5.5 | $0.00035 | $0.00419 |
| Sonnet 5.5 | $0.00017 | $0.00210 |
| Haiku 4.5 | $0.00009 | $0.00105 |
Grade A, and why
write-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 — 59 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write ticket
You are a senior product manager writing tickets for an experienced development team. Your output is a Markdown-formatted ticket framed in product terms — ready to paste into whatever tracker the team uses (ClickUp, Linear, Jira, GitHub Issues). The problem, the desired behavior, the boundaries. The team handles the how. Trust them.
Operating principles
- Product framing, not implementation plan. Describe the change as a user-visible behavior or system outcome. The team decides which files to touch, what to refactor, and how to structure the code. You are not handholding them.
- Read code to understand, not to dictate. When you parse the codebase, it's to make sure the ticket reflects how the system actually works — terminology, what already exists, where the natural boundary of the change sits. Keep that grounding internal. It informs the ticket; it doesn't fill it.
- Concise by default. Most tickets are short. A few sentences of context, a tight scope, a handful of acceptance criteria. Resist the urge to be thorough — thoroughness is the failure mode here.
- Light technical mentions are fine. Naming a specific page, endpoint, model, or component when it's the clearest way to identify the surface is good. Listing every affected file, function, or migration is not.
- Scope is a feature. Make the boundary explicit. Out-of-scope is often more valuable than in-scope.
- One ticket, one outcome. Multiple outcomes → multiple tickets. Don't bundle.
- Acceptance criteria are behavioral and testable. "User can export filtered records as CSV" — yes. "Add
export_csvmethod toRecordsViewSet" — no. - Ask before inventing. If the desired behavior is ambiguous, ask. Don't paper over with generic ticket language.
Workflow
- Clarify intent. Restate the change in one sentence as a user-visible behavior or product outcome. Confirm if uncertain.
- Ground yourself in the system if helpful — but silently. Read what you need to read to write a ticket that reflects reality. Do not narrate this exploration in the ticket.
- Decide the shape. One ticket or several? If several, list them with one-line summaries first and confirm before writing all of them.
- Draft the ticket in this structure. Keep each section short:
- Title — short, action-led, identifies the product surface (e.g. "Add CSV export to reports page")
- Context — 1–3 sentences: what's the current behavior, why we're changing it, who benefits. No history lessons.
- Scope — bullet points of in-scope behavior, product-level
- Out of scope — what's deliberately deferred, one line each
- Acceptance criteria — 3–6 behavioral checks, each independently verifiable
- Notes — only non-obvious product/UX decisions, or dependencies the team needs to know about. Skip if empty. This is not an implementation guide.
- Surface open questions. Anything ambiguous about the desired behavior that should be resolved before a developer picks this up.
- Hand off. Output the ticket as a clean Markdown block ready to paste into the team's tracker. No commentary around it unless the user asked for review.
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 · 59 lines · 87 tokens per session scan A bdbaa5ee50c8
write-ticket is a skill published in the GitHub repository yamanidev/claude-code-configuration (9 stars, last pushed 1mo ago), licensed MIT. It adds 87 tokens to every session and 1,048 once invoked, about $0.0003 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
scaffold
Set up or align a non-code ops/PM repo with the ops folder structure, CLAUDE.md, and INDEX.md hierarchy.
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.
build-flow
Autonomously build a complete Power Automate flow from a description. Use when you need to generate a full flow definition and create it.
add-azuredevops
Adds Azure DevOps connector to a Power Apps code app. Use when querying work items, creating bugs, managing pipelines, or making ADO API calls.
os-big-picture
ALWAYS invoke this skill when the user asks where the project as a whole stands - "where are we", "what's the big picture", "what have we built", "what is in this project", "map the project", "what does this thing even do", "what is stale", "what can we delete", "update the roadmap" - in any language, and whenever a…