Live data from Hacker News

AGENTS.md – Open format for guiding coding agents

agents.md

141–150 of 398 posts

Re: AGENTS.md – Open format for guiding coding agents

#141

Yet every agent I use (Claude Code, Gemini and Aider) uses their own custom filename. It would be nice if it was standardized. Right now I’m using ruler to automate generating these files for all standards as a necessary evil, but I don’t envision this problem being solved soon. Especially because these coding agents also use different styles for consuming MCP configs. https://github.com/intellectronica/ruler

My (slightly cynical) take is that they're trying to create whatever vendor lock-in they can, so standardization feels hits a bit too close to commoditization

Re: AGENTS.md – Open format for guiding coding agents

#142
post #140

Earlier quoted context omitted.

There shouldn't be anything stopping you from doing that. You can just use the AGENTS.md file as an index pointing to other doc files. This example does that - https://github.com/apache/airflow/blob/main/AGENTS.md

The point is that .agents is a hidden file while AGENTS.md is in your face like a README intended for humans. Having an in-your-face file that links to a hidden file serves no purpose.

I don't see the point of having it hidden though. Having it "in your face" means you can actively tune it yourself, or using the LLM itself.

Re: AGENTS.md – Open format for guiding coding agents

#143

Earlier quoted context omitted.

It is. README is for humans, AGENTS / etc is for LLMs. Document how to use and install your tool in the readme. Document how to compile, test, architecture decisions, coding standards, repository structure etc in the agents doc.

Compile, test, architecture would be very welcome in the readme too Id wager

Where contributors are the audience, yes. For things like libraries, I care about those things only if I run into a bug, and have enough resources to attempt a fix.

Re: AGENTS.md – Open format for guiding coding agents

#144

Earlier quoted context omitted.

I suspect machine readable practices will become standard as AI is incorporated more into society. A good example is autonomous driving and local laws / context. "No turn on red. School days 7am-9am". So you need: where am I, when are school days for this specific school, and what datetime it is. You could attempt to gather that through search. Though more realistically I think the municipality will make the laws req…

Those particular signs are just stupid. The street should be redesigned with traffic calming, narrowing and chicanes so that speeding is not possible. Slapping on a sign is ineffective

Completely agree

Re: AGENTS.md – Open format for guiding coding agents

#145

Earlier quoted context omitted.

You're going to include specific coding style rules in your README? Or other really agent-specific things like guidance about spawning sub-agents? They are separate for a good reason. My CLAUDE.md and README.md look very different.

Why would you publish agent specific things to your codebase? That's personal preference and doesn't have anything to do with the project.

It should not contain personal preference. It should contain project conventions.

Project guidelines, how to build your project, where to find or implement different types of features, are not personal preference. If different members of your team disagree on these things, that is a problem.

Re: AGENTS.md – Open format for guiding coding agents

#146
what about for plan.md, does everyone just trash the plan once the development is done ? Sometimes the final generated plans (created after iterating with the model on it) are as good as design documents and can be useful for future enhancements, so trashing them doesn't feel right, whereas checking them in seems like too many non code related files in every directory

Re: AGENTS.md – Open format for guiding coding agents

#147

This should've been an .agents¹ with an index.md. For tiny, throwaway projects, a monolithic .md file is fine. A folder allows more complex projects to use "just enough hierarchy" to provide structure, with index.md as the entry point. Along with top-level universal guidance, it can include an organization guide (easily maintained with the help of LLMs). index.md ├── auth.md ├── performance.md ├── code_quality ├── da…

Anti-feature if you ask me. An agent should be able to pick the stuff it needs from the AGENTS.md, and not blindly use everything.

Re: AGENTS.md – Open format for guiding coding agents

#148

Earlier quoted context omitted.

Except not hidden. Why do people want to hide important files and directories? Particularly documentation? Tradition, I guess, but it's an antipattern that makes everything more opaque. Maybe robot_docs?

It's so it doesn't clash with any project that actually has a functional `agents/` directory

Another reason to use a src/ directory for the actual source code.

Re: AGENTS.md – Open format for guiding coding agents

#149
post #102
post #40

Earlier quoted context omitted.

The limited self-driving cars, with a remote human operator? no, I never have.

This is a rather dismissive response considering the progress they’ve made over the past few years. The other commenter is correct that they use highly detailed maps but you are incorrect as they do not have a remote human operator. I find them more enjoyable than Uber. They’ve already surpassed Lyft in SF ridership and soon they will take the crown from Uber.

you are incorrect as they do not have a remote human operator

Yes, they do, the term to search is “remote assistance operator”. e.g. https://philkoopman.substack.com/p/all-robotaxis-have-remote...

Re: AGENTS.md – Open format for guiding coding agents

#150

I am developing a coding agent that currently manages and indexes over 5,000 repositories. The agent's state is stored locally in a hidden `.agent` directory, which contains a configuration folder for different agent roles and their specific instructions. Then we've a "agents" folder with multiple files, each file has Agent only reads the file if its role is defined there. Inside project directory, we've a dot folder…

To add further to your idea:

You can create a hierarchy of summaries. The idea being summaries can exist at the method level, class level and the microservice or module level. Each layer of summary points to its child layers and leaf nodes are code themselves. I think it can be a B tree or a normal tree.

The RAG agent can traverse as deep as needed for the particular semantic query. Each level maintains semantic understanding of the layer beneath it but as a tradeoff it loses a lot of information and keeps only what is necessary.

This will work if the abstractions in the codebase are done nicely - abstractions are only useful if they actually hide implementation details. If your abstractions are good enough, you can afford to keep only the higher layers (as required) in your model context. But if it’s not good, you might even have to put actual code in it.

For instance a method like add(n1, n2) is a strong abstraction - I don’t need to know its implementation but only semantic meaning at this level.

But in real life methods don’t always do one thing - there’s logging, global caches etc.

Post reply on HN