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

291–300 of 312 posts

Re: Anatomy of the .claude/ folder

#291

Post by theshrike79 »

EdwardDiego wrote: post #261
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…

I've put some stuff in my global Claude.md to avoid things like... * Claude trying to install packages into my Python system interpreter - (always use uv and venvs) * Claude pushing to main - (don't push to main ever) * When creating a PR, completely ignoring how to contribute (always read CONTRIBUTING.md when creating a PR) * Yellow ANSI text in console output - (Color choices must be visible on both dark and light…

Mine has "always run `task build` before claiming a task as done"

For all of my projects task build runs linters, tests and builds the project with as little output as possible on a happy path.

This catches a bunch of "it's a pre-existing issue" stuff from Claude. Sometimes I ask it to run build first, then start implementing just so that it can prove to itself that no, it wasn't a pre-existing issue, you broke something.

Re: Anatomy of the .claude/ folder

#292

Post by Titled86 »

frizlab wrote: post #69

Completely tangential, but can we please stop putting one million files at the root of the project which have nothing to do with the project? Can we land on a convention like, idk, a `.meta` folder (not the meta company, the actual word), or whatever, in which all of these Claude.md, .swift-version, Code-of-Conduct.md, Codeowners, Contributing.md, .rubocop.yml, .editorconfig, etc. files would go??

you don't like seeing 50 random dot files at the repo root you have to scroll past when trying to get to the readme in GitHub?

Re: Anatomy of the .claude/ folder

#293

Post by krisoft »

soulchild77 wrote: post #247
luisgvv wrote: post #210

Earlier quoted context omitted.

This is why the grill me skill went viral - https://github.com/mattpocock/skills/blob/main/grill-me/SKIL...

I asked Claude whether these elaborate words like "walk down the design tree" actually mean anything to the LLM and make a difference. The answer confirmed my gut feeling: You can just tell me to "be critical" and get mostly the same results. Matt did incredible work teaching people TS, but this feels more like trying to create FOMO to sell snake oil and AI courses.

> I asked Claude […]. The answer confirmed my gut feeling.

And i drawn a tarot card and the card refuted your gut feeling.

Joking asside, there is no reason to suspect that an LLM is telling you correct information about how best to use an LLM. The way to confirm your thesis is by running experiments, or finding someone who has already done them. It is a valid move to use an LLM to find primary sources, but in itself the LLM is not an authority you could or should trust.

Re: Anatomy of the .claude/ folder

#294

Post by braebo »

zwaps wrote: post #244
ijustlovemath wrote: post #220

Earlier quoted context omitted.

Even the most complex distributed systems can be understood with the context windows we have. Short of 1M+ loc, and even then you could use documentation to get a more succinct view of the whole thing.

This really doesn’t pan out in practice if you work a lot with these models And also we know why: effective context depends on inout and task complexity. Our best guess right now is that we are often between 100k to 200k effective context length for frontier, 1m NIHS type models

Agreed, not to mention the m additional cost of chats with more context.

Re: Anatomy of the .claude/ folder

#295

Post by HostingSift »

Nice writeup! Been experimenting a lot with skills, agents and tools like GSD and honestly the biggest lesson for me has been: keep things short and simple.

Not just CLAUDE.md but everything, the prompts you type in a session, skill descriptions, agent configs, all of it. More instructions does not mean better results. Claude actually performs noticeably better with brief focused input. The moment you start over-specifying things quality drops.

Just my observation from using it daily but it's been consistent enough that I figured it's worth sharing.

Re: Anatomy of the .claude/ folder

#296

Post by viktorianer »

tern wrote: post #198
chatmasta wrote: post #195

Earlier quoted context omitted.

All I want is for my agent to save me time, and to become a _compounding_ multiplier for my output. As a PM, I mostly want to use it for demos and prototypes and ideation. And I need it to work with my fractured attention span and saturated meeting schedule, so compounding is critical. I’m still new to this, but the first obvious inefficiency I see is that I’m repeating context between sessions, copying .md files aro…

It's too early. People are trying all of the above. I use all of the above, specifically: - A well-structured folder of markdown files that I constantly garden. Every sub-folder has a README. Every files has metadata in front-matter. I point new sessions at the entry point to this documentation. Constantly run agents that clean up dead references, update out of date information, etc. Build scripts that deterministica…

[flagged]

Re: Anatomy of the .claude/ folder

#297

Post by jasomill »

theshrike79 wrote: post #286
abustamam wrote: post #272

Earlier quoted context omitted.

Much of my time at work is reading through quickly typed messages from my boss and understanding exactly what questions I need to ask in order to make it easy for him to answer clearly. Engineers who lack soft skills cannot be effective in team environments.

Being able (and willing) to write shit down is a superpower among 10x programmers who think "code is self-documenting" and don't even add comments.

RTFM and being able to quickly reduce problems to the simplest possible test case are my superpowers.

To be fair, LLMs can be quite useful for quickly finding the correct place in TFM to look when you don't necessarily have a function or feature name to go on.

Re: Anatomy of the .claude/ folder

#298

Post by abustamam »

pydry wrote: post #287
abustamam wrote: post #273

Earlier quoted context omitted.

At work I use skills to maintain code consistency. We instrumented a solid "model view viewmodel" architecture for a front-end app, because without any guard rails it was doing redundant data fetching and type casts and just messy overall. Having a "mvvm" rule and skill that defines the boundaries keeps the llm from writing a bunch of nonsense code that happens to work.

A deterministic layer linter would be better for this.

Possibly, and we do use linters, but linters don't stop LLMs from going off the rails. It does end up fixing itself because of the linter, but then the results are only as good as the linter itself.

Re: Anatomy of the .claude/ folder

#299

Post by manfre »

smj-edison wrote: post #218
gck1 wrote: post #108

Earlier quoted context omitted.

I'd also go even further and say that you likely should never install ANY skill that you didn't create yourself (i mean, guided claude to create it for you works too), or "forked" an existing one and pulled only what you need. Everyone's workflow is different and nobody knows which workflow is the right one. If you turn your harness into a junk drawer of random skills that get auto updated, you introduce yet another…

I use vanilla Claude Code, and I've never looked that much into skills, so I'm curious: how do you know when it's time to add a new skill?

Create .claude/commands/ when you have well defined repeatable, multi-step actions you want to take. I have a command `/triage` where I provide it a bug report and it asks me questions to start scaffolding a work area, lookup related issues, create patches, etc.

Create .claude/agents/ when you have a narrow scoped thing that you want to happen, but not pollute the main context and have a well formed output. Also handy for reducing costs by using a different model for a class of actions you repeat often. For example, the "lookup related issues" from `/triage` is a Sonnet agent that finds Trac issues for a bug reports. Main context only needs the small list of matches and not the dozens of not relevant ones.

Create .claude/skills/ for job description like behaviors you want. For example, code reviewer or security researcher.

For any of these, install the `/plugin` skill-creator. Run `/init` if you don't have a claude.md and then ask the skill creator to help you improve the claude.md and create useful commands and skills.

Re: Anatomy of the .claude/ folder

#300

Post by theshrike79 »

abustamam wrote: post #288
theshrike79 wrote: post #286

Earlier quoted context omitted.

Being able (and willing) to write shit down is a superpower among 10x programmers who think "code is self-documenting" and don't even add comments.

Haha. I always say that I'm only a good IC not because of my technical skills but because of my communication skills and my willingness to, as Steven Covey says, seek first to understand.

I literally got a transfer to a more exciting position and most likely a raise (discussing it on Tuesday =P) just because I communicated things related to the new position proactively and more than other people who, after the fact, expressed interest in the position.
Post reply on HN