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

301–310 of 312 posts

Re: Anatomy of the .claude/ folder

#301

Post by Leynos »

stingraycharles wrote: post #252
Leynos wrote: post #250

Earlier quoted context omitted.

Use evals Coming soon, unit, behavioural and regression tests for your prompts and skills :P

How do you use evals when you’re using Claude Code, given that Claude Code also changes their prompts all the time? You’ll have: * Claude model version * Claude Code prompts and tools * Your own prompts and skills and whatnot * Your repository’s source code (= the input) All of those change constantly, it’s not like it’s some kind of SWE benchmark.

You just said it. If consistency is that important, keep consistent versions of model, harness, prompts, skills, etc., and regression test changes. That way lies madness :)

Re: Anatomy of the .claude/ folder

#302

Post by suttontom »

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.

How odd, are you under the impression that LLMs have self-awareness or understand their own internal mechanisms? Do you know that you can tell an LLM almost anything and, absent a tool, it will tell you that you're correct? By your logic, why do we even experiment with skills, planning modes, harnesses, etc. when we could just ask the model what the best way to get it to produce information is?

Re: Anatomy of the .claude/ folder

#303

Post by bisonbear »

nunez wrote: post #234
bisonbear wrote: post #144

Earlier quoted context omitted.

I'm also thinking on how we can put guardrails on Claude - but more around context changes. For example, if you go and change AGENTS.md, that affects every dev in the repo. How do we make sure that the change they made is actually beneficial? and thinking further, how do we check that it works on every tool/model used by devs in the repo? does the change stay stable over time?

Given the scope that AGENTS has, I would use PRs to test those changes and discuss them like any other large-impact area of the codebase (like configs). If you wanted to be more “corporate” about it, then assuming that devs are using some enterprise wrapper around Claude or whatever, I would bake an instruction into the system prompt that ensures that AGENTS is only read from the main branch to force this convention.…

PRs for AGENTS.md are necessary, but not sufficient, exactly because of non-determinism. You can LGTM the AGENTS.md change, but it's so hard to know what downstream behavioral effects it has. I feel like the only way to really know is by building a benchmark on your repo, and actually A/B testing the AGENTS.md change. I'm building something in the space - happy to share if it's something that sounds interesting to you

Re: Anatomy of the .claude/ folder

#304

Post by nsvd2 »

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 come to the point where, if the agent makes a wrong assumption about the code base with fresh context, I consider that the code is not obvious enough about it's intent.

Re: Anatomy of the .claude/ folder

#305

Post by nsvd2 »

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…

I usually relegate the agent to code, I do the git part/put the patch together. Git is an excellent tool to review the changes granularly and find potential weaknesses.

Re: Anatomy of the .claude/ folder

#306

Post by ccosky »

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?

Anytime I do something as a one-off that I know I'll do in the future, at the end of the session I'll ask Claude to write a new skill based on what it did. For instance, I had to run some queries on Azure to check the logs for certain output and for the frequency of output. Did it once in a session and then had it write the skill for it. Now I can just run the skill whenever I need that data and it pulls it for me.

Re: Anatomy of the .claude/ folder

#307

Post by tern »

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…

Ah, thanks so much for this question. I ended up building a tool that agent can use to track 'compounding' in my corpus of .markdown files. Keep iterating and thinking about it, and you may find you can do the same for your process.

Re: Anatomy of the .claude/ folder

#308

Post by abustamam »

theshrike79 wrote: post #300
abustamam wrote: post #288

Earlier quoted context omitted.

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.

Nice, congrats! A former boss once told me that over communication never hurt anyone. Of course there are ways to fine-tune and get the point across more succinctly but I think the point still stands - err on the side of over than under communication.

Re: Anatomy of the .claude/ folder

#309

Post by abustamam »

dotancohen wrote: post #276
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.

This sounds great - skills to ensure that the code maintains proper separation of concerns and is packaged properly. I'd love to know how this skill was phased.

Honestly I started with Obra superpowers and worked with my boss to brainstorm the best way to keep separation of concerns, and we just stepped on rakes as we developed and had Obra superpowers suggest updates to our rules/skills.

It's certainly an iterative process but it gets better every iteration.

Re: Anatomy of the .claude/ folder

#310

Post by gffrd »

obsidianbases1 wrote: post #135
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…

Lots of money being made by luring people into this trap. The reality is that if you actually know what you want, and can communicate it well (where the productivity app can be helpful), then you can do a lot with AI. My experience is that most people don't actually know what they want. Or they don't understand what goes into what they want. Asking for a plan is a shortcut to gaining that understanding.

> My experience is that most people don't actually know what they want. Or they don't understand what goes into what they want.

1000%. This is why people whose job it was to figure out how to make a thing are thriving with AI tools, and those who operate in the conceptual/abstract are flailing and frustrated with it. (it really is a mirror in this case, and the frustration they have is unknowingly directed at themselves)

Post reply on HN