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 niels-emmer/myace --skill readme-structuregit clone --depth 1 https://github.com/niels-emmer/myaceWrote 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/niels-emmer/myace/readme-structure)<a href="https://agentmods.dev/skills/niels-emmer/myace/readme-structure"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/readme-structure/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/niels-emmer/myace/readme-structure"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/readme-structure.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.00037 | $0.00731 |
| Opus 5.5 | $0.00015 | $0.00292 |
| Sonnet 5.5 | $0.00007 | $0.00146 |
| Haiku 4.5 | $0.00004 | $0.00073 |
Grade A, and why
README Structure 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 — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
A README is usually the first (and sometimes only) doc a new contributor or user reads. Use this skill when creating a new README from scratch, restructuring one that's grown unwieldy, or deciding whether new content belongs in the README or needs its own page.
When to use it
- Starting a new project or package that doesn't have a README yet.
- A README has become long enough that readers are visibly skipping sections or asking questions the README already answers (a sign of structure, not content, failure).
- Deciding where a new piece of documentation belongs — extend the README, or start a docs/ page.
Default README shape
- What it is — one or two sentences: what the project does and who it's for. No setup instructions yet, no history, just the summary a stranger needs before deciding to keep reading.
- Quickstart — the shortest path from "nothing installed" to "it's running." Concrete, copy-pasteable commands, not a description of the steps. If there are prerequisites, list them right before the commands that need them, not in a separate section the reader has to hunt for.
- Key commands — the small set of commands a working contributor actually uses day to day (run tests, run the linter, start the dev server, build). Not an exhaustive CLI reference — link out to that if it exists.
- Where to find more — links to deeper docs: architecture notes, contribution guidelines, the agent-facing instruction file if there is one, API references. This section is what makes it safe to keep the README itself short.
Optional sections (license, badges, changelog link) go after this core, not before it — nothing should push the quickstart below the fold.
When a project needs more than a README
A single README stops being the right shape when any of these are true:
- The quickstart section can no longer stay short because there are genuinely multiple setup paths (e.g. different platforms, different deployment targets) that each need real explanation.
- There's enough architectural or design-rationale content that inlining it would bury the quickstart — this belongs in a docs/ directory or dedicated architecture doc, linked from the README.
- Contribution process, coding standards, or review requirements have grown past a few bullet points — split into CONTRIBUTING.md and link it.
- Multiple audiences need fundamentally different entry points (end users vs. plugin authors vs. core contributors) — consider a docs/ directory with per-audience landing pages instead of one README trying to serve everyone.
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 · 42 lines · 37 tokens per session scan A 385d03e6ea13
README Structure is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 3d ago), licensed MIT. It adds 37 tokens to every session and 731 once invoked, about $0.0001 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-08-31.
Other skills, from other repositories
eclipse-license-check
Vet third-party dependencies for an Eclipse Foundation project with the Eclipse Dash License Tool — license checks, "do I need to vet X?" questions, IPLab review filing, and release IP due diligence. Use whenever the user mentions Eclipse license checking, dash-licenses, the Dash License Tool, IPLab, third-party…
idiomatic-go
Apply Go community idioms for API and package design, error and concurrency patterns, naming (initialisms, stutter, receivers), generics vs interfaces, and Go code review — including PR or diff review, questions about "the Go way", pointer vs value receivers, channels vs mutexes, and building Go language tooling…
go-documentation
Write idiomatic Go doc comments that render correctly on pkg.go.dev — package comments, doc.go, exported-symbol comments, testable Example functions, deprecation notices — and publish or debug modules on pkg.go.dev (pkgsite, the module proxy). Use when writing or reviewing Go documentation, or when a developer used to…
publish-vscode-extension
Publish a VS Code extension to the VS Code Marketplace and/or Open VSX Registry. Use when the user wants to publish, ship, or release a VS Code extension; audit or improve manifest, listing, or release setup; build or upload a .vsix; set up vsce or ovsx; create a marketplace publisher or Open VSX namespace; configure…
domainmodel-dsl
Read, write, and modify Domain Model DSL files (.dmodel) — datatypes, entities with inheritance and multi-valued features, and nested packages with qualified cross-references. Use when the user wants to create, edit, explain, or debug a domain model in this DSL, including resolving references across packages.
statemachine-dsl
Read, write, and modify Statemachine DSL files (.statemachine). Use when the user wants to create, edit, explain, or debug a state machine written in this textual DSL — defining states, events, commands, and transitions, or generating a machine from a description.