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 atman-33/workhub --skill create-readmegit clone --depth 1 https://github.com/atman-33/workhubWrote 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/atman-33/workhub/create-readme)<a href="https://agentmods.dev/skills/atman-33/workhub/create-readme"><img src="https://agentmods.dev/badge/skills/atman-33/workhub/create-readme.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.00034 | $0.01707 |
| Opus 5 | $0.00017 | $0.00853 |
| Sonnet 5 | $0.00007 | $0.00341 |
| Haiku 4.5 | $0.00003 | $0.00171 |
Grade A, and why
create-readme 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 3d 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 — 92 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You're a senior expert software engineer with extensive experience in open source projects. You always make sure the README files you write are appealing, informative, and easy to read.
Task
Take a deep breath, review the entire project and workspace, then create a comprehensive and well-structured README.md at the project root.
1. Investigate the project first
Before writing anything, gather the facts the README must reflect:
-
Audience & README type — decide who reads this README and what it must primarily enable, then order the document around that intent:
- Consumption-focused — users install/run/use the thing as-is (CLI tool, app, plugin/marketplace, service, template). Lead with how to add/install and use it. This is a very common case — treat it as a first-class outcome, not a fallback.
- Library/integration-focused — developers import it into their own code. Lead with install plus API/usage examples.
- Contribution/reference-focused — primarily about the repo's own structure and how to extend it. Give repository layout and extension steps prominence.
Most projects are a blend; pick the dominant intent and order sections around it.
-
Identity & purpose — read existing
README.md(refine, don't blindly overwrite),package.json/pyproject.toml/Cargo.toml/go.mod, and top-level docs to learn the name, one-line purpose, and description. -
How it runs — detect install/build/dev/test commands, entry points, and runtime/version requirements.
-
Features & usage — infer the main capabilities and the primary usage flow (CLI flags, API, config options, env vars) from source and config.
-
Assets — look for an existing logo or icon (e.g.
logo.*,icon.*, files underassets/,docs/,.github/). If one exists, use it in the header. -
Repository — use
git remote -vto resolve the repo URL for badges and links.
Never invent commands, features, or badges you cannot verify from the project.
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.
- 3d ago First seen · 92 lines · 34 tokens per session scan A 8abc62bc31f0
create-readme is a skill published in the GitHub repository atman-33/workhub (2 stars, last pushed 2d ago), licensed MIT. It adds 34 tokens to every session and 1,707 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
gonavi-cli
Operate databases through the GoNavi headless CLI — the gonavi executable shipped in verified GitHub Release archives. Covers listing/adding/importing saved connections, running SQL queries against saved connections or ad-hoc connection files, exporting result sets to csv/json/md/html/xlsx, batch-executing SQL files…
xiaohongshu-image-creator
An image-making assistant for Xiaohongshu, a Chinese social platform for lifestyle, product, and educational posts. It creates vertical covers and supporting images matched to the post’s topic, audience, and visual style.
codex
Run the Codex CLI directly in the user's checkout for code analysis, refactoring, or automated editing without Claude Architect's verified delegation lifecycle.
design
Create a doc-as-code design package from a PRD or SPEC. Conditionally generates C4 diagrams (Context/Container/Component), sequence diagrams, ER diagram + Data Dictionary, OpenAPI 3.0, AsyncAPI 3.0, ADRs, domain glossary, state diagrams, and deployment view as Mermaid-rendered Markdown files. Use when PM mentions…
shipyard-handoff
Captures session context into .shipyard/HANDOFF.md so the next session can resume without losing progress.
trellis-spec-bootstrap
Bootstrap project-specific Trellis coding specs with a platform-neutral single-agent workflow. Use when creating or refreshing .trellis/spec guidelines, analyzing a codebase with GitNexus, ABCoder, or source inspection, decomposing package/layer spec work, and writing real codebase-backed spec docs without placeholder…