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/tomzx/agents/create-readmenpx skills add tomzx/agents --skill create-readmegit clone --depth 1 https://github.com/tomzx/agentsWhat 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.00027 | $0.01173 |
| Opus 5 | $0.00014 | $0.00587 |
| Sonnet 5 | $0.00005 | $0.00235 |
| Haiku 4.5 | $0.00003 | $0.00117 |
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 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 — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write README
Produces a README.md for a project using a fixed template with centered header, badges, feature list, roadmap, and setup instructions. Derives content from the codebase, existing configuration files, and any available context.
Prerequisites
- A project directory with source code, a license file, and a package manifest (e.g.,
go.mod,package.json,Cargo.toml,pyproject.toml) - If
$1is provided, use it as the project directory; otherwise use the current working directory
Steps
- Scan the project for metadata: repository name from git remote or directory name, license type, language/runtime version from the package manifest, storage or database dependencies, and platform targets.
- Determine a one-sentence description of the project from existing docs, the package manifest description, or by reading the main entry point.
- List features by scanning source directories, CLI commands, exported functions, and any existing documentation.
- Identify roadmap items from open GitHub issues, TODO comments, or stated goals in docs.
- Identify out-of-scope items by reading issue discussions, design docs, or the package manifest's stated purpose.
- Determine install steps from the package manifest, Makefile, or build scripts.
- Write the README following the output template exactly.
- Write the file to
README.mdin the project root. - Add an HTML comment
<!-- session_link: http://localhost:10000/?session=<id> -->as the first line of the file, using the current session ID from context. If no session ID is available, omit the comment.
Output Format
<h1 align="center">{repository}</h1>
<p align="center">
<strong>{one sentence description of the project}</strong>
</p>
<p align="center">
<a href="./LICENSE"><img src="https://img.shields.io/github/license/tomzxcode/{repository}" alt="License"></a>
<img src="https://img.shields.io/badge/{language}-{version}%2B-{color}" alt="{Language} {version}+">
<img src="https://img.shields.io/badge/platform-{platforms}-lightgrey" alt="Platform">
</p>
<p align="center">
<img src="screenshot.png" alt="{repository} Demo"/>
</p>
## What
{2-4 sentences explaining what the project is and what it does.}
## Why
{2-4 sentences explaining the motivation behind the project, the problem it solves, and why it exists.}
## Included
{bullet point list of features, one per line, using - prefix}
## Roadmap
{bullet point list of planned features, one per line, using - prefix}
## Out of Scope
{bullet point list of features explicitly not planned, one per line, using - prefix}
## Requirements
{List of system requirements needed to build and run the project. Include language version, OS, and any external dependencies.}
## Install
{Step-by-step installation instructions with code blocks for commands.}
## Getting Started
{Step-by-step guide to using the project after installation. Include code examples where applicable.}
## License
The code is licensed under the [MIT license](http://choosealicense.com/licenses/mit/). See [LICENSE](LICENSE).
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 · 130 lines · 27 tokens per session scan A ec11dd57c72e
create-readme is a skill published in the GitHub repository tomzx/agents (5 stars, last pushed 5d ago), licensed MIT. It adds 27 tokens to every session and 1,173 once invoked, about $0.0001 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…