Every codebase has rules that live in people’s heads: which package manager to use, how you name things, the folder that’s off-limits, the migration you never touch. A rules file writes those down once so 100xprompt reads them at the start of every session. No more re-explaining your project each time you sit down. Rules are plain Markdown. You author them, you own them, and they travel with your repository so your whole team gets the same guidance.

​
How rules files merge

Create a file named AGENTS.md and 100xprompt treats it as standing instructions. You can place rules at three levels, and 100xprompt merges them all into the guidance it follows:
  • Global rules - how you like to work, on every project.
  • Project rules - conventions for this repository, shared with your team.
  • Folder rules - extra context for a specific subfolder, closest to the code it describes.
More specific rules add to the picture rather than starting over: when you work inside a subfolder, its rules layer on top of the project and global ones. Global gives your baseline, the project root sets the shared conventions, and folder-level files add local detail exactly where it’s relevant.
AGENTS.md is the recommended, cross-tool standard filename. 100xprompt also recognizes a native 100xprompt.md at the same locations if you prefer a project-specific name.

​
Place rules at the right level

​
Write rules worth following

The best rules files are short, concrete, and about this project. Aim for the things you’d tell a strong new engineer on day one.
  • Package manager and how to run, build, and test the project.
  • Naming conventions, formatting, and import style.
  • Preferred libraries - and ones you’ve deliberately moved away from.
## Conventions
- Use `pnpm`, never `npm` or `yarn`.
- Run `pnpm test` before considering any change done.
- Prefer named exports. No default exports.
- Dates are always UTC ISO-8601 strings.
A short map of how the project fits together saves 100xprompt from guessing.
## Architecture
- `packages/api` - REST service, talks to Postgres.
- `packages/web` - the front end; calls the API, never the DB directly.
- Shared types live in `packages/shared` - update them there, not in copies.
Guardrails are some of the highest-value rules. Be explicit.
## Do
- Add a test for every bug fix.
- Keep public API changes backward compatible.

## Don't
- Don't edit files in `generated/` - they're built from schema.
- Don't add new runtime dependencies without flagging it first.
- Don't touch the payments module without asking.
Business rules and vocabulary that aren’t obvious from the code.
## Domain
- A "seat" is a paid user; an "invite" is not billed until accepted.
- Tax logic lives in `billing/tax.ts` and must match the rules in `docs/tax.md`.
Keep rules actionable and specific. “Write clean code” doesn’t help; “Validate all input at the route boundary with zod” does. Delete rules that go stale - an out-of-date rule is worse than none.

​
Pull in other files with @ references

Suppose you already maintain a style guide or testing standard elsewhere. A rules file can include other files inline with an @ reference, so you compose guidance from focused pieces instead of duplicating them. 
# Project Rules

See our full style guide: @./docs/style-guide.md

Testing standards: @~/standards/testing.md
References resolve like this:
SyntaxResolves to
@./relative/path.mdRelative to the file doing the including
@path/to/file.mdRelative to the file doing the including
@~/some/path.mdRelative to your home directory
@/absolute/path.mdAn absolute path
The referenced file’s contents are pulled in as if they were part of the rules file, so you can keep long-lived standards in one place and reference them from several projects.
Includes are resolved recursively - an included file can include others - and 100xprompt guards against loops. Only text files (Markdown, plain text, .json, .yaml, and similar) can be included, and @ references inside code blocks or inline code are treated as literal text, not includes.
There’s a generous but finite budget for how much rules text is loaded at once. Keep files focused; if you’re pulling in very large documents, reference just the sections that matter rather than entire manuals.

​
Write your first AGENTS.md

1

Create the file at your repo root

In the root of your project, create a file named AGENTS.md.
touch AGENTS.md
2

Start with the essentials

Write down how to run the project and the two or three rules you’d most want followed.
# Project Rules

## Setup
- Package manager: pnpm. Run `pnpm install`, then `pnpm dev`.
- Tests: `pnpm test`. Everything must pass before a change is done.

## Conventions
- TypeScript strict mode. No `any`.
- Named exports only.

## Don't
- Don't edit anything under `generated/`.
3

Add architecture and domain notes

Give a short map of the codebase and any domain vocabulary that isn’t obvious from the code. A paragraph each is plenty.
4

Reference shared standards (optional)

If you keep style guides or testing standards elsewhere, pull them in with an @ reference instead of duplicating them.
Full style guide: @./docs/style-guide.md
5

Commit it

Commit AGENTS.md so your whole team - and every future session - benefits from the same guidance.
git add AGENTS.md && git commit -m "Add project rules for 100xprompt"
From now on, 100xprompt reads these rules at the start of every session on this project.

​
Tips & limits

Global rules are the broadest, project rules narrow them to this repo, and folder rules add local detail. When you work deep in the tree, all applicable layers combine - so put universal rules high and specific rules close to the code.
Rules load into every session. A tight, current file is far more effective than a long one. Prune aggressively and let @ includes hold the bulky reference material.
Rules are explicit instructions you author and commit. Memory is what 100xprompt learns and recalls on its own over time. Use rules for the conventions you want enforced every time; let memory handle the softer, evolving context.

Settings & Configuration

Point 100xprompt at extra instruction files and tune project behavior in 100xprompt.json.

Memory & Context

How 100xprompt remembers durable facts across sessions - and how it differs from rules.

Best Practices

Patterns for getting the most out of 100xprompt on real projects.