awesome-agent-skills: Instructions file for Claude Code

AGENTS.md

Rules for this repository, on top of whatever global guidance an agent already loads.

Examples in a skill are abstract, never real

A skill teaches a rule; it never carries a sample of anyone's actual work. Every example in SKILL.md and in references/ is a shape or a placeholder — what the sentence does, not the sentence itself.

Never a real post, a real account, a real person's text, a captured run, a screenshot of one, or anything copied from the author's own published writing. Two reasons, each sufficient: that material is private and does not belong in a published skill, and a sentence printed in a skill comes back verbatim in the next run's output.

No evals, in any form

This repository has no eval concept and no files for one. No evals/ folder, no cases, no fixtures, no known-good and known-bad pairs, no runner, and no mention of any of it inside a skill.

A rule a skill states is proved by reading it, and a check it prescribes is proved by running it on the work in hand.

Text only: a skill instructs, it never ships code

A skill folder holds SKILL.md plus references/, and nothing else. No scripts/, no templates/, no .mjs, .py, .sh, .ps1, .html, .json fixture, no binary, no file that exists to be executed or copied into the user's project. Markdown is the only format a skill ships.

The reason is where the work happens. An agent reading a skill knows its own platform, its own shell, its own language runtimes and what the user's repository already has; a file written here months ago knows none of that, and running it puts the author's code on someone else's machine. So a skill says what to check, what counts as a pass, what the thresholds are and what evidence to report — and the agent writes whatever it needs, in whatever language fits, or performs the check by reading.

This binds the wording too: a skill never prints a script for the reader to paste, never specifies a command-line interface, a flag set, a file layout for a checker, or the shape its output should take as code. A one-line shell command against a standard tool stays welcome where it is the clearest way to say what to look for; a program does not, however short. The line is what the block is for: code that is the subject being taught — what a typed error looks like in the reader's own codebase, the markup an accessible control needs, a configuration entry — is the skill's content and stays; a routine the reader is meant to run against their project is the thing this rule removes, and it is written as what to do instead.