Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a good Claude.md

humanlayer.dev

Post reply on HN
Print view View original

101–110 of 304 posts

Re: Writing a good Claude.md

#101

Post by girvo »

wredcoll wrote: post #39
serial_dev wrote: post #20

I’m sure I’m just working like a caveman, but I simply highlight the relevant code, add it to the chat, and talk to these tools as if they were my colleagues and I’m getting pretty good results. About 12 to 6 months ago this was not the case (with or without .md files), I was getting mainly subpar result, so I’m assuming that the models have improved a lot. Basically, I found that they not make that much of a differe…

How about a list of existing database tables/columns so you don't need to repeat it each time?

I gave it a tool to execute to get that info if required, but it mostly doesn’t need to due to Kysely migration files and the database type definition being enough.

Re: Writing a good Claude.md

#102

Post by girvo »

wredcoll wrote: post #97
HDThoreaun wrote: post #70

Earlier quoted context omitted.

Do you not use a model file for your orm?

ORMs are generally a bad idea, so.. hopefully not?

Even without the explicit magic ORMs, with data mapper style query builders like Kysely and similar, I still find I need to marshall selected rows into objects to, yknow, do things with them in a lot of cases.

Perhaps a function of GraphQL though.

Re: Writing a good Claude.md

#103

Post by stingraycharles »

nico wrote: 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…

That’s hilarious and a great way to test this.

What I’m surprised about is that OP didn’t mention having multiple CLAUDE.md files in each directory, specifically describing the current context / files in there. Eg if you have some database layer and want to document some critical things about that, put it in “src/persistence/CLAUDE.md” instead of the main one.

Claude pulls in those files automatically whenever it tries to read a file in that directory.

I find that to be a very effective technique to leverage CLAUDE.md files and be able to put a lot of content in them, but still keep them focused and avoid context bloat.

Re: Writing a good Claude.md

#104

Post by Zerot »

teiferer wrote: post #53
0xblacklight wrote: post #25

Earlier quoted context omitted.

Hi, post author here :) Yes README.md should still be written for humans and isn’t going away anytime soon. CLAUDE.md is a convention used by claude code, and AGENTS.md is used by other coding agents. Both are intended to be supplemental to the README and are deterministically injected into the agent’s context. It’s a configuration point for the harness, it’s not intended to replace the README. Some of the advice in…

> you shouldn’t use an LLM to do a linter &formatter’s job, Why is that good advice? If that thing is eventually supposed to do the most tricky coding tasks, and already a year ago could have won a medal at the informatics olympics, then why wouldn't it eventually be able to tell if I'm using 2 or 4 spaces and format my code accordingly? Either it's going to change the world, then this is a trivial task, or it's all…

> Why is that good advice? If that thing is eventually supposed to do the most tricky coding tasks, and already a year ago could have won a medal at the informatics olympics, then why wouldn't it eventually be able to tell if I'm using 2 or 4 spaces and format my code accordingly? Either it's going to change the world, then this is a trivial task, or it's all vaporware, then what are we even discussing..

This is the exact reason for the advice: The LLM already is able to follow coding conventions by just looking at the surrounding code which was already included in the context. So by adding your coding conventions to the claude.md, you are just using more context for no gain.

And another reason to not use an agent for linting/formatting(i.e. prompting to "format this code for me") is that dedicated linters/formatters are faster and only take maybe a single cent of electricity to run whereas using an LLM to do that job will cost multiple dollars if not more.

Re: Writing a good Claude.md

#105

Post by wredcoll »

girvo wrote: post #102
wredcoll wrote: post #97

Earlier quoted context omitted.

ORMs are generally a bad idea, so.. hopefully not?

Even without the explicit magic ORMs, with data mapper style query builders like Kysely and similar, I still find I need to marshall selected rows into objects to, yknow, do things with them in a lot of cases. Perhaps a function of GraphQL though.

Sure, but that's not the same thing. For example, whether or not you have to redeclare your entire database schema in a custom ORM language in a different repo.

Re: Writing a good Claude.md

#106

Post by bryanhogan »

I've been very satisfied with creating a short AGENTS.md file with the project basics, and then also including references to where to find more information / context, like a /context folder that has markdown files such as app-description.md.

Re: Writing a good Claude.md

#107

Post by gitgud »

bastawhiz wrote: post #22
_pdp_ wrote: post #13

There is far much easier way to do this and one that is perfectly aligned with how these tools work. It is called documenting your code! Just write what this file is supposed to do in a clear concise way. It acts as a prompt, it provides much needed context specific to the file and it is used only when necessary. Another tip is to add README.md files where possible and where it helps. What is this folder for? Nobody…

This is missing the point. If I want to instruct Claude to never write a database query that doesn't hit a preexisting index, where exactly am I supposed to document that? You can either choose: 1. A centralized location, like a README (congrats, you've just invented CLAUDE.md) 2. You add a docs folder (congrats, you've just done exactly what the author suggests under Progressive Disclosure) Moreover, you can't just…

> 1. A centralized location, like a README (congrats, you've just invented CLAUDE.md)

README files are not a new concept, and have been used in software for like 5 decades now, whereas CLAUDE.md files were invented 12 months ago...

Re: Writing a good Claude.md

#108

Post by Zerot »

brcmthrowaway wrote: post #90

Is CLAUDE.md required when claude has a --continue option?

I would recommend using it, yeah. You have limited context and it will be compacted/summarized occasionally. The compaction/summary will lose some information and it is easy for it to forget certain instructions you gave it. Afaik claude.md will be loaded into the context on every compaction which allows you to use it for instructions that should always be included in the context.

Re: Writing a good Claude.md

#109

Post by dimitri-vs »

vunderba wrote: post #41

From the article: > We recommend keeping task-specific instructions in separate markdown files with self-descriptive names somewhere in your project. Then, in your CLAUDE.md file, you can include a list of these files with a brief description of each, and instruct Claude to decide which (if any) are relevant and to read them before it starts working. I've been doing this since the early days of agentic coding though…

Correct me if I'm wrong but I think the new "skillss are exactly this, but better.

Re: Writing a good Claude.md

#110

Post by 0xblacklight »

acedTrex wrote: post #48

"Here's how to use the slop machine better" is such a ridiculous pretense for a blog or article. You simply write a sentence and it approximates it. That is hardly worth any literature being written as it is so self obvious.

This is an excellent point - LLMs are autoregressive next-token predictors, and output token quality is a function of input token quality

Consider that if the only code you get out of the autoregressive token prediction machine is slop, that this indicates more about the quality of your code than the quality of the autoregressive token prediction machine

Post reply on HN