agentleFS
di-sukharevdi-sukharev/opencommit/AGENTS.md

opencommit

AGENTS.md7.5k starsChanged 7 months agoMITView on GitHub

The user decides product behavior. Choose the implementation and checks yourself. Ask about unresolved product choices. A request authorizes its scope. Reviews and questions do not authorize edits. Use the user's language in conversation, product documents, and tasks. Write technical documents and agent instructions in English. Follow ASD-STE100: short sentences, active voice, and consistent terms. Keep business rules in their owning modules. Modules call other modules through their public API. Correct shared defects where the wrong result originates. Do not…

Trending

Quiet since August.about the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 1 mentionMar 2026: 1 mentionApr 2026: 1 mentionMay 2026: 1 mentionJun 2026: 0 mentionsJul 2026: 1 mentionAug 2026: 1 mentionSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the di-sukharev/opencommit repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about di-sukharev/opencommit

The biggest 5 of 27 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 27

Talked about on GitHub, Bluesky and Hacker News (27 times).

On GitHub · 23

18 more on GitHub
  • 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,439 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

8 rules. About 1 is common, 7 are distinctive, and 0 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use the user's language in conversation, product documents, and tasks.

    line 7
  2. Distinctive:

    Keep business rules in their owning modules.

    line 11
  3. Distinctive:

    Use test-driven development for behavior changes and bug fixes.

    line 19
  4. Distinctive:

    Run relevant checks locally through the project's scripts.

    line 25
  5. Common:

    Ask before destructive actions, spending, new dependencies, or changes to data access.

    line 37
  6. Distinctive:

    Keep temporary files in the system temp directory and delete yours afterward.

    line 39
  7. Distinctive:

    No slop. Write clear, declarative code.

    line 47
  8. Distinctive:

    Write as if you will maintain this code for the next 10 years.

    line 49

≈ “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.

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

AGENTS.md

Working agreement

The user decides product behavior. Choose the implementation and checks yourself. Ask about unresolved product choices. A request authorizes its scope. Reviews and questions do not authorize edits.

Use the user's language in conversation, product documents, and tasks. Write technical documents and agent instructions in English. Follow ASD-STE100: short sentences, active voice, and consistent terms.

Implementation

Keep business rules in their owning modules. Modules call other modules through their public API. Correct shared defects where the wrong result originates. Do not add a workaround in each caller. Change generated files through their source and generator.

UI

Use the existing design system. Product components own colors, typography, padding, borders, and radius. Use theme tokens. Parents control placement through wrappers and gaps. Do not pass className or style into product components. Preserve keyboard and focus behavior. Show loading, empty, error, and success states for real data.

Tests and TDD

Use test-driven development for behavior changes and bug fixes. Confirm the expected failure, implement the change, then refactor while tests pass. Copy and styling changes need no test-first development.

Prefer integration tests through real application or core interfaces. Keep internal modules and test databases real. Replace external providers with test doubles. Add unit tests only for cases that integration tests cannot cover efficiently. Do not duplicate coverage or assert UI wording, CSS, markup, or snapshots.

Verification

Run relevant checks locally through the project's scripts. Do not add cloud CI. Report changes, checks, failures, and required user actions. Never claim a check you did not run.

Interactive browser use requires an explicit request. Run scripted browser checks only as prescribed by project instructions or requested by the user. The user performs the final visual check.

Documentation

Code and configuration are the source of truth. Document only decisions, constraints, and procedures they do not explain. Update the owning document instead of adding guides or repeating instructions. Remove completed setup instructions.

Git and safety

Inspect Git status and remotes before Git operations. Stage, commit, push, change branches or worktrees, or rewrite history only on explicit request. Never stash or discard another person's work. Preserve the existing remote. Do not add AI attribution to commits.

Ask before destructive actions, spending, new dependencies, or changes to data access. A request naming a dependency authorizes it. Never print or commit secrets or personal data. Never weaken security controls.

Keep temporary files in the system temp directory and delete yours afterward. Use your own ports. Stop only processes you started.

Deployment

Deploy only on request through the project's release tools. Follow its deployment guide. Stop for a dirty tree, unpublished source, or an unclear release commit.

Maintenance

No slop. Write clear, declarative code. Prefer the smallest solution that meets the requirement and stays easy to read. Remove code your changes make unused.

Write as if you will maintain this code for the next 10 years. Keep it clean. Take ownership of every module you change and leave it better than you found it.

Download now (ZIP)

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.