[dead]
Anatomy of the .claude/ folder
221–230 of 312 posts
Re: Anatomy of the .claude/ folder
#222Earlier 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?
I used them for repeated problems or workflows I encounter when running with the default. If I find myself needing to repeat myself about a certain thing a lot, I put it into claude.md. When that gets too big or I want to have detailed token-heavy instructions that are only occasionally needed, I create a skill.
I also import skills or groups of skills like Superpowers (https://github.com/obra/superpowers) when I want to try out someone else's approach to claude code for a while.
Re: Anatomy of the .claude/ folder
#223[dead]
Re: Anatomy of the .claude/ folder
#224I’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.
> empty AGENTS.md, zero skills which is basically every setup because claude sucks at calling skills and forget everything in claude.md with a few seconds.
Right? I laughed when I read this:
>If you tell Claude to always write tests before implementation, it will. If you say “never use console.log for error handling, always use the custom logger module,” it will respect that every time.
It just isn't true lol
Re: Anatomy of the .claude/ folder
#225Feel little like this is generated and not based on experience. Claude.md should be short. Typescript strict mode isnt a gotcha, itll figure that out on its own easily, imo omit things like that. People put far too much stuff in claude, just a few lines and links to docs is all it needs. You can also @Agents.md and put everything there instead. Dont skills supercede commands? Subagents are good esp if you specify mod…
The intro paragraph sounds exactly like Claude’s phrasing. So much so that I couldn’t read the rest of the article because I assumed I could just ask Claude about the topic.
Exactly this. If there is some nuance in the article vs what Claude can tell you, then that's worthwhile. This article is just generated with a specific prompt on style but very little content editing. What's the point? It's like posting the results of a Google search. The prompt would have been more interesting.
It's not against the rules to post AI slop here, and I don't necessarily think it should be. But I do wonder how we value written content going forward. There's value to taste and style and editing and all the other human things... there's very little value in the actual words themselves. We'll figure it out.
Re: Anatomy of the .claude/ folder
#226Earlier 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?
You observe what it does to accomplish a particular task, and note any instances where it:
1. Had to consume context and turns by reading files, searching web, running several commands for what was otherwise a straightforward task
2. Whatever tool it used wasn't designed with agent usage in mind. Which most of the time will mean agent has to do tail, head, grep on the output by re-running the same command.
Then you create a skill that teaches how to do this in fewer turns, possibly even adding custom scripts it can use as part of that skill.
You almost never need a skill per se, most models will figure things out themselves eventually, skill is usually just an optimization technique.
Apart from this, you can also use it to teach your own protocols and conventions. For example, I have skills that teach Claude, Codex, Gemini how to communicate between themselves using tmux with some helper scripts. And then another skill that tell it to do a code review using two models from two providers, synthesize findings from both and flag anything that both reported.
Although, I have abandoned the built-in skill system completely, instead using my own tmux wrapper that injects them using predefined triggers, but this is stepping into more advanced territory. Built in skill system will serve you well initially, and since skills are nothing but markdown files + maybe some scripts, you can migrate them easily into whatever you want later.
Re: Anatomy of the .claude/ folder
#227[flagged]
Re: Anatomy of the .claude/ folder
#228[flagged]
Re: Anatomy of the .claude/ folder
#229Earlier 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’…
I run a small local non-profit which is essentially security hardening guide with some helper tooling that simplifies some concepts for non-techies (FDE, MFA, password managers etc).
LLMs have completely killed my motivation to continue running it. None of standard practices apply anymore
Re: Anatomy of the .claude/ folder
#230Earlier 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 had an issue with playwright MCP where only one Claude Code instance could be using it at a time, so I switched to Claude's built-in /chrome MCP. In practice, I also find it more useful that the Chrome MCP uses my current profile since I might want Claude to look at some page I'm already logged in to. I'm not very sophisticated here though. I mainly use use browser MCP to get around the fact that 30% of servers blo…
Would love if there is a way to parallelize playwright mcp using multiple agents and such, but it seems it's a fundamental limitation of that MCP that only on instance/tab can be controlled.
Chrome MCP is much slower and by default pretty much unusable because Claude seems to prefer to read state from screenshots. Also, no Firefox/Safari support means no cross-browser testing.
There appears to be https://github.com/sumyapp/playwright-parallel-mcp which may be worth trying.