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

161–170 of 312 posts

Re: Anatomy of the .claude/ folder

#161

Post by thisrobot »

dewey wrote: post #132

Building your AI agent "toolkit" is becoming the equivalent of the perfect "productivity" setup where you spend your time reading blog posts, watching YouTube videos telling you how to be productive and creating habits and rituals...only to be overtaken by a person with a simple paper list of tasks that they work through. Plain Claude, ask it to write a plan, review plan, then tell it to execute still works the best…

This resonates with me. Sometimes I build up some artifacts within the context of a task, but these almost always get thrown away. There are primarily three reason I prefer a vanilla setup.

1. I have many and sometimes contradictory workflows: exploration, prototyping, bug fixing debugging, feature work, pr management, etc. When I'm prototyping, I want reward hacking, I don't care about tests or lint's, and it's the exact opposite when I manage prs.

2. I see hard to explain and quantify problems with over configuration. The quality goes down, it loses track faster, it gets caught in loops. This is totally anecdotal, but I've seen it across a number of projects. My hypothesis is that is related to attention, specifically since these get added to the system prompt, they pull the distribution by constantly being attended to.

3. The models keep getting better. Similar to 2, sometime model gains are canceled out by previously necessary instructions. I hear the anthropic folks clear their claude.md every 30 days or so to alleviate this.

Re: Anatomy of the .claude/ folder

#162

Post by rafaelmn »

It's shocking how shitty claude code CLI app is - config is brittle shit (setting up a plugin LSP is searching through GitHub issues and guessing which parameters you messed up), hooks render errors in the app when there are none and the permission harness is barely documented, zero customization options (would you like the agent config come from a different folder than source root ? nope). Going through gihub issues, same issue you hit has been open since beginning of 2025 and ignored - their issues are /dev/null - it's basically a user forum.

Re: Anatomy of the .claude/ folder

#164

Post by lanthissa »

dewey wrote: post #132

Building your AI agent "toolkit" is becoming the equivalent of the perfect "productivity" setup where you spend your time reading blog posts, watching YouTube videos telling you how to be productive and creating habits and rituals...only to be overtaken by a person with a simple paper list of tasks that they work through. Plain Claude, ask it to write a plan, review plan, then tell it to execute still works the best…

its not though if you're working in a massive codebase or on a distributed system that has many interconnected parts.

skills that teach the agent how to pipe data, build requests, trace them through a system and datasources, then update code based on those results are a step function improvement in development.

ai has fundamentally changed how productive i am working on a 10m line codebase, and i'd guess less than 5% of that is due to code gen thats intended to go to prod. Nearly all of it is the ability to rapidly build tools and toolchains to test and verify what i'm doing.

Re: Anatomy of the .claude/ folder

#165

Post by Fishkins »

gawa wrote: post #73
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

The part about permissions with settings.json [0] is laughable. Are we really supposed to list all potential variations of harmful commands? In addition to the `Bash(cat ./.env)`, we would also need to add `Bash(cat .env)`, Bash(tail ./.env)`, Bash(tail .env)`, `Bash(head ./.env)`, `Bash(sed '' ./.env)`, and countless others... while at the same time we allow something like `npm` to run? I know the deny list is only…

> The part about permissions with settings.json [0] is laughable

I never said "permissions", I said "sandboxing". You can configure that in settings.json.

https://code.claude.com/docs/en/sandboxing#configure-sandbox...

Re: Anatomy of the .claude/ folder

#166

Post by Fishkins »

kseniamorph wrote: post #128
arcanemachiner wrote: post #112

Earlier quoted context omitted.

That's not a sandbox.

there is a real one though — https://www.anthropic.com/engineering/claude-code-sandboxing . needs to be enabled with /sandbox, not on by default.

Right, that's what I was referring to

Re: Anatomy of the .claude/ folder

#168

Post by dotancohen »

wilkystyle wrote: post #137
pfortuny wrote: post #133

Earlier quoted context omitted.

Emacs init file bikeshedding comes to mind…

but now you can build your AI agent toolkit to work on your init file for you

My init.el file went from some 300 lines to under 50 with Claude's assistance. Some of that had to do with updating Emacs, but I really only use Emacs for Org mode so that contribution was minimal.

Re: Anatomy of the .claude/ folder

#169

Post by chrisweekly »

dataviz1000 wrote: post #87

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 e…

Great link, thanks for sharing! Read and bookmarked it.

TLDR "CLAUDE.md isn't documentation for Claude to read - it's an operating system for Claude to run. Define behavior, delegate knowledge to skills, and build a system that improves itself over time."

Re: Anatomy of the .claude/ folder

#170

Post by sillysaurusx »

lanthissa wrote: post #164
dewey wrote: post #132

Building your AI agent "toolkit" is becoming the equivalent of the perfect "productivity" setup where you spend your time reading blog posts, watching YouTube videos telling you how to be productive and creating habits and rituals...only to be overtaken by a person with a simple paper list of tasks that they work through. Plain Claude, ask it to write a plan, review plan, then tell it to execute still works the best…

its not though if you're working in a massive codebase or on a distributed system that has many interconnected parts. skills that teach the agent how to pipe data, build requests, trace them through a system and datasources, then update code based on those results are a step function improvement in development. ai has fundamentally changed how productive i am working on a 10m line codebase, and i'd guess less than 5%…

But... plain Claude does that. At least for my codebase, which is nowhere close to your 10m line. But we do processing on lots of data (~100TB) and Claude definitely builds one-off tools and scripts to analyze it, which works pretty great in my experience.

What sort of skills are you referring to?

Post reply on HN