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

211–220 of 312 posts

Re: Anatomy of the .claude/ folder

#211

Post by chatmasta »

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…

On your first point, one unexpected side effect I’ve noticed is that in an effort to offload my thinking to an agent, I often end up just doing the thinking myself. It’s a surprisingly effective antidote to writer’s block… a similar effect to journaling, and a good reason why people feel weird about sharing their prompts.

Re: Anatomy of the .claude/ folder

#213

Post by nzoschke »

chatmasta wrote: post #195
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…

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…

The best thing you can do is help build and maintain high quality docs.

Great docs help you, your agents, your team and your customers.

If you’re confused and the agent can’t figure it out reliably how can anyone?

Easier said than done of course. And harder now than ever if the products are rapidly changing from agentic coding too.

One of my only universal AGENTS.md rules is:

> Write the pull request title and description as customer facing release notes.

Re: Anatomy of the .claude/ folder

#214

Post by kccqzy »

JohnMakin wrote: post #127
dance2die wrote: post #124

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 Ignore original comment below, as the post is technical so is the parent comment: for techies --- That applies to tech users only. Non-tech users starting to use Claude code and won't care to get the job done Claude introduced skills is to bring more non-tech users to CLI as a good way to get your feet we…

what? non techies are most at risk. There are a huge number of malicious skills. Not knowing or caring how to spot malicious behavior doesn’t mean someone shouldn’t be concerned about it, no matter how much they can’t or don’t want to do it. I am an adminstrator of this stuff at my company and it’s an absolute effing nightmare devising policies that protect people from themselves. If I heard this come out of someone’…

My company simply bans Claude code for all non-technical users. They can only use the chatbot from the web UI.

Re: Anatomy of the .claude/ folder

#215

Post by nzoschke »

bonoboTP wrote: post #160
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.

2 months ago I built (with Claude) a quite advanced Python CLI script and Claude Skill that searches and filters the Claude logs to access information from other sessions or from the same session before context compaction. But today Claude Code has a builtin feature to search its logs and will readily do it when needed. My point is, these custom things are often short lived band-aids, and may not be needed with bette…

This is very insightful thanks for sharing.

I’ve been developing and working on dev tools for more than 15 years. I’ve never seen things evolve so rapidly.

Experiment, have fun and get things done, but don’t get too sure or attached to your patches.

It’s very likely the models and harnesses will keep improving around the gaps you see.

I’ve seen most of my AGENTS.md directives and custom tools fade away too, as the agents get better and better at reading the code and running the tests and feeding back on themselves.

Re: Anatomy of the .claude/ folder

#216

Post by nzoschke »

sornaensis wrote: post #139

I've been going heavily in the direction of globally configured MCP servers and composite agents with copilot, and just making my own MCP servers in most cases. Then all I have to do is let the agents actually figure out how to accomplish what I ask of them, with the highly scoped set of tools and sub agents I give them. I find this works phenomenally, because all the .agent.md file is, is a description of what the t…

I’ve had success with this general approach too.

The best thing I’ve done so far is put GitHub behind an API proxy and reject pushes and pull requests that don’t meet a criteria, plus a descriptive error.

I find it forgets to read or follow skills a lot of the time, but it does always try to route around HTTP 400s when pushing up its work.

Re: Anatomy of the .claude/ folder

#217

Post by chatmasta »

nzoschke wrote: post #213
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…

The best thing you can do is help build and maintain high quality docs. Great docs help you, your agents, your team and your customers. If you’re confused and the agent can’t figure it out reliably how can anyone? Easier said than done of course. And harder now than ever if the products are rapidly changing from agentic coding too. One of my only universal AGENTS.md rules is: > Write the pull request title and descri…

I’ve been thinking about this a lot. It’s obviously the ideal state of things. The challenge is that we’ve got existing docs frameworks and teams and inertia and unreleased features… and I don’t have time to wait for that when I’m trying to get something done today. Not to mention the trade off of writing in public vs. private.

One quick win I’ve thought could bridge this is updating our docs site to respond to `Accept: text/markdown` requests with the markdown version of the docs.

Re: Anatomy of the .claude/ folder

#218

Post by smj-edison »

gck1 wrote: post #108
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.

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?

Re: Anatomy of the .claude/ folder

#219

Post by pdantix »

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…

at work i've spent some time setting up our claude.md files and curated the .claude directory with relevant tools such as linear, figma, sentry, LSP, browser testing. sensible stuff anyone using these tools would want, it all works pretty well.

my only machine-specific config is overriding haiku usage with sonnet in claude code. i outline what i want in linear, have claude synthesize into a plan and we iterate until we're both happy, then i let it rip. works great.

then one of my juniors goes and loads up things like "superpowers" and all sorts of stuff that's started littering his PRs. i'm just not convinced this ricing of agents materially improves anything.

Re: Anatomy of the .claude/ folder

#220

Post by ijustlovemath »

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

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.
Post reply on HN