Agents md
This skill should be used when the user asks to "create AGENTS.md", "update AGENTS.md", "maintain agent docs", "set up CLAUDE.md", or needs to keep agent instructions concise. Enforces research-backed best practices for minimal, high-signal agent documentation.From its SKILL.md
npx -y skills add sickn33/agentic-awesome-skills --skill agents-mdAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
4.6 KB, as published. Nobody here has run it
Maintaining AGENTS.md
AGENTS.md is the canonical agent-facing documentation. Keep it minimal—agents are capable and don't need hand-holding. Target under 60 lines; never exceed 100. Instruction-following quality degrades as document length increases.
When to Use
- The user asks to create, update, or audit
AGENTS.mdorCLAUDE.md. - The project needs concise, high-signal agent instructions derived from the actual toolchain and repo layout.
- Existing agent documentation is too long, duplicated, or drifting away from real project conventions.
File Setup
- Create
AGENTS.mdat project root - Create symlink:
ln -s AGENTS.md CLAUDE.md
Before Writing
Analyze the project to understand what belongs in the file:
- Package manager — Check for lock files (
pnpm-lock.yaml,yarn.lock,package-lock.json,uv.lock,poetry.lock) - Linter/formatter configs — Look for
.eslintrc,biome.json,ruff.toml,.prettierrc, etc. (don't duplicate these in AGENTS.md) - CI/build commands — Check
Makefile,package.jsonscripts, CI configs for canonical commands - Monorepo indicators — Check for
pnpm-workspace.yaml,nx.json, Cargo workspace, or subdirectorypackage.jsonfiles - Existing conventions — Check for existing CONTRIBUTING.md, docs/, or README patterns
Writing Rules
- Headers + bullets — No paragraphs
- Code blocks — For commands and templates
- Reference, don't embed — Point to existing docs: "See
CONTRIBUTING.mdfor setup" or "Follow patterns insrc/api/routes/" - No filler — No intros, conclusions, or pleasantries
- Trust capabilities — Omit obvious context
- Prefer file-scoped commands — Per-file test/lint/typecheck commands over project-wide builds
- Don't duplicate linters — Code style lives in linter configs, not AGENTS.md
Required Sections
Package Manager
Which tool and key commands only:
## Package Manager
Use **pnpm**: `pnpm install`, `pnpm dev`, `pnpm test`
File-Scoped Commands
Per-file commands are faster and cheaper than full project builds. Always include when available:
## File-Scoped Commands
| Task | Command |
|------|---------|
| Typecheck | `pnpm tsc --noEmit path/to/file.ts` |
| Lint | `pnpm eslint path/to/file.ts` |
| Test | `pnpm jest path/to/file.test.ts` |
Commit Attribution
Always include this section. Agents should use their own identity:
## Commit Attribution
AI commits MUST include:
Co-Authored-By: (the agent model's name and attribution byline)
Example: `Co-Authored-By: Claude Sonnet 4 <[email protected]>`
Key Conventions
Project-specific patterns agents must follow. Keep brief.
Optional Sections
Add only if truly needed:
- API route patterns (show template, not explanation)
- CLI commands (table format)
- File naming conventions
- Project structure hints (point to critical files, flag legacy code to avoid)
- Monorepo overrides (subdirectory
AGENTS.mdfiles override root)
Anti-Patterns
Omit these:
- "Welcome to..." or "This document explains..."
- "You should..." or "Remember to..."
- Linter/formatter rules already in config files (
.eslintrc,biome.json,ruff.toml) - Listing installed skills or plugins (agents discover these automatically)
- Full project-wide build commands when file-scoped alternatives exist
- Obvious instructions ("run tests", "write clean code")
- Explanations of why (just say what)
- Long prose paragraphs
Example Structure
# Agent Instructions
## Package Manager
Use **pnpm**: `pnpm install`, `pnpm dev`
## Commit Attribution
AI commits MUST include:
Co-Authored-By: (the agent model's name and attribution byline)
## File-Scoped Commands
| Task | Command |
|------|---------|
| Typecheck | `pnpm tsc --noEmit path/to/file.ts` |
| Lint | `pnpm eslint path/to/file.ts` |
| Test | `pnpm jest path/to/file.test.ts` |
## API Routes
[Template code block]
## CLI
| Command | Description |
|---------|-------------|
| `pnpm cli sync` | Sync data |
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most docs writing skills give
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.