> 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.
curl "https://skillshub.wtf/getsentry/skills/agents-md?format=md"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.
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's name and attribution byline)
Example: `Co-Authored-By: Claude Sonnet 4 <noreply@example.com>`
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'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 |
> related_skills --same-repo
> skill-creator
Alias for sentry-skills:skill-writer. Use when users explicitly ask for "skill-creator" or reference the legacy skill name. Redirects to the canonical skill authoring workflow.
> security-review
Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security", "OWASP review", or review code for injection, XSS, authentication, authorization, cryptography issues. Provides systematic review with confidence-based reporting.
> doc-coauthoring
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
> code-simplifier
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Use when asked to "simplify code", "clean up code", "refactor for clarity", "improve readability", or review recently modified code for elegance. Focuses on project-specific best practices.