Live data from Hacker News

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

arps18.github.io

201–210 of 297 posts

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

#201
post #194
post #192

Earlier quoted context omitted.

Hi Boris, what is the advantage of using /code-review vs just asking Opus to “code review”? As a casual user working on hobby projects, I struggle to keep up with the pace of changes and knowing what to use when. My default now is to use Opus for all coding (sonnet is fine but seems dumber) and to prompt it for everything I need. I’ve had great success with this but clearly I’m missing power user functions with the s…

The advantage is that /code-review supplies a structured idea of how to review and what that process should look like and then launches independent subagents to approach the issue from multiple angles. It's analogous to how in the early days you could see benefits by telling the models to "think step by step". /code-review is something like "review angle by angle". "Consider removed behavior" and also "Look at langua…

Thank you I will try this!

Is there something equivalent when coding in the first place? Eg /code high “prompt”

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

#202
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…

Yikes. That Nix code is a mess without meaningful organization & only usable via experimental flakes.

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

#203
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…

> They are all just variations of "insert a canned prompt", varying only along the dimensions of (a) how and where the prompt is installed and from where it is sourced, and (b) which context or contexts the prompt runs in. There's not much advice here about which option is best, and no clear best practices seem to have emerged yet either. Personally, I find just asking Claude to review the code works well enough.

The subagent approach is structurally different from the others because it runs with clean context. That has three major effects:

1. All other things being equal, it will result in a lower cost-to-solution because of the quadratic cost scaling of an LLM session (input token or cached-input cost being paid with each new round).

2. The review model will not be able to 'cheat' by retaining assumptions from the main session, such as "x must be done like y." For people, this is why having a separate person perform code review (or, if not possible, reviewing code after a mind-clearing break) is handy; the applicability of this analogy to LLMs is vague but reasonable.

3. The main model will only see the results of the review, not the detailed reasoning that leads up to it. On one hand this avoids more context pollution, but on the other hand it might lead to duplicative logic to re-discover the mechanics behind bugs found.

> I checked the session logs to see how often the agents were actually invoking the LSP tools. The answer was they had invoked them literally once the entire time.

I think the intent behind 'install a language server plugin' is that these tools should lint automatically after every edit, without waiting for an explicit call from the LLM.

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

#204
post #192

Earlier quoted context omitted.

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…

Hi Boris, what is the advantage of using /code-review vs just asking Opus to “code review”? As a casual user working on hobby projects, I struggle to keep up with the pace of changes and knowing what to use when. My default now is to use Opus for all coding (sonnet is fine but seems dumber) and to prompt it for everything I need. I’ve had great success with this but clearly I’m missing power user functions with the s…

As a general rule, I'd give the Markdown a read for any skills/commands you might find useful, it'll give you a good idea of the specifics it adds.

https://github.com/anthropics/claude-code/blob/main/plugins/...

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

#205
post #191

Earlier quoted context omitted.

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…

Hey Boris, some feedback. I like the new /code-review skill but was disappointed you guys removed /simplify because I quite liked the focus on finding code reuse/efficiency opportunities. I see now in 2.1.152 you added those focus areas back to /code-review, but still bundled with the correctness finding. It would be great to have more fine grained control over the /code-review angles beyond just effort level. Or may…

Yep, you can add free-form input. Will update /simplify to only check for code quality and not bugs (the way it used to work), that's a good suggestion.

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

#206
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 just consider this temp phase because models are dumb and harnesses are not yet there. When I need code review I should just say “review it”. Model should figure out what plugins, skills, etc. to use.

Totally. You can do that now, and Claude will know to use /code-review.

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

#207
post #129
post #88

Earlier quoted context omitted.

> 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

I would argue that it's really only toy projects that can continue in an Internet outage. "Serious shops" will be using cloud based version control, cloud based testing workflows, and most likely cloud based distribution of the software. isn't it only the little side projects you can get away with not needing the Internet for? Software long ago stopped being something one person on a computer did, today the professio…

[deleted]

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

#208
post #139

Earlier quoted context omitted.

Basically any other that is not stuck to being managed just by one company. Claude Code does things like using CLAUDE.md and other stuff specific to just their platform, so you are basically locking your project, and everyone else who works on it, to Claude Code only, if you don't also port everything you do to other harnesses. If Anthropic is giving cheaper tokens in exchange for locking you in into their ecosystem,…

It also can respect AGENTS.md, just saying. It’s all about your README.md. But I’m with you about being agent agnostic.

works the other way as well, i have my opencode.jsonc which declares what model an agent should use, and it points at .claude/agents/ those agents each have their anthropic based model instead, almost feel like this broke in the past week though for just cc, hard to tell as cc keeps changing and i dont wanna update and learn more claude based nonsense again, if i wasn't locked into a year of pro or whatever, I would 100% be done using them entirely.

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

#209
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…

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…

Thanks, Boris, for reading and reviewing :)

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

#210
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…

Hey, Boris from the CC team here. I agree, we're working on consolidating these. Going forward it will just be the built-in /code-review skill. Here's how to use the skill on the latest version: /code-review # do a balanced code review. checks for bugs and inconsistencies, poor code quality, duplication, band aids, etc. /code-review --fix # same as above, but also fix the issues # choose an explicit effort level (def…

Hey Boris, thanks for the great product and for listening!

I find the mix between slash commands that are programmatic harness configuration and control commands (/config, /model, /feedback, /fork, /usage, etc.) and ones that are little more than prompt template insertion (/code-review, /, etc.) to be a little confusing and unnecessary. A slash command should be one thing, and one thing only: a command for the harness, not the agent.

When I invoke a slash command like /code-review, I should be invoking some additional harness functionality, something above and beyond the agent's sphere of influence - not just pasting some hidden text into the next turn. Otherwise, why wouldn't I just say "Claude, review this code"?

Yet most of these "added value" commands bloating the slash command list, are just shortcuts for copy and paste. I don't want to go to have to learn the syntax of a special /code-review command (which options are positional args, which are --flags, etc.), and I'm much less likely to use or even be aware of a command like this, when I can just ask "Do a balanced code review and fix the issues", or use the GUI to set the effort level to xhigh before asking "Review my code." That way I can also be more specific about exactly what I need, rather than relying on what's in the canned prompt - a prompt which I'll probably never read and vet myself anyway. The value added by the slash command needs to be really high compared to just typing a prompt, for it to justify the friction of discovery and learning the syntax.

So I suppose I'm advocating for a different system. Keep slash commands for meta-level harness control and configuration, and add a new mechanism for canned prompt insertion, one which is tailor made for that purpose rather than overloading the slash command system. Let the user see what's in the canned prompts, and even make adjustments or edits as needed before sending them, one-time or persisted. Provide a GUI in the app with the user's favorite prompts, where the user can add, delete, and edit them, making it easy to invoke and insert them as needed. Or let the agent automatically discover and use them as needed, rather than requiring the user to remember and recall their magic shortcuts and their arguments. That's just one idea.

Skills, plugins, commands, and so on, need to be consolidated not just for code review of course but across the full architecture of how prompt templates are managed.

Post reply on HN