Live data from Hacker News

Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

arps18.github.io

171–180 of 297 posts

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#171
I’m so done reading articles like this.

Beyond the issue of AI serfdom, I just don’t want so much of my workflow to depend on “some other company.”

This whole setup is basically setting you up to have all your projects in a Claude SaaS lock-in.

I also think if AI was actually smart it wouldn’t need so much handholding. I don’t want to spend my time developing skills and writing markdown files to try to get this dumb thing to write code for me. Why isn’t the AI reading the codebase and understanding what to do?

Because it’s artificial, that’s why.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#172

What happens when you have a codebase made with claude using this setup and claude is down for let's say 8 hours? Are you able to efficiently, smoothly and productively take over the codebase?

Some agent-written tools and modules are easily the best codebases I've worked with. Documented correctly to the T with various charts and explanations for everything, "start here" guides, concepts defined clearly, and very good Git commit messages.

Naturally you can also have a LLM one-shot a 14000 line PHP monstrosity - it's up to you still, LLM or not.

The main problem is that it'll probably be a waste of time to code anything yourself if Claude is back online in 8 hrs. It's like walking to the next bus stop when you missed your bus - it won't make you get home any sooner.

8 hrs will probably be better spent reading specs or checking things with stakeholders so the next features you let Claude implement are the ones the business actually wants.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#173
post #13

The number one power move I have is Nix integration. The availability of tooling, secrets, environment and the ability for the agent to modify its own environment is... well, I don't know how people live without it. I guess you guys still install things using commands and hope everything you need is present on the next machine? Developer machine, CI environment, deployment environment: They're all derived from a sing…

I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point.

Codex is way better at nix than I am.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#174
I don't know how you guys still use anthropic models and Claude Code. It's so unbearably slow. Yesterday I was on screenshare with a coworker that still uses claude and I was shocked how much time was spent just waiting for tokens to generate.

Do yourself a favor and try Codex. Then do yourself an even bigger favor and try composer 2.5 from Cursor. It's night and day difference. You don't even have time to get distracted, you stay in the zone.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#175

What happens when you have a codebase made with claude using this setup and claude is down for let's say 8 hours? Are you able to efficiently, smoothly and productively take over the codebase?

We have 3 big competitors in the space: Anthropic, Google and Microsoft. I think they can all use the same base configuration. So it's not that we are out of options here.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#176
post #70

Earlier quoted context omitted.

Claude Code CLI is just a software package, if Anthropic API is down you could always connect Deepseek/other provider API to Claude Code CLI...

The point is that, with a sufficiently complex setup (with skills, MCPs, prompts, etc.) the difference in AI models will impact the quality of work. You might not care now, but you might care when you have 2 million lines of code and zero idea whats going on. The point is vendor lock-in. The vibe coding community has reinvented vendor lock-in and is bound to repeat every mistake associated with it.

Can you give an example of a skill or prompt that would work in Claude and not in the others?

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#178
post #168

We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…

I imagine that the companies that earn money from input and output tokens really, really like excessive skills because of the sheer amount of potentially pointless constraints and instructions being sent back and forth ("don't store passwords as plaintext", "always check for syntax errors" and other obvious guidelines).

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#179
Sometimes I feel like the only sane person in the room for not wanting to have to usher the LLM through phase by phase. Every time I need to choose the next skill or cat the next error is just a waste of my time that could be spent doing things that actually need my attention like making business tradeoffs.

Re: Claude Code as a Daily Driver: Claude.md, Skills, Subagents, Plugins, and MCPs

#180
post #178
post #168

We really need some consolidation around commands, skills, subagents, and plugins. For example, if you want to, say, review code, you have five options now: - Write a .claude/commands/review.md. Simple but deprecated. - Use a /code-review skill, either one you install or one you just write yourself (it's just Markdown, after all). - Use the /pr-review subagent. Also just Markdown, but it runs "in the background" and…

I imagine that the companies that earn money from input and output tokens really, really like excessive skills because of the sheer amount of potentially pointless constraints and instructions being sent back and forth ("don't store passwords as plaintext", "always check for syntax errors" and other obvious guidelines).

My personal experience is the opposite. Lack of skills uses more tokens.
Post reply on HN