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 layer of nondeterminism into it, and also blow up your context window.
The only skill you should probably install instead of maintaining it yourself is playwright-cli, but that's pretty much it.
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 wet.
Not everyone will go for such minute tweaks.
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’s mouth underneath me I’d tell them to leave the room before I have a stroke.
And this is stuff like, if so and so’s machine is compromised, it could cost the company massive sums of money. for your personal use, fine, but hearing this cavalier attitude like it doesn’t matter is horrifying, because it absolutely does in a lot of contexts.
You do not want to log in one day to find your favorite workflow has changed via updates.
Then again this is all personal preference as well.
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 block agent traffic like Apple's documentation.
For example, I have a rule [^0] that instructs Claude to never start work until some pre-conditions are met. This works well, as it always seems to check these conditions before doing anything, every turn.
I can see security teams wanting to use this approach to feel more comfortable about devs doing things with agentic tools without worrying _as much_ about them wreaking havoc (or what they consider "havoc").
As well, as someone who's just _really_ getting started with agentic dev, spending time dumping how I work into rules helped Claude not do things I disapprove of, like not signing off commits with my GPG key.
That said, these rules will never be set in stone, at least not at first.
[^0]: https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/c...
It's also not targeted at first-timers getting their first taste of AI coding. It's a guide for how to use these tools to deal with frustrations you will inevitably encounter with AI coding.
Though really, many of the complaints about AI coding on HN are written by beginners who would also benefit from a simple .claude configuration that includes their preferences and some guidelines. A frequent complaint from people who do drive-by tests of AI coding tools before giving up is that the tools aren't reading their mind or the tools keep doing things the user doesn't want. Putting a couple lines into AGENTS.md or the .claude folder can fix many of those problems quickly.
IMHO most of this “customize your config to be more productive” stuff will go away within a year, obsoleted by improved models and harnesses.
Just like how all the lessons for how to use LLMs in code from 1-2 years ago are already long forgotten.
Working out how to work on code on your own with agentic support is one thing. Working out how to work on it as a team where each developer is employing agentic tools is a whole different ballgame.
Is this a hangover from when the tools were not as good?
1. Provision of optional tools: I may use an ai agent differently to all other devs on a team, but it seems useful for me to have access to the same set of project-specific commands, skills & MCP configs that my colleagues do. I amn't forced to use them but I can choose to on a case by case basis.
2. Guardrails: it seems sensible to define a small subset of things you want to dissuade everyone's agents from doing to your code. This is like the agentic extension of coding standards.
Most people do, most people don’t have wildly different setups do they? I’d bet there’s a lot in common between how you write code and how your coworkers do.
Isn't this article just another one in that same drawer?
> What actually belongs in CLAUDE.md - Write: - Import conventions, naming patterns, error handling styles
Then just a few lines below:
> Don’t write: - Anything that belongs in a linter or formatter config
The article overall seems filled with internal inconsistencies, so I'm not sure this article is adding much beyond "This is what an LLM generated after I put the article title with some edits".
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
I know the deny list is only for automatically denying, and that non-explicitly allowed command will pause, waiting for user input confirmation. But still it reminds me of the rationale the author of the Pi harness [1] gave to explain why there will be no permission feature built-in in Pi (emphasis mine):
> If you look at the security measures in other coding agents, *they're mostly security theater*. As soon as your agent can write code and run code, it's pretty much game over. [...] If you're uncomfortable with full access, run pi inside a container or use a different tool if you need (faux) guardrails.
As you mentioned, this is a big feature of Claude Code Web (or Codex/Antigravity or whatever equivalent of other companies): they handle the sand-boxing.
[0] https://blog.dailydoseofds.com/i/191853914/settingsjson-perm...
[1] https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to...
https://github.com/anthropics/claude-code
You can download the devcontainer CLI and use it to start a Docker container with a working Claude Code install, simple firewall, etc. out of the box. (I believe this is how the VSCode extension works: It uses this repo to bootstrap the devcontainer).
Basic instructions:
- Install the devcontainer CLI: `https://github.com/devcontainers/cli#install-script`
- Clone the Claude Code repo: `https://github.com/anthropics/claude-code`
- Navigate to the top-level repo directory and bring up the container: `devcontainer --workspace-folder . up`
- Start Claude in the container: `devcontainer exec --workspace-folder . bash -c "exec claude"`
P.S. It's all just Docker containers under the hood.
Better isolation than running it in a container.
Always separate plan from implementation and clear context between, its the build up of context that makes it bad ime.
Don't skills sit in context while custom slash commands are only manually invoked?
The difference isn't clear to me, especially since, upon googling it right now, I see that skills can also be invoked with a /slash.
I don't think people realize exactly how important the specific prompts are, with the same prompt you'd get wildly different results for different models, and when you're iterating on a prompt (say for some processing), you'd do different changes depending on what model is being used.
Would also be interested in examples of a CLAUDE.md file that works well in Claude, but works poorly with Codex.
[0] https://claudefa.st/blog/guide/mechanics/claude-md-mastery
They look to me like people actually want to build deterministic workflows, but blobs of text are the wrong approach for that. The right tool is code that controls the agent through specific states and validates the tool calls step by step.
This sort of "prompt and pray" flow really works for people, as in they can make products and money, however, I do think the people that succeed today also would've reached for no-code tools 5 years ago and seen similar success. It's just faster and more comprehensive now. I think the general theme of the products remains the same though; not un-important or worthless, but it tends to be software that has effects that say INSIDE the realm of software. I feel like there's always been a market for that, as it IS important, it's just not WORTH the time and money to the right people to "engineer" those tools. A lot of SaaS products filled that niche for many years.
While it's not a way I want to work, I am also becoming comfortable with respecting that as a different profession for producing a certain brand of software that does have value, and that I wasn't making before. The intersection of that is opportunity I'm missing out on; no fault to anyone taking it!
The software engineer that writes the air traffic avoidance system for a plane better take their job seriously, understand every change they make, and be able to maintain software indefinitely. People might not care a ton about how their sales tracking software is engineered, but they really care about the engineering of the airplane software.
It shouldn’t be, but it’s going to take some catastrophic events to convince people that we have to work to make sure we understand the systems we’re building and keep everything from devolving into vibe coded slop.
I guess that's why I see it as a separate profession, as in we have to actually profess a standard for how a professional in our field acts and believes. I think it's OK for it to bifurcate into two different fields, but Software Engineering would need to specifically reject prompt-and-pray on a principled and rational basis.
Sadly yes, that might require real cost to life in order to find out the "why" side of that rational basis. If you meet anyone that went to an engineering school in Québec, ask them about the ceremony they did and the ring they received. [0] It's not like that ceremony fixes anything, but it's a solemn declaration of responsibility which to me at least, sets a contract with society that says "we won't make things that harm you".
[0] https://ironring.ca/home-en/
> [The] history of the 1907 failure of the Quebec City bridge, which was the inspiration for the Calling of an Engineer ceremony.This is a brilliant reimagining of the old and trusted PnP acronym.
It has a few issues with outdated advice (e.g. commands has been merged with skills), but overall I might use share it with co-workers who needs an introduction to the concept.
I recently tried IntelliJ for Kotlin development and it wanted me to give a credit card for a 30 day trial. I just want something that scans my repo and I tell it the changes I want and it does it. If possible, it would also run the existing tests to make sure its changes don't break anything.
While the coding assistants are pretty much universally free, you still need to connect them to a model. The model tokens generally cost something once you've gone past a certain quota.
I'm not sure if this is still true, but if you have a Google account, Gemini Code Assist had a quite generous "free tier" that I used for a while and found it do be pretty decent.
It is fun to use.
You log in with your Goggle account.
Opencoder is bring your own model.
You get what you pay for so good luck.
Do people find the nano-banana cartoon infographics to be helpful, or distracting? Personally, I'm starting to tire seeing all the little cartoon people and the faux-hand-drawn images.
Wouldn't Tufte call this chartjunk?
Feels like generated AI art like this is modern clipart
Let’s say lose those and using emojis as bullet points. It’s going to be a lot harder to detect.
But they had already lost me at all the links, and the fact there's not a red wire through the entire article.
The first thing my eyes skimmed was:
> CLAUDE.md: Claude’s instruction manual
> This is the most important file in the entire system. When you start a Claude Code session, the first thing it reads is CLAUDE.md. It loads it straight into the system prompt and keeps it in mind for the entire conversation.
No it's not. Claude does not read this until it is relevant. And if it does, it's not SOT. So no, it's argumentatively not the most important file.
https://code.claude.com/docs/en/memory
“CLAUDE.md files are loaded into the context window at the start of every session”
Like mostly people who have confused luck and success, or business acumen for religion.
So I wouldn’t use LinkedIn as a positive data point of what’s hot.
> Clutter is the disease of American writing. We are a society strangling in unnecessary words, circular constructions, pompous frills and meaningless jargon.
> Look for the clutter in your writing and prune it ruthlessly. Be grateful for everything you can throw away. Reexamine each sentence you put on paper. Is every word doing new work? Can any thought be expressed with more economy?
On Writing Well (Zinsser)
In this case, I'd say helpful because I didn't have to read the article at all to understand what was being communicated.
Some of the others, I don’t feel like added value, but I agree that these are some of the best of a practice that I agreed does not add a ton of value typically
So yes, it's chartjunk.
I think the problem is that they're uninformative slop often enough that I've subconsciously determined they aren't worth risking attention time on.
>Claude Code users typically treat the .claude folder like a black box. They know it exists. They’ve seen it appear in their project root. But they’ve never opened it, let alone understood what every file inside it does.
I know we are living in a post-engineering world now, but you can't tell me that people don't look at PRs anymore, or their own diffs, at least until/if they decide to .gitignore .claude.
I'm a senior engineer who has been shipping code since before GitHub and PR reviews was a thing. Thankfully LLMs have freed me from being asked to read other people's shit code for hours every day.
No.
CLAUDE.md is just prompt text. Compaction rewrites prompt text.
If it matters, enforce it in other ways.
When you have this performative folder of skills the AI wastes a bunch of tool calls, gets confused, doesn't get to the meat of the problem.
beware!
> Two folders, not one
Why post AI slop here?