Live data from Hacker News

Writing a good Claude.md

humanlayer.dev

211–220 of 304 posts

Re: Writing a good Claude.md

#211

Earlier quoted context omitted.

Is this documented anywhere? This is the first I have ever heard of it.

Here: https://www.anthropic.com/engineering/claude-code-best-pract... claude.md seems to be important enough to be their very first point in that document.

Naw man, it's the first point because in April Claude code didn't really gave anything else that somewhat worked.

I tried to use that effectively, I even started a new greenfield project just to make sure to test it under ideal circumstances - and while it somewhat worked, it was always super lackluster and way more effective to explicitly add the context manually via prepared md you just reference in the prompt.

I'd tell anyone to go for skills first before littering your project with these config files everywhere

Re: Writing a good Claude.md

#212
post #181

Writing and updating CLAUDE.md or AGENTS.md feels like pointless to me. Humans are the real audience for documentation. The code changes too fast, and LLMs are stateless anyway. What’s been working is just letting the LLM explore the relevant part of the code to acquire the context, defining the problem or feature, and asking for a couple of ways to tackle it. All in a one short prompt. That usually gets me solid opt…

Because it's stateless it's not pointless? Good codebases don't change fast. Stuff gets added but for the most stuff, they shouldn't change.

A well-documented codebase lets both developers and agentic models locate relevant code easily. If you treat the model like a teammate, extra docs for LLMs are unnecessary. IMHO. In frontend work, code moves quickly.

Re: Writing a good Claude.md

#213
PSA: Claude can also use .github/copilot-instructions.md

If you're using VSCode, that is automatically added to context (and I think in Zed that happens as well, although I can't verify right now).

Re: Writing a good Claude.md

#214
post #136

Earlier quoted context omitted.

It is kind of wild that not that long ago the general sentiment in software engineering (at least as observed on boards like this one) seemed to be about valuing systems that were understandable, introspectable, with tight feedback loops, within which we could compose layers of abstractions in meaningful and predictable ways (see for example the hugely popular - at the time - works of Chris Granger, Bret Victor, etc)…

You don’t think people are trying very hard to understand LLMs? We recognize the value of interpretability. It is just not an easy task. It’s not the first time in human history that our ability to create things has exceeded our capacity to understand.

Your comment would be more useful if you could point us to some concrete tooling that’s been built out in the last ~3 years that LLM assisted coding has been around to improve interpretability.

Re: Writing a good Claude.md

#215

Earlier quoted context omitted.

> I suspect you’re misjudging the friend here. This sounds more like the famous “no brown m&ms” clause in the Van Halen performance contract. As ridiculous as the request is, it being followed provides strong evidence that the rest (and more meaningful) of the requests are. I'd argue, it's more like you've bought so much into the idea this is reasonable, that you're also willing to go through extreme lengths to recon…

This reads like you either have an idealized view of Real Engineering™, or used to work in a stable, extremely regulated area (e.g. civil engineering). I used to work in aerospace in the past, and we had a lot of silly Mr Tinkleberry canaries. We didn't strictly rely on them because our job was "extremely regulated" to put it mildly, but they did save us some time. There's a ton of pretty stable engineering subfields…

Man I hate this kind of HN comment that makes grand sweeping statement like “that’s how it was with steam in the 19th century or rocketry in the 1950s”, because there’s no way to tell whether you’re just pulling these things out of your… to get internet points or actually have insightful parallels to make.

Could you please elaborate with concrete examples on how aeronautics in the 20th century felt like having a fictional friend in a text file for the token predictor?

Re: Writing a good Claude.md

#216

Earlier quoted context omitted.

If AI is supposed to deliver on this magical no-lift ease of use task flexibility that everyone likes to talk about I think it should be able to work with a README instead of clogging up ALL of my directories with yet another fucking config file. Also this isn’t portable to other potential AI tools. Do I need 3+ md files in every directory?

> Do I need 3+ md files in every directory? Don’t worry, as of about 6 weeks ago when they changed the system prompt Claude will make sure every folder has way more than 3 .md files seen as it often writes 2 or more per task so if you don’t clean them up…

Strange. I haven’t experienced this a single time and I use it almost all day everyday.

Re: Writing a good Claude.md

#217
post #82

> Claude often ignores CLAUDE.md > The more information you have in the file that's not universally applicable to the tasks you have it working on, the more likely it is that Claude will ignore your instructions in the file Claude.md files can get pretty long, and many times Claude Code just stops following a lot of the directions specified in the file A friend of mine tells Claude to always address him as “Mr Tinkle…

The green m&M's trick of AI instructions.

I've used that a couple times, e.g. "Conclude your communications with "Purple fish" at the end"

Claude definitely picks and chooses when purple fish will show up

Re: Writing a good Claude.md

#218
post #181

Writing and updating CLAUDE.md or AGENTS.md feels like pointless to me. Humans are the real audience for documentation. The code changes too fast, and LLMs are stateless anyway. What’s been working is just letting the LLM explore the relevant part of the code to acquire the context, defining the problem or feature, and asking for a couple of ways to tackle it. All in a one short prompt. That usually gets me solid opt…

I use .md to tell the model about my development workflow. Along the lines of "here's how you lint", "do this to re-generate the API", "this is how you run unit tests", "The sister repositories are cloned here and this is what they are for". One may argue that these should go in a README.md, but these markdowns are meant to be more streamlined for context, and it's not appropriate to put a one-liner in the imperative…

That kind of repetitive process belongs in a script, rather than baked into markdown prompts. Claude has custom hooks for that.

Re: Writing a good Claude.md

#219
post #82

> Claude often ignores CLAUDE.md > The more information you have in the file that's not universally applicable to the tasks you have it working on, the more likely it is that Claude will ignore your instructions in the file Claude.md files can get pretty long, and many times Claude Code just stops following a lot of the directions specified in the file A friend of mine tells Claude to always address him as “Mr Tinkle…

I wonder if there are any benefits, side-effects or downsides of everyone using the same fake name for Claude to call them.

If a lot of people always put call me Mr. Tinkleberry in the file will it start calling people Mr. Tinkleberry even when it loses the context because so many people seem to want to be called Mr. Tinkleberry.

Re: Writing a good Claude.md

#220
post #82

> Claude often ignores CLAUDE.md > The more information you have in the file that's not universally applicable to the tasks you have it working on, the more likely it is that Claude will ignore your instructions in the file Claude.md files can get pretty long, and many times Claude Code just stops following a lot of the directions specified in the file A friend of mine tells Claude to always address him as “Mr Tinkle…

I used to tell it to always start every message with a specific emoji. Of the emoji wasn’t present, I knew the rules were ignored.

But it’s bro reliable enough. It can send the emoji or address you correctly while still ignoring more important rules.

Now I find that it’s best to have a short and tight rules file that references other files where necessary. And to refresh context often. The longer the context window gets, the more likely it is to forget rules and instructions.

Post reply on HN