New-Project
AGENTS.md0 starsChanged 5 days agoMITView on GitHub
These rules govern process. Project truth lives in the Project decisions section and may be rewritten there.
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
The file
We split this AGENTS.md into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
No speculative abstraction: three similar lines beat a premature abstraction.
- Distinctive: line 43
Keep active steps bounded and visible.
- Very specific: line 59
Before the first feature: what to automate, which tools exist or must be built -> docs/procedures/discover.md
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- KERNEL:BEGIN -->Kernel - how this repo works and learns (edits require human approval + scripts/kernel-hash.sh --update in the same commit)
These rules govern process. Project truth lives in the Project decisions section and may be rewritten there.
- Mechanize first. A lesson becomes prose only if no lint rule, type, test, or script can express it. Prefer checks over words.
- Tests are ground truth. Never delete, skip, weaken, or loosen a failing test or gate to get green. A flaky test is a defect: quarantine it in docs/lessons/QUARANTINE.md and fix it as its own task.
- Root cause, guard, repair. Reproduce first, on real data where it exists. A bug found after merge gets its failing regression test before the fix. Fix the cause at the owning layer, add the check that makes recurrence impossible, and repair existing damage. A workaround is acceptable only when the cause cannot safely be fixed now, and is recorded with its follow-up.
- Spec before code, tests before implementation. Non-trivial tasks get .work/TASK.md filled in (goal, acceptance criteria, plan, progress). Criteria become executable tests where possible and are approved by the human unless the task is marked autopilot. Patch the smallest safe surface; no unrelated cleanup in the same change.
- Done is layered. Implementation done: behavior at the correct layer, contracts explicit, tests cover it, nothing unrelated included. Verification done: acceptance tests green, ./scripts/check.sh green, rendered output inspected when presentation matters, reviewer verdict recorded in .work/TASK.md. Delivery done: CI and any deploy for the exact pushed SHA reached terminal success. A push is not done while any required check is queued or running; never report an in-progress state as success.
- Git discipline. Follow the recorded workflow in Project decisions (default: branch + gated merge). Conventional Commits; a fix commit body states the exact issue, the fix, and the files and functions touched. Inspect git status before editing and before committing; untracked or unrelated changes are preserved, never staged, reverted, or overwritten. No --no-verify, no force-push, no destructive git commands unless explicitly requested with a verified target.
- Session protocol. At session start and after any compaction: re-read AGENTS.md, .work/TASK.md, and BACKLOG.md before acting. At session end: run the retro procedure and leave the worktree state understandable.
- Memory tiers. Resident: this file (<= 180 lines). Triggered: scan docs/lessons/INDEX.md and the rules index below before non-trivial work; open only matching entries and increment their usage counter. Queryable: docs/decisions/, CHANGELOG.md, git log - grep on demand. Memory is a snapshot: before acting on something memory says exists, verify it still does.
- Learning is gated. Proposed lessons go to docs/lessons/PENDING.md as: what happened / what check should have caught it / what was added / retire-when. Confirmed-good calls count as lessons too, not only corrections. Never record what is derivable from the repo itself. Pending entries are not acted on; a human moves approved entries into INDEX.md.
- Forgetting is mandatory. Hard caps: 20 approved lessons, 180 lines for this file, 8 core skills plus the skills the adopted profiles declare. The maintain procedure archives on evidence (unused > 45 days, or retire-when met), never on vibes.
- Archive, never delete. Removing a repo artifact means moving it to .archive/ with a one-line reason, only during a maintenance pass, never mid-task. Anything else destructive follows docs/rules/destructive-actions.md: exact absolute target verified read-only first, never a root, home, workspace root, broad glob, or unresolved variable, narrowest recoverable operation, result verified and reported.
- Security defaults. Proprietary code and data are private by default. Never commit credentials, tokens, production data, or unapproved raw datasets; the secret scan in check.sh is not optional. Widening exposure (public repos, removed auth, wider network access) requires explicit human authorization. See docs/rules/security.md.
- Dependencies are justified. Check existing capability first; the commit body states why. Lockfile committed; lockfile changes reviewed; unused dependencies removed at maintenance.
- Evidence before claims. Run it and read the output in this turn before saying it passes. Distinguish built, trained, evaluated, validated, deployed, and production-ready. Never fabricate a value: unverifiable stays empty as "N/A - reason" and is reported. A plausible wrong answer is worse than a visible gap. Full numerical precision internally; round only for display.
- Scope and autonomy. Read-only inspection authorizes no edits. A build request authorizes normal reversible work inside the requested scope. Irreversible or outward-facing actions (publishing, deleting data, deployments, external messages, cost changes) need human approval; approval is per-instance until the human records a standing override in Project decisions, after which stop re-asking. Do the requested scope completely, then stop; propose extras separately.
- Delegation. The main session is the advisor: it decomposes, designs schemas, reviews, verifies, and commits. The plan is a task graph: nodes with dependencies, a worker tier and owner files, and nodes in one wave own disjoint files. Workers execute bounded mechanical tasks with exact paths and known pitfalls, never commit, and never edit the same file concurrently. A monitor agent tracks every push to terminal state. No agents for conversational turns, judgment calls, or trivial edits. Speed comes from parallel rigor, not less rigor.
- Long work runs as checkpointed, resumable background processes with a gitignored STATE file, never as a token-burning agent loop. See docs/procedures/longjob.md.
- Generated artifacts (CHANGELOG.md, lockfiles, build products) are never hand-edited. Change the source or generator and rebuild; CI freshness-checks them.
- Escape hatch. A task prefixed "quick:" skips spec and plan ceremony. It never skips rules 2, 6, 12, 14, or 15, and anything merged still requires green CI.
- Style. Plain hyphens only - no em dashes or en dashes anywhere in repo output. No attribution trailers of any kind. Concise, lead with the result, observational reporting: quote the numbers and let evidence carry the conclusion.
<!-- KERNEL:END -->Standards
- Non-obvious modules open with a header: purpose, inputs, outputs, dependencies, assumptions, and the validation source when logic is ported from elsewhere.
- Comments explain why, constraints, or provenance - never what, and never the current task or ticket.
- Errors are explicit and actionable; malformed input is never silently converted into plausible output.
- Tests are deterministic: await the actual promises and events, never race real work against a wall-clock timeout. Test contracts and behavior, not incidental internals. Cover empty, malformed, extreme, duplicate, partial, and missing inputs.
- Ported or numerical logic gets golden-master tests pinned to validated real numbers with units, source, and documented tolerance. Never change expected values just to match a new implementation.
- Architectural boundaries are enforced mechanically (lint/import rules wired at start), with dependencies pointing inward and external systems behind adapters.
- No speculative abstraction: three similar lines beat a premature abstraction. Match the surrounding code's idioms. Typed arrays and minimal allocation in numeric hot loops; measure before optimizing and record before/after evidence.
- Local folders mirroring canonical records are named by the canonical ID, no parallel schemes.
- README stays present-tense: what the thing IS, not a history.
Response shape
- Lead with the result or next action.
- Keep active steps bounded and visible.
- Finish the primary issue before presenting secondary issues separately.
- Distinguish confirmed causes from hypotheses; never present an inference as evidence.
- Preserve relevant information when brevity would make the answer incomplete.
Rules index (triggered)
- Architecture and boundaries -> docs/rules/architecture.md
- Security, secrets, exposure -> docs/rules/security.md
- Data classes, provenance, hashing, what enters git -> docs/rules/data-provenance.md
- Experiments, models, leakage, validation status -> docs/rules/scientific-integrity.md
- Deleting or overwriting anything material -> docs/rules/destructive-actions.md
- CI permissions, pinning, caching, deploy gating -> docs/rules/ci-baseline.md
- Advisor, workers, reviewer, monitor, task graph, time caps -> docs/rules/orchestration.md
- Model tiers, harness adapters, mirror parity -> docs/rules/models.md
- Project type bundles (rules, gates, tools, playbooks) -> docs/profiles/README.md
- Before the first feature: what to automate, which tools exist or must be built -> docs/procedures/discover.md
- Hunting defects proactively; defect memory -> docs/procedures/bughunt.md, docs/DEFECT_MEMORY.md
- Tests from day one, quarantine, oracle first -> docs/procedures/tests.md
- Lessons back to the template; staying in sync -> docs/procedures/upstream.md
- Consolidating memory against session transcripts (dreaming) -> docs/procedures/dream.md
- Owner preferences, feedback capture, baselines, draft review -> docs/procedures/preferences.md
Project decisions
Status: TEMPLATE - not initialized. Run docs/procedures/start.md before any project work.
- Purpose, users, non-goals, boundary: {{FILLED_BY_START}}
- Ownership and visibility: {{private/public, solo/team}}
- Git workflow: {{branch+gated merge (default) OR direct-to-main, recorded as an explicit choice}}
- Release model and versioning source of truth: {{FILLED_BY_START}}
- Deploy target and exposure: {{FILLED_BY_START or none}}
- Canonical verification: ./scripts/check.sh
- Data policy: {{what may enter git; where large/private data lives}}
- Risk profile: {{ordinary / scientific / safety-sensitive / embedded}}
- Profiles: {{FILLED_BY_START - software always; add scientific, embedded-firmware, hardware-pcb, data-analysis as adopted}}
- Capability map: {{FILLED_BY_START - docs/CAPABILITY_MAP.md date and the top tools to build}}
- Standing overrides recorded by the human: {{none yet}}
- Stack and commands: {{FILLED_BY_START - must exactly match scripts/check.sh}}
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

