Live data from Hacker News

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

arps18.github.io

81–90 of 297 posts

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

#81
post #9

Regarding: ``` # Development Workflow *Always use `bun`, not `npm`.* # 1. Make changes # 2. Typecheck (fast) bun run typecheck # 3. Run tests bun run test -- -t "test name" # Single suite bun run test:file -- "glob" # Specific files # 4. Lint before committing bun run lint:file -- "file1.ts" bun run lint # 5. Before creating PR bun run lint:claude && bun run test ``` I have these things in pre-commit, this way the ta…

Isn't it simpler to use claude's vocabulary? I don't see a good use case for this.

To understand a solution you must first understand the problem. If your whole company calls its customers "clients" but claude finds that confusing, I think it's probably easier to tell claude that then get everyone in the company to change how they talk.

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

#82

I’m getting into the agentic coding (I know, late to the party, and that’s been a good spot for my experience and use case), so I’m reading with interest. The first tip: “give Claude a way to verify its own work”. So what’s the recommendation for Claude to have a feedback loop? Because it’s not what follows in the article: _“Explore, then plan, then code.”, “Use plan mode…”, “Reference, do not describe.”_

Typically for most code it's telling claude how to run tests.

For front end code it's giving claude a way to 'see' the work for example a Playwrite MCP server seems common. https://playwright.dev/docs/getting-started-mcp

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

#83

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?

You could say the same thing about any always online software suite and it would be equally fair as we move into more agentic development workflows. EX. Sure, you could go back to the old ways of using a drafting table for your engineering work if CAD went down but it would be exponentially slower… Personally with my workflow I spend 30-60 minutes per Claude feature spec doc when I’m pair planning. If Claude goes dow…

>You could say the same thing about any always online software suite

Precisely. Every online-only solution is a huge risk i personally do not want to take, i've always done my best to use offline-only tools.

That may restrict me from the latest and greatest, but i prefer not to be left at mercy of any corpo

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

#84
post #72

Earlier quoted context omitted.

I assume it will be similar to when a person is out sick or on vacation. Another person on the team likely could take over the work for a day, but realistically it just sits until they're is back.

So work stops until Claude is back? What if Claude comes back and costs 10x the amount? The answer is obviously that you'll "bend over" and pay, because the AI vendor who convinced you that Claude is so great owns you, your codebase, and by extension your company now.

For substandard developers, yes, work stops.

I have seen many many times in microcontroller forums posts from first timers in the liking of "hello sirs i have problem please show how to do this", followed by their own reply a few hours later asking again because they were holding up, where "this" was usually something really trivial, you just needed to read the docs and the rightful answer was "did you really not try anything in 6 hours?"

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

#85
post #55

Earlier quoted context omitted.

[flagged]

I agree. In fact, computers in general are for lazy cretins who can't use a pen and paper. We got man into space calculating with a pen and paper, if it was good enough then, it is good enough now. I like your concept, it should go further, cars are for people too lazy to walk. Planes are for people too lazy to flap their arms. Video cameras are for people too lazy to draw each frame by hand in real time then play th…

Please. Don't compare the objectively useful deterministically operating tools with the stochastic shit-generating-machines.

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

#86

I've been using Claude to work on a medium-sized (100+kLoc) codebase, and it's a great productivity multiplier. Putting hours into creating a good AGENTS file is more improved results a lot. I find that over time it picks up the codebase quite well. Tedious tasks that would take a day are now a matter of a few prompts. Still... I'm not ready to give it more autonomy. Even as it gets high-level things quite well, I st…

Understandable. You don’t want to lose control to your codebase and don’t trust LLM is competent in handling that fully.

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

#87
post #39

Earlier quoted context omitted.

For those who don't want the complexity of Nix, Mise is a good compromise

+100. I also dig fnox (encrypted-secrets-in-git) and hk (pre-hooks manager that is actually fast and stays out of the way) by the same author, pretty much default for any project I start nowadays. Though I also use nix to manage my machines :-D

Awesome, both fnox and hk look very well-made.

How does fnox compare to sops?

How does hk compare to lefthook?

And does hk and fnox have a similar Nix integration as lefthook-nix and sops-nix?

I'm still hoping I don't need to make a better lefthook.

I kind of like sops-nix, not sure what's missing, really. Maybe fnox is similarly wholesome for non-Nix users.

I see that hk has a flake, so that's a good sign.

https://github.com/sudosubin/lefthook.nix

https://simonshine.dk/articles/lefthook-treefmt-direnv-nix/

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

#88

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?

You could say the same thing about any always online software suite and it would be equally fair as we move into more agentic development workflows. EX. Sure, you could go back to the old ways of using a drafting table for your engineering work if CAD went down but it would be exponentially slower… Personally with my workflow I spend 30-60 minutes per Claude feature spec doc when I’m pair planning. If Claude goes dow…

> You could say the same thing about any always online software suite

But this is the reason "serious shops" do not use always online software and tools in critical parts of the SDLC. There is a difference between influencers/people on socials promoting things vs. reality where the expectation is that things don't just stop working because there is an internet outage or some 3rd party disruption

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

#89

In the recent weeks, I think the harness/model came to a point that you can just ask it to do stuff and it just does. You can use plan mode, you can also use superpowers, or whatever other skill, but given that you'll review something anyway, why not work directly with code instead of silly amounts of md files?

In the recent weeks I trust Claude less and less. Yes, you can ask it to do stuff and it does stuff. But if you do look what it did you will often find corners cut, work based on assumptions and not verification, a lot of stuff missed. Even tests - it is common for it to write tests which in reality test nothing.

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

#90
The reliance on context to drive correct actions just doesn't work well. I am constantly wrestling with AI agents that do not do what you tell them. Every AI agent out there seems to suck in this regard, leaving it up to the user to build in their own guardrails. I have a bad feeling that nobody is working on an improved solution.
Post reply on HN