/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
$ npx -y skills add mcollina/skills --skill init --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/init
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
init.SKILL.mdname: init
description: 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.
metadata:
tags: initialization, agents, context-engineering, agents-md, maintenance
When to use
Use this skill when creating or updating `AGENTS.md` for a repository.
Use it especially when:
- the current `AGENTS.md` is long, generic, or stale
- 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 (`README`, code, config, scripts, directory tree)?
- 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: 1. **Non-discoverable** from repository files alone 2. **Operationally significant** (changes commands, outcomes, or safety) 3. **Actionable** (specific enough to execute)
Typical examples:
- Non-standard tooling choices (e.g. use `uv` instead of `pip`)
- Command caveats (e.g. tests must run with `--no-cache` due to fixture behavior)
- 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:
- `Scope & routing` (which areas need separate/module-local AGENTS files)
- `Non-discoverable commands`
- `Landmines / do-not-touch areas`
- `Task-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`
- `PROJECT.md` (if present)
- Cursor rules (`.cursor/rules/` or `.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: 1. Prefer fixing the root cause in code/tooling (lint rule, test, script, structure) 2. Keep only the minimum instruction needed until the root cause is solved 3. 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.
Read more
name: init description: 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. metadata: tags: initialization, agents, context-engineering, agents-md, maintenance
When to use
Use this skill when creating or updating `AGENTS.md` for a repository.
Use it especially when:
- the current `AGENTS.md` is long, generic, or stale
- 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 (`README`, code, config, scripts, directory tree)?
- 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: 1. **Non-discoverable** from repository files alone 2. **Operationally significant** (changes commands, outcomes, or safety) 3. **Actionable** (specific enough to execute)
Typical examples:
- Non-standard tooling choices (e.g. use `uv` instead of `pip`)
- Command caveats (e.g. tests must run with `--no-cache` due to fixture behavior)
- 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:
- `Scope & routing` (which areas need separate/module-local AGENTS files)
- `Non-discoverable commands`
- `Landmines / do-not-touch areas`
- `Task-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`
- `PROJECT.md` (if present)
- Cursor rules (`.cursor/rules/` or `.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: 1. Prefer fixing the root cause in code/tooling (lint rule, test, script, structure) 2. Keep only the minimum instruction needed until the root cause is solved 3. 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.
Repo: mcollina/skills
Other skills on mcollina-skills.
- /documentation
Creates, structures, and reviews technical documentation following the Diátaxis framework (tutorials, how-to guides, reference, and explanation pages). Use when a user needs to write or reorganize docs, structure a tutorial vs. a how-to guide, build reference docs or API
Open skill - /fastify
Guides development of Fastify Node.js backend servers and REST APIs using TypeScript or JavaScript. Use when building, configuring, or debugging a Fastify application — including defining routes, implementing plugins, setting up JSON Schema validation, handling errors,
Open skill - /linting-neostandard-eslint9
Configures ESLint v9 flat config and neostandard for JavaScript and TypeScript projects, including migrating from legacy `.eslintrc*` files or the `standard` package. Use when you need to set up or fix linting with `eslint.config.js` or `eslint.config.mjs`, troubleshoot lint
Open skill - /node
Provides domain-specific best practices for Node.js development with TypeScript, covering type stripping, async patterns, error handling, streams, modules, testing, performance, caching, logging, and more. Use when setting up Node.js projects with native TypeScript support,
Open skill - /nodejs-core
Contributes to and debugs Node.js core, including nodejs/node commit and PR tone, contribution workflows, native crashes, V8 performance, node-gyp builds, N-API bindings, and libuv issues. Use when drafting or reviewing a Node.js core commit or pull request, working in
Open skill - /oauth
Implements OAuth 2.0/2.1 authorization flows in Fastify applications — configures authorization code with PKCE, client credentials, device flow, refresh token rotation, JWT validation, and token introspection/revocation endpoints. Use when setting up authentication,
Open skill

