agentleFS
gosudagosuda/portal/AGENTS.md

portal

AGENTS.md293 starsChanged 3 months agoMITView on GitHub

Keep this file short and behavioral. Architecture documentation should primarily describe the current architecture. Issues and pull requests preserve short-lived refactoring, migration, and rejected-design history.

We split this AGENTS.md into the rules it gives an agent

28 rules. About 0 are common, 24 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈24

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep this file short and behavioral.

    line 3
  2. Distinctive:

    Do not keep historical artifacts that no longer explain or protect current behavior.

    line 11
  3. Distinctive:

    Prefer a single stable contract with one real owner.

    line 12
  4. Distinctive:

    Prefer local simplicity over premature or speculative abstraction.

    line 13
  5. Distinctive:

    Add indirection only when it removes real coupling or protects a real boundary.

    line 14
  6. Distinctive:

    Do not generalize a one-off problem by default.

    line 16
  7. Distinctive:

    Keep a regression test when the regression reveals a contract or invariant that remains important.

    line 18
  8. Distinctive:

    Do not test incidental implementation details such as call sequence, log output, retry count, or file metadata unless they are themselves …

    line 19
  9. Distinctive:

    When a refactor makes an implementation-coupled test obsolete, delete it if no enduring behavior or invariant would be left unprotected.

    line 20
  10. Very specific:

    Prefer deterministic unit tests at the lowest coherent owner, or real black-box E2E tests in e2e/.

    line 21
  11. Distinctive:

    Never add a production callback, interface, config knob, wrapper, synchronization primitive, or injection seam only to make a test possible.

    line 22
  12. Very specific:

    When a regression crosses components, protect the enduring invariant in its lowest owner.

    line 23
  13. Distinctive:

    When caller and callee are both local and no real boundary exists, change both directly.

    line 27
  14. Distinctive:

    If a field, method, wrapper, or abstraction has no clear, current use and does not protect a real boundary, remove it immediately.

    line 28
  15. Distinctive:

    No wrapper functions or helpers unless they remove real coupling, protect a real boundary, or represent independently meaningful behavior.

    line 29
  16. Distinctive:

    Prefer changing existing code directly when the change remains local.

    line 30
  17. Distinctive:

    Prefer direct code over layers, facades, and indirection when the extra structure would outgrow the problem it solves.

    line 31
  18. Distinctive:

    Prefer existing ownership and serialization over adding synchronization unless concurrency itself is part of the problem being modeled.

    line 32
  19. Distinctive:

    Prefer flattening and merging nearby responsibilities over splitting by default.

    line 33
  20. Distinctive:

    Remove dead fields, methods, config, and stale state while touching nearby code.

    line 34
  21. Distinctive:

    Do not duplicate normalization, validation, or defaulting logic.

    line 35
  22. Very specific:

    Keep shared stateless transforms in utils/.

    line 36
  23. Very specific:

    Keep stable shared contracts, constants, and public paths in types/, not in runtime or helpers.

    line 37
  24. Distinctive:

    Use ADRs sparingly for stable, long-lived architecture or compatibility decisions.

    line 40
  25. Distinctive:

    Keep ordinary refactors, migrations, rejected approaches, and temporary implementation decisions in issues and pull requests unless they …

    line 41
  26. Distinctive:

    Remove stale or superseded documentation that no longer helps explain the current system or its supported compatibility constraints.

    line 42
  27. Distinctive:

    Run tests only when explicitly requested.

    line 48
  28. Distinctive:

    If verification seems necessary, ask before running it.

    line 49

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

AGENTS.md

Keep this file short and behavioral. Architecture documentation should primarily describe the current architecture. Issues and pull requests preserve short-lived refactoring, migration, and rejected-design history.

Development Principles

  • Minimize concepts, duplication, and ceremony.
  • Do not keep historical artifacts that no longer explain or protect current behavior.
  • Prefer a single stable contract with one real owner.
  • Prefer local simplicity over premature or speculative abstraction.
  • Add indirection only when it removes real coupling or protects a real boundary.
  • Before introducing a new mechanism or local subsystem, judge whether the problem is large, repeated, long-lived, or independent enough to justify one. Examples include interfaces, wrappers, helpers, callbacks, hooks, locks, channels, goroutines, registries, caches, shadow state, generation counters, configuration knobs, feature flags, state machines, reconciliation loops, adapters, and extension points. Prefer the existing owner, control flow, data flow, lifecycle, or serialization when they already express the requirement clearly; introduce a new mechanism when the problem itself warrants a durable new concept.
  • Do not generalize a one-off problem by default. Generalize when multiple real callers, implementations, lifecycle paths, or an enduring boundary make the broader form useful on its own.
  • Tests protect stable public behavior, protocol and security invariants, and real lifecycle E2E behavior.
  • Keep a regression test when the regression reveals a contract or invariant that remains important.
  • Do not test incidental implementation details such as call sequence, log output, retry count, or file metadata unless they are themselves part of a stable contract.
  • When a refactor makes an implementation-coupled test obsolete, delete it if no enduring behavior or invariant would be left unprotected.
  • Prefer deterministic unit tests at the lowest coherent owner, or real black-box E2E tests in e2e/; do not add middle-layer tests that assemble several subsystems with fake transports or callbacks to inspect internal state.
  • Never add a production callback, interface, config knob, wrapper, synchronization primitive, or injection seam only to make a test possible.
  • When a regression crosses components, protect the enduring invariant in its lowest owner; otherwise assert the real behavior in e2e/.

Project Principles

  • When caller and callee are both local and no real boundary exists, change both directly; do not preserve local call shapes.
  • If a field, method, wrapper, or abstraction has no clear, current use and does not protect a real boundary, remove it immediately.
  • No wrapper functions or helpers unless they remove real coupling, protect a real boundary, or represent independently meaningful behavior.
  • Prefer changing existing code directly when the change remains local; introduce a new abstraction when the responsibility is substantial enough to deserve an owner of its own.
  • Prefer direct code over layers, facades, and indirection when the extra structure would outgrow the problem it solves.
  • Prefer existing ownership and serialization over adding synchronization unless concurrency itself is part of the problem being modeled.
  • Prefer flattening and merging nearby responsibilities over splitting by default.
  • Remove dead fields, methods, config, and stale state while touching nearby code.
  • Do not duplicate normalization, validation, or defaulting logic; keep it in a single real owner.
  • Keep shared stateless transforms in utils/; keep stateful and domain-shaped logic with the real owner.
  • Keep stable shared contracts, constants, and public paths in types/, not in runtime or helpers.
  • Resolve complexity in the lowest coherent owner and expose only the minimum surface upward.
  • Shared runtime logic must live in one real owner and be reused, not mirrored.
  • Use ADRs sparingly for stable, long-lived architecture or compatibility decisions.
  • Keep ordinary refactors, migrations, rejected approaches, and temporary implementation decisions in issues and pull requests unless they are needed to understand current operational compatibility.
  • Remove stale or superseded documentation that no longer helps explain the current system or its supported compatibility constraints.

Verification

  • CI commands: make vet, make lint, make test.
  • make tidy is local maintenance, not a CI requirement.
  • Run tests only when explicitly requested.
  • If verification seems necessary, ask before running it.

Download now (ZIP)

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. gosuda/portal-tunnel★ 293100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • 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 28,693 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.

  • In this repository2 other files it gives its agents.

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.