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

Why are there so many flagged comments in here? They all look fairly banal but yet still flagged.

"Claude Code as a Daily Driver", which was also used to generate this article..

Also, how is "Explore, then plan, then code" considered "beyond the basics"?

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?

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 single source, and compiling and running always works on every machine.

In Claude I use /branch and /rename a lot (context checkpoints, fork, go back)

I use sandboxing almost exclusively: https://github.com/nix-tools/bubblebox -- it's a generalisation of Numtide's claudebox with a few fixes and some feature additions (more coming). This is best compared to always running your Claude in Docker containers, except there's no Docker runtime. Works fine in WSL and nix-darwin, too.

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 targets are always ran and the agent is forced to fix them (I ask claude to commit changes). The agents are erratic and very often skip these steps. Anything that can be deterministic I keep as scripts.

Regarding commits; both codex and claude are terrible at writing them. I have in my user CLAUDE.md:

``` Pattern: `type(scope): message` where type is `fix`, `feat`, `chore`, `docs`, `refactor`, or `style`; scope marks what is affected; message is a short lowercased description.

Keep subject and body lines under 72 characters. Always write a body explaining what, how, and why in continuous human-readable text. For fixes include the error message being fixed. No first-person speech. Re-read the actual git diff before writing — the message must describe what changed, not what was planned.

Use following command to create commit:

```bash git commit -F - <<'EOF' type(scope): subject line

Body paragraph explaining what, how, and why. EOF ```

```

Without it would write the body as a single long sentence; when asked to fix lines it would just insert \n (newlines), which were not respected and were instead just rendered as characters.

Another thing I find helpful is VOCABULARY.md. Very often the agent would assume (connect?) a different thing than what I had in mind, with VOCABULARY I make sure when I say "thing" claude and I have both the same "understading" (connection?) what "thing" is.

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?

How much time do you lose when doing things like "verify plan with a second clean agent" instead of just reading and fixing it yourself in 5 min? How much understanding do you lose? How do you manage to treat it "as an engineer" where it's clearly not there yet? How much time do you lose when it makes almost the same mistake, invents stuff or tries to gaslight you over and over? What about blood pressure?

Claude Code with skills is undoubtedly powerful and useful, but it doesn't always work as expected.

I always get the best results when I have live feedback with it.

The post goes to the point. Somehow this must be buried in Anthropic's documentation but I miss this kind of back-to-basic posts. Even if they are LLM-penned.

Out of curiosity, how much does it cost to daily drive Claude like this?

To me, this kind of talk exhibits the very cultish and con side of the whole genAI train. In a way, it does a poor job especially when the intent is positive about the technology, it sheds a bad look on it.

Generally, and more so with paid products, one should expect to get something that is ready to be used, tuned by who's selling it at the best of their efforts. Instead, this is basically saying that the product is actually not much more than an empty box, and that it is your responsibility to augment it with third-party plugins and markdown texts that make it finally useful. And you better be carefully selecting the skills you install, you don't want to end up with second tier material made by GithubInfluencerA, you definitely need the work of GithubInfluencerB.

In the end, it's what is giving companies fuel to keep the hype running, because it allows to counter every possible argument or doubt about the technology, especially the ones made in good faith. No matter the problem you're facing, the blame is definitely on you, the user, for not setting up the tool in the right way.

I'm struggling in a lot of ways in accepting LLMs, but if I'll ever come completely sold on them and take this technology seriously, it won't be before this mood has gone away.

Nerds and their tendency to over-complicate everything. What is wrong with just an IDE with a simple claude integration?

> Delegate, do not pair-program. Cat Wu (Claude Code team): “The model performs best if you treat it like an engineer you’re delegating to, not a pair programmer you’re guiding line by line.” Write a crisp brief upfront, then let it run.

This is also how you get a slop codebase that you won’t easily understand.

It becomes a labyrinth that only the Agent knows. It’s not a catastrophe when your making prototypes or projects like you see on X.

But if you are expanding your codebase or trying to build something more professional and maintainable. I find it important to explicitly spec things bit by bit so I can understand and some what keep my writing style in this codebase. But this is only productive when you have a fast model otherwise it kills your chain of thought while you wait for the output.

If the model is slow, delegation is probably the only way.

Oh great! Another AI slop article about "working" with AI (= working for AI). Do you notice how much bloody work you put in the boring parts, only to leave out the most creative aspect of software engineering to a slot-machine?

Honestly, claude code has saved so many hours of finding bugs for developers

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

[dead]