Open your AGENTS.md file. Does it describe your folder structure? Does it explain that you run npm install to install dependencies and npm test to run the unit tests? Does it ask the agent to "write clean, maintainable code"?

It does nothing for your agent. You can delete it.

Well, almost. What deserves to stay should be short, precise, and hard for the agent to discover on its own in a reasonable amount of time. In most projects, a few lines are enough, especially if you use skills.

Stop babysitting your agent

The first coding agents couldn't explore a project. Long instruction files made sense back then.

Today, agents do what a good developer would do on day one: they read package.json and angular.json, notice that your components are standalone and use signals, run the tests, and pick up the style of the surrounding code.

They infer, and they're good at it. Telling them "this is an Angular application written in TypeScript" is like handing a senior developer a note that says "this is a keyboard."

Your current file probably does more harm than good

Here's an AGENTS.md file from a real Angular project. I trimmed it, since the original runs over 80 lines:

# Instructions

- This project is for internal use of XYZ company.

## Angular Best Practices

- **Use Angular CLI**: Use Angular CLI for creating components, services,
  and other files.

  ```
  ng new component my-component --standalone
  ng generate service my-service
  ng generate interface my-interface
  ```

## Project Folder Structure

### Root Directory

- Keep a **flat and predictable** structure.
- **angular-project/**: This is the root directory of your Angular project.

### Source Directory

- **src/**: Contains the source code of your application.
- **app/**: Main application folder.
- **core/**: Contains singleton services [...]
- **shared/**: Contains shared components, directives, and pipes.
  [... 30 more lines of folders ...]
- **polyfills.ts**: Polyfills for browser compatibility.

### Other Files

- **.postcssrc.json**: Postcss configuration file for Tailwindcss >= 4.
- **angular.json**: Configuration file for Angular CLI.
- **package.json**: NPM package configuration file.
- **tsconfig.json**: TypeScript configuration file.

## Angular Coding Guidelines

- **Nested feature**: if the feature to create is a nested feature, create
  the folder under the parent folder and place the new feature inside it.
- **Standalone Components**: Utilize standalone components to simplify
  module management and improve code clarity.
- **Standalone Components**: Use `standalone: true` in component
  configurations to leverage Angular's standalone component architecture.
- ...

## Tailwind Coding Guidelines

- **.html**: Use Tailwind's utility classes directly in your HTML files.

Someone clearly put time into this file. Here's what it costs.

It wastes context

The file is loaded in every session and for every task, which burns tokens for nothing and clutters the context window.

Forty lines of folder tree and a reminder that package.json is the "NPM package configuration file" take up room that should go to the task itself. The agent can run ls, knows what package.json is, and doesn't care that your company is called XYZ.

It gets things wrong and contradicts the code

ng new creates a new Angular workspace, not a component.

Recent Angular projects don't have a polyfills.ts file.

Components have been standalone by default since Angular 19, so standalone: true is just noise that the agent will dutifully add everywhere.

It's a generic template, not a description of your project

"Keep a flat and predictable structure." "This is the root directory of your Angular project." These lines would fit any Angular project on the planet, so they tell the agent nothing about yours.

Files like this are often copied from a blog post or generated once and never touched again. And it shows, starting with the angular-project folder, which doesn't even exist.

The agent already knows the generic Angular advice. What it can't know is what's specific to your codebase, and that's exactly what's missing.

The two golden rules

For every line in your AGENTS.md file, ask yourself two questions:

1. Would you say it to a good developer?

Picture a competent developer starting tomorrow. You wouldn't tell them to "follow best practices." You would, however, tell them: "Don't copy the patterns in legacy/: we're migrating that code." Or: "Use port 8001 to test the app, because it runs behind our in-house proxy." If you wouldn't say it to a good developer, don't say it to the agent.

2. Can the agent figure it out on its own without breaking the bank?

The folder structure, the Angular version, the npm scripts, and the formatting rules are all in the code and the config. Writing them down again creates a second source of truth, and sooner or later it will drift from the first. If the agent can easily infer it, leave it out.

What's left of that example?

Put that file through the two rules. The CLI commands, the folder tree, the config files, and the standalone components are all visible in the code. "This project is for internal use" changes nothing about how the code should be written. What's left? Maybe the Tailwind line, but it needs rewording. For example:

Prefer Tailwind utility classes over custom SCSS.

That's a team choice the agent can't guess in a project that uses both styles. So one line survives the two rules. But does it really belong in AGENTS.md?

AGENTS.md or skill?

For every line that passed both tests, ask a third and final question: does the agent need this information for every task?

If so, it belongs in AGENTS.md. If not, put it in a skill, which the agent only loads when the task calls for it.

Translation conventions, for example, only matter when a task touches internationalization. So they live in an angular-i18n skill:

---
name: angular-i18n
description: Guidelines for implementing internationalization in Angular apps
---

## Naming convention

- Keys must be ALL UPPERCASE.
- The dot (`.`) notation should be used for grouping related keys. Example: `NAV.HOME.TITLE`, `NAV.HOME.DESCRIPTION`

## Implementation

- Import the `TranslatePipe` in the component TypeScript file. Do not import `TranslateModule`.

The same goes for the Tailwind line from our example: it only matters for UI tasks, so it belongs in a skill. In the end, nothing is left.

What should go in AGENTS.md?

Instructions that apply to every task and that are expensive to get wrong. A skill only gets loaded when the agent knows it needs it. But with these instructions, the agent only realizes it needed them after making the mistake.

For example:

  • The don'ts: don't edit generated files or Liquibase migrations that have already been applied, and don't copy the patterns in legacy/.
  • Quirks of the local environment: the app is tested on port 8001, behind the in-house proxy, not on port 4200.
  • Working habits: open a PR automatically at the end of every task.

Here's what that might look like:

- Never edit generated files or Liquibase migrations that have already been applied.
- Don't copy patterns from `legacy/`: this code is being migrated.
- Test the app on port 8001 (behind our proxy), not on 4200.
- Open a PR automatically when you finish a task.

Four lines that pass both rules, and that the agent needs for every task.

Finally, no rule lasts forever. Once the legacy/ migration is done, that line is useless and you can delete it. A good AGENTS.md gets thinner over time. Only add a line after you've seen the agent get it wrong.

Conclusion

Go through your AGENTS.md line by line. If you wouldn't say it to a good developer, or if the agent can figure it out on its own without burning through tokens, delete it. If it only matters for some tasks, move it to a skill.

You'll be left with a few lines, sometimes none. Either way, that beats a file that lies.

If you enjoyed this article, follow @ahasall on Twitter for more content like this.