<!--
  AGENTS.md STARTER TEMPLATE
  =========================
  This is a commented skeleton for your first AGENTS.md, the plain-markdown file
  that gives AI coding tools the standing context they need to work on your project.

  HOW TO USE THIS FILE:
  1. Rename it to AGENTS.md
  2. Put it at the root of your repository
  3. Replace each placeholder below with details from your own project
  4. Delete the HTML comment notes (the lines wrapped in <!-- -->) once you have filled a section

  A FEW THINGS WORTH KNOWING:
  - There are no required fields and no required sections. Use any headings you like.
    The sections below are the ones the standard suggests; keep the ones that fit, drop the rest.
  - AGENTS.md complements your README. The README is for humans; this file holds the
    extra context a coding agent needs to do the job well.
  - Write it as guidance, not a guarantee. The file shapes how a tool behaves, but the
    instructions are context, not an enforcement layer, so review the tool's work as you
    would a teammate's.
  - Keep it lean. A useful rule of thumb is under 200 lines. Longer files use more
    context and the instructions get followed less reliably. Start with what you
    re-explain most, and grow it as you go.

  USING CLAUDE CODE? It reads CLAUDE.md, not AGENTS.md. You do not have to keep two
  copies in sync. Create a CLAUDE.md that imports this file:

      @AGENTS.md

      ## Claude Code

      Use plan mode for changes under src/billing/.

  A symlink also works if you do not need Claude-specific notes: ln -s AGENTS.md CLAUDE.md
  (On Windows a symlink needs Administrator privileges or Developer Mode, so the
  @AGENTS.md import is the safer default there.)
-->

# AGENTS.md

## Project overview

<!-- Two or three sentences on what this project is and what it does. Give the tool the
     same orientation you would give a new teammate before handing them a task. -->

_Describe your project here._

## Build and test commands

<!-- The exact commands you run most, written out in full. This section pays off fastest,
     because a tool guessing at your test runner is the most common way a good change goes
     sideways. Use only the commands you actually run, not the ones you wish you ran. -->

```
# build:   <your build command here, e.g. npm run build>
# test:    <your test command here, e.g. npm test>
# run:     <your local dev command here, e.g. npm run dev>
```

## Code style and conventions

<!-- Naming, formatting, the patterns you want matched, and the ones you have moved away
     from. Be specific. A note telling the tool to match the style of the surrounding file
     fits here too. -->

- _Naming and formatting conventions go here._
- _Patterns you want followed go here._
- _Patterns you have moved away from go here._

## Testing instructions

<!-- How you expect changes to be verified before they are considered done. Name the check
     you run before a commit. -->

_Describe how changes should be tested here._

## Security considerations

<!-- Anything sensitive an agent should avoid touching: folders to leave alone, files that
     hold secrets, areas that need extra care. -->

- _Folders or files an agent should leave alone go here._
- _Anything sensitive to avoid goes here._

---

<!--
  WORKED EXAMPLE
  ==============
  Here is one short, filled-in version so you can see the shape. It is for an imaginary
  to-do list web app. Yours will look different. Delete this whole block before you ship.

  # AGENTS.md

  ## Project overview

  Taskbird is a small web app for shared to-do lists. The frontend is React, the backend
  is a Node API, and data lives in Postgres.

  ## Build and test commands

  ```
  # build:   npm run build
  # test:    npm test
  # run:     npm run dev
  ```

  ## Code style and conventions

  - Use two-space indentation and single quotes.
  - Components are function components. We moved away from class components, so do not add new ones.
  - Match the style of the surrounding file.

  ## Testing instructions

  Run npm test before any commit. Every new API route needs at least one test.

  ## Security considerations

  Do not touch the /infra folder or anything under /config/secrets. Never commit a .env file.
-->
