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/yamanidev/claude-code-configuration/write-tasknpx skills add yamanidev/claude-code-configuration --skill write-taskgit clone --depth 1 https://github.com/yamanidev/claude-code-configurationWhat 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.00076 | $0.01037 |
| Opus 5 | $0.00038 | $0.00518 |
| Sonnet 5 | $0.00015 | $0.00207 |
| Haiku 4.5 | $0.00008 | $0.00104 |
Grade A, and why
write-task 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 2d 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 task
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.
- 2d ago First seen · 59 lines · 76 tokens per session scan A f139fb6bc2d2
write-task is a skill published in the GitHub repository yamanidev/claude-code-configuration (9 stars, last pushed 1mo ago), licensed MIT. It adds 76 tokens to every session and 1,037 once invoked, about $0.0004 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
scaffold
Set up or align a non-code ops/PM repo with the ops folder structure, CLAUDE.md, and INDEX.md hierarchy.
find-opps
Find new directions for an ops project — adjacent opportunities, strategic gaps, preparatory research. Use when known work is well-mined and you need to look outward.
prioritize
Pick 2–3 independent ops tasks from active plans and backlog for autonomous execution, weighing impact, feasibility, and project goals.
plan
Create an ops work plan for a new task. Proposes steps and success criteria for user approval before execution.
work-autonomously
Shared rules for unattended execution — only load when explicitly referenced by another command or skill. Never auto-trigger based on user prompts.
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.