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

Anatomy of the .claude/ folder

blog.dailydoseofds.com

Post reply on HN
Print view View original

81–90 of 312 posts

Re: Anatomy of the .claude/ folder

#81

Post by slopinthebag »

SV_BubbleTime wrote: post #49
elcapitan wrote: post #37

Earlier quoted context omitted.

When I see AI images, I skip them, and most likely, the entire article. They're a better warning sign than the ones hidden in the text.

Yeah, I’ve been considering this. They’re going to start removing em dashes, which currently is a surefire way to detect AI text. Let’s say lose those and using emojis as bullet points. It’s going to be a lot harder to detect.

I don't actually look for em dashes or emojis as indicators, I can tell just from a few paragraphs if the pacing and flow is AI slop.

Re: Anatomy of the .claude/ folder

#82

Post by kenforthewin »

sroussey wrote: post #72
Fishkins wrote: post #52

Earlier quoted context omitted.

I agree with most of this, with one important exception: you should have some form of sandboxing in place before running any local AI agent. The easiest way to do that is with .claude/settings.json[0]. This is important no matter how experienced you are, but arguable the most important when you don't know what you're doing. 0: or if you don't want to learn about that, you can use Claude Code Web

Do people really run claude and other clis like this outside a container??

Let's not fool ourselves here. If a security feature adds any amount of friction at all, and there's a simple way to disable it, users will choose to do so.

Re: Anatomy of the .claude/ folder

#83

Post by dgb23 »

saadn92 wrote: post #62

The claim that "whatever you write in CLAUDE.md, Claude will follow" is doing a lot of heavy lifting. In practice CLAUDE.md is a suggestion, not a contract. Complex tasks and compaction will dilute the use of CLAUDE.md, especially once the context window runs out.

This is correct. All of these .md files are just blobs of text that the LLM matches against. They might increase the likelihood of something happening or not happening.

They look to me like people actually want to build deterministic workflows, but blobs of text are the wrong approach for that. The right tool is code that controls the agent through specific states and validates the tool calls step by step.

Re: Anatomy of the .claude/ folder

#84

Post by dhorthy »

dbmikus wrote: post #54
embedding-shape wrote: post #23

Earlier quoted context omitted.

Issue is that both harness and specific model matters a lot in what type of instruction works best, if you were to use Anthrophic's models together with the best way to do prompting with Codex and GPT models, you'd get a lot worse results compared to if you use GPT models with Codex, prompted in the way GPTs react best to them. I don't think people realize exactly how important the specific prompts are, with the same…

Are there any good guides on how to write prompt files tailored to different agents? Would also be interested in examples of a CLAUDE.md file that works well in Claude, but works poorly with Codex.

I think one of the main examples that i saw in a swyx article a while back is that using the sort of ALL CAPS and *IMPORTANT* language that works decently with claude will actually detune the codex models and make them perform worse. I will see if I can find the post

Re: Anatomy of the .claude/ folder

#85

Post by matsemann »

bagrow wrote: post #2

Here's a question that I hope is not too off-topic. Do people find the nano-banana cartoon infographics to be helpful, or distracting? Personally, I'm starting to tire seeing all the little cartoon people and the faux-hand-drawn images. Wouldn't Tufte call this chartjunk?

I never trust them to actually be correct. Aka they're probably worse than useless.

Re: Anatomy of the .claude/ folder

#86

Post by thierrydamiba »

sceptic123 wrote: post #65
jameshart wrote: post #22

Earlier quoted context omitted.

Yes, but as soon as you start checking in and sharing access to a project with other developers these things become shared. Working out how to work on code on your own with agentic support is one thing. Working out how to work on it as a team where each developer is employing agentic tools is a whole different ballgame.

But why is it different? Why does it need to be? I don't write code the same as other devs so why would/should I use AI the same? Is this a hangover from when the tools were not as good?

[dead]

Re: Anatomy of the .claude/ folder

#87

Post by dataviz1000 »

Claude Fast has very good alternate documentation for this. [0] I don't understand the hate for defining .claude/ . It is quite easy to have the main agent write the files. Then rather doing one shot coding, instead iterate quickly updating .claude/ I'm at the point where .claude/ makes copies of itself, performs the task, evaluates, and updates itself. I'm not coding code, I'm coding .claude/ which does everything else. This is also a mechanism for testing .claude, agents, and instructions which would be useful for sharing and reuse in an organization.

[0] https://claudefa.st/blog/guide/mechanics/claude-md-mastery

Re: Anatomy of the .claude/ folder

#88

Post by lucideer »

sceptic123 wrote: post #65
jameshart wrote: post #22

Earlier quoted context omitted.

Yes, but as soon as you start checking in and sharing access to a project with other developers these things become shared. Working out how to work on code on your own with agentic support is one thing. Working out how to work on it as a team where each developer is employing agentic tools is a whole different ballgame.

But why is it different? Why does it need to be? I don't write code the same as other devs so why would/should I use AI the same? Is this a hangover from when the tools were not as good?

I'd see this as being useful for two reasons:

1. Provision of optional tools: I may use an ai agent differently to all other devs on a team, but it seems useful for me to have access to the same set of project-specific commands, skills & MCP configs that my colleagues do. I amn't forced to use them but I can choose to on a case by case basis.

2. Guardrails: it seems sensible to define a small subset of things you want to dissuade everyone's agents from doing to your code. This is like the agentic extension of coding standards.

Re: Anatomy of the .claude/ folder

#89

Post by randusername »

bagrow wrote: post #2

Here's a question that I hope is not too off-topic. Do people find the nano-banana cartoon infographics to be helpful, or distracting? Personally, I'm starting to tire seeing all the little cartoon people and the faux-hand-drawn images. Wouldn't Tufte call this chartjunk?

Tufte is evergreen. Zinsser is another.

> Clutter is the disease of American writing. We are a society strangling in unnecessary words, circular constructions, pompous frills and meaningless jargon.

> Look for the clutter in your writing and prune it ruthlessly. Be grateful for everything you can throw away. Reexamine each sentence you put on paper. Is every word doing new work? Can any thought be expressed with more economy?

On Writing Well (Zinsser)

Re: Anatomy of the .claude/ folder

#90

Post by pgwhalen »

exitb wrote: post #17

I’m seeing this more and more, where people build this artificial wall you supposedly need to climb to try agentic coding. That’s not the right way to start at all. You should start with a fresh .claude, empty AGENTS.md, zero skills and MCP and learn to operate the thing first.

Who is building an artificial wall? Maybe I skimmed the post too fast, but it doesn't seem like this information is being presented as "you have to know/do this before you start agentic engineering", just "this is some stuff to know."
Post reply on HN