Agent rule pattern

Behavioral framing

Rules for approaching the work, not facts about the repository.

43 of 100 projects

The shape of the rule

  1. Name a recurring mistake
  2. Set a decision rule
  3. Make the action observable
How to use it

State tradeoffs, do not over-build, and touch only what the request needs. Two projects say these rules came from mistakes agents kept making.

Turn a recurring mistake into a decision the agent can act on: what to check before editing, when to stop expanding scope, or when a request should remain read-only.

Examples from real projects

3 examples · Pinned source

Four framing sections before any repository detail

Four general sections come first: Think Before Coding, Simplicity First, Surgical Changes, and Goal-Driven Execution. They cover assumptions, scope, adjacent code, and completion criteria.

AGENTS.mdL3
Source excerpt starting at line 3.
**Don't assume. Don't hide confusion. Surface tradeoffs.**

Prove the contract violation

Reproduction is the start of triage. The file requires evidence from documented behavior, types, or established runtime semantics before treating the result as a bug.

AGENTS.mdL56
Source excerpt starting at line 56.
- A reproducible error is not automatically a bug. First prove the behavior violates Better Auth's documented contract, TypeScript contract, or established runtime semantics.

Questions treated as read-only

A question about the codebase does not imply permission to change it. The default is stated in one line at the top of the working style section.

AGENTS.mdL23
Source excerpt starting at line 23.
- Treat questions about the codebase as read-only unless the user asks for changes.

Projects using this pattern (43)

Browse in directory →
Show 35 more projects
← All agent rule patterns