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.
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.
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.
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.
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.
LLMs have completely killed my motivation to continue running it. None of standard practices apply anymore
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.
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.
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.
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...
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.
This is harder to guarantee since these tools are non-deterministic.
cute that you think cluade gives a rat ass about this.
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.
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.
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.
Perhaps your blanket statement could be wrong, and I would encourage you to let your mind be a bit more open. The landscape here is not what it was 6 months ago. This is an undeniable fact that people are going to have to come to terms with pretty soon. I did not want to be in this spot, I was forced to out of necessity, because the stuff does work.
The Vercel team had some interesting findings[1]:
> In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it.
Others had different findings for commonly accepted practices[2], some you may have adopted from reading documentation, which surely didn't come from influencers.
And yet others swear by magical Markdown documents[3].
So... who is the ultimate authority on what actually works, and who is just cargo culting the trendy practice of the week? And how is any of this different from what was being done a few years ago?
[1]: https://vercel.com/blog/agents-md-outperforms-skills-in-our-...
[2]: https://arxiv.org/abs/2602.11988
[3]: https://soul.md/
I measure the tooling success with a suite of small prompt tests performing repeatable tasks, measuring the success rate over time, educating the broader team, and providing my own tried and tested in the field skills that I’ve shared to similar successes to the broader teams. We’ve seen a huge increase in velocity and lower bug rate, which are also very easily measurable (and long evaluated stats) enough to put me in the position I am, which was not a reluctant one. You’re perfectly free to view my long history on this topic on this forum to see I am a complete skeptic on this topic, and wouldn’t be here unless I had to.
everyone is figuring this out still. There is no authority, I am my own authority on what I have seen work and what hasn’t. Feel free to take of that what you will. I just wanted to provide a counterpoint to your initial claim. I’m certainly not going to expose to a fine degree what has worked for my org and what hasn’t due to obvious reasons.
have a good day!
https://theonion.com/area-man-constantly-mentioning-he-doesn...
My point is, these custom things are often short lived band-aids, and may not be needed with better default harnesses or smarter future models.
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.
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
Better isolation than running it in a container.
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.
There many decent options (cloud VMs, local VMs, Docker, the built-in sandboxing). My point is just that folks should research and set up at least one of them before running an agent.
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...
I never said "permissions", I said "sandboxing". You can configure that in settings.json.
https://code.claude.com/docs/en/sandboxing#configure-sandbox...
which is basically every setup because claude sucks at calling skills and forget everything in claude.md with a few seconds.
>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