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/jv-vogler/skills/write-descriptionnpx skills add jv-vogler/skills --skill write-descriptiongit clone --depth 1 https://github.com/jv-vogler/skillsWrote 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/jv-vogler/skills/write-description)<a href="https://agentmods.dev/skills/jv-vogler/skills/write-description"><img src="https://agentmods.dev/badge/skills/jv-vogler/skills/write-description.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.00065 | $0.01325 |
| Opus 5 | $0.00032 | $0.00662 |
| Sonnet 5 | $0.00013 | $0.00265 |
| Haiku 4.5 | $0.00006 | $0.00133 |
Grade A, and why
write-description 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 5d 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 — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing PR Descriptions
The one rule
A PR description carries only what the diff cannot show: the why, the shape of the change, and what to look at first. The reviewer reads the code for the how. Every sentence that restates the implementation is noise; cut it.
Write for a reviewer scanning in fifteen seconds. Short is the target, not a constraint. Size to the number of distinct ideas, not the file count: a 50-file rename is one idea and earns a tiny description.
Pre-flight (before writing a word)
Read the change: git diff <base>...HEAD and git log <base>..HEAD. Every path, name, and count in
the description must match what you just read. That is what keeps it from going stale.
The shape
Lead with a visual when the change has one, then the four sections. Most are one line.
Visual first (when it applies)
- The change is a mapping, rename, enumeration, or set of values -> show a table.
- The change is a flow, topology, lifecycle, or state machine of 3+ parts -> show a diagram
(
mermaid; an inlineA -> B -> Cfor a plain 3-box chain). - Neither -> skip this; no decorative diagram.
Draw the data once, here. The sections below must not re-narrate what the visual already shows.
1. TL;DR
One sentence: <what changed at the system level> so that <why it matters>. The why is required. The
PR title is the conventional-commit summary; the TL;DR is the sentence version, not a copy of it.
2. Goal
One line, first match wins: (a) link the tracker ticket; (b) else name the task and link its plan/spec doc; (c) else one plain sentence. If the TL;DR already carries the why and there is no ticket or doc, fold Goal into the TL;DR rather than pad an empty line.
3. What changed
Three to five bullets, one line each. Each bullet is a decision, capability, or consequence the reviewer cannot read off the diff, not the mechanism.
- A bullet that names types, fields, or call chains is restating the code. Rewrite it as the decision behind them.
- When a visual already carries the change, the bullets cover only what it cannot: the why, the migration, the blast radius.
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.
- 5d ago First seen · 115 lines · 65 tokens per session scan A 1776e73e25b1
write-description is a skill published in the GitHub repository jv-vogler/skills (1 stars, last pushed 11d ago), licensed MIT. It adds 65 tokens to every session and 1,325 once invoked, about $0.0003 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
meta-tags-optimizer
Optimize title tags, meta descriptions, Open Graph, and Twitter cards for maximum click-through rate. Generates multiple A/B test variations with character counting and SERP preview. Use when asked to "optimize title tag", "write meta description", "improve CTR", "Open Graph tags", "fix my meta tags", "social media…
google-ads-audit
Google Ads account audit and business context setup. Run this first — it gathers business information, analyzes account health, and saves context that all other ads skills reuse. Trigger on "audit my ads", "ads audit", "set up my ads", "onboard", "account overview", "how's my account", "ads health check", "what should…
sxo
Search Experience Optimization (SXO) — the bridge between SEO and UX/CRO. Audits the full journey from the SERP click to the on-page goal: SERP click-through factors (title/meta/rich results that win the click), then post-click experience signals that keep users and drive conversions — above-the-fold relevance and…
elixir-idioms
OTP/BEAM patterns and Elixir idioms — GenServer, Supervisor, Task, Registry, pattern matching, with chains, pipes. Use when designing processes or debugging BEAM issues.
tidewave-integration
Tidewave MCP runtime tools — debugging, smoke testing, live state inspection, SQL queries, hex docs. Use when evaluating code in a running Phoenix app.
security
Enforce Elixir/Phoenix security — auth, OAuth, sessions, CSRF, XSS, SQL injection, input validation, secrets. Use when editing auth files, login flows, RBAC, or API keys.