Skills init
Creates, updates, or optimizes an AGENTS.md file for a repository with minimal, high-signal instructions covering non-discoverable coding conventions, tooling quirks, workflow preferences, and project-specific rules that agents cannot infer from reading the codebase. Use when setting up agent instructions or Claude configuration for a new repository, when an existing AGENTS.md is too long, generic, or stale, when agents repeatedly make avoidable mistakes, or when repository workflows have changed and the agent configuration needs pruning. Applies a discoverability filter—omitting anything Claude can learn from README, code, config, or directory structure—and a quality gate to verify each line remains accurate and operationally significant.
git clone https://github.com/mcollina/skills
T=$(mktemp -d) && git clone --depth=1 https://github.com/mcollina/skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/init" ~/.claude/skills/mcollina-skills-init && rm -rf "$T"
skills/init/SKILL.mdWhen to use
Use this skill when creating or updating
AGENTS.md for a repository.
Use it especially when:
- the current
is long, generic, or staleAGENTS.md - agents repeatedly make the same avoidable mistakes
- repository workflows changed and agent guidance needs pruning
Instructions
Treat
AGENTS.md as a living list of non-discoverable landmines and workflow gotchas, not a codebase overview.
Core rule: discoverability filter
Before adding any line, ask:
Can an agent discover this by reading the repo (
, code, config, scripts, directory tree)?README
- If yes: do not include it in
.AGENTS.md - If no, and it materially affects task success/cost/safety: include it.
What earns a line
Include only guidance that is:
- Non-discoverable from repository files alone
- Operationally significant (changes commands, outcomes, or safety)
- Actionable (specific enough to execute)
Typical examples:
- Non-standard tooling choices (e.g. use
instead ofuv
)pip - Command caveats (e.g. tests must run with
due to fixture behavior)--no-cache - Hidden constraints/landmines (deprecated directories still imported in production)
- Critical local conventions that are not encoded in lint/tests/config
What to remove or avoid
Do not include:
- Tech stack summaries
- Directory structure overviews
- Architecture descriptions agents can infer from code
- Generic best-practice advice
- Rules already enforced by tooling (linters, typecheck, tests, CI)
- Mandatory boilerplate headers unless the repo explicitly requires one
Recommended structure
Prefer short, high-signal sections such as:
(which areas need separate/module-local AGENTS files)Scope & routingNon-discoverable commandsLandmines / do-not-touch areasTask-specific constraints
For large repos, recommend hierarchical AGENTS.md files near relevant modules instead of one monolithic root file.
Source files to check first
- Existing
AGENTS.md README.md
(if present)PROJECT.md- Cursor rules (
or.cursor/rules/
).cursorrules - Copilot instructions (
).github/copilot-instructions.md GEMINI.md- CI/workflow files and package manager config (for command/tooling mismatches)
If
AGENTS.md exists, improve it incrementally instead of replacing it blindly.
Maintenance mindset
AGENTS.md is temporary guidance, not permanent configuration.
When recurring issues appear:
- Prefer fixing the root cause in code/tooling (lint rule, test, script, structure)
- Keep only the minimum instruction needed until the root cause is solved
- Prune stale instructions aggressively
Quality gate before finalizing
For each line in
AGENTS.md, verify:
- Is it non-discoverable?
- Is it still accurate today?
- Does it materially reduce mistakes/cost/time?
Delete any line that fails one of these checks.