5 ms·

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 u

by bcherny 4mo ago

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 (defaults to your current effort level). all of these also accept --fix: /code-review low /code-review medium /code-review high /code-review xhigh /code-review max # do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity): /code-review ultra Open to feedback if anyone has feedback or ideas for how to make these even nicer to use.

extr 4mo ago
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 maybe you would recommend that I just specify that as freeform input after effort level?
- bcherny 4mo ago
  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.
  - extr 4mo ago
    Damn already there in 154. Thank you man.
bix6 4mo ago
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 slash commands and such.
- bcherny 4mo ago
  /code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.
  - bix6 4mo ago
    And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place? This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.
- extr 4mo ago
  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 language gotchas" and also "Look at test changes"...etc. Yes these are all somewhat implicitly already part of what "code review" means, but the models perform best with explicitness. If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.
  - bix6 4mo ago
    Thank you I will try this! Is there something equivalent when coding in the first place? Eg /code high “prompt”
    - extr 4mo ago
      Are you thinking of the /effort level in Claude Code? I would just go with xhigh as a reasonable default. Most important thing in prompting is specifying what "done" and "success" looks like to you. Ask Claude to help you come up with a well formed request and spend most of your time on that, then paste that into a brand new session.
new_account_101 4mo ago
[flagged]
arps18 4mo ago
Thanks, Boris, for reading and reviewing :)
mil22 4mo ago
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, /<skill>, 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.
- wonkyfruit 4mo ago
  What clicked for me recently was treating skills as composable. Having meta-skills that call smaller skills in order. The "skill vs command vs subagent" confusion partly dissolves once you let skills call other skills. The meta-skill holds the workflow state, the smaller ones each do one job well.
svieira 4mo ago
> reliably catches >99% of bugs In what scope?
8note 4mo ago
> # do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity): /code-review ultra main suggestion would be to sound a lot less optimistic about that it finds 99% of bugs or that its at all thorough, and instead list that it is time capped, and will only find bugs that you explicitly tell it to look for. i used my three runs of ultrareview. the first run with no other prompting found a couple typos in markdown only the second one i prompted it with several themes of known open bugs in the code, and it found 6 items and then the third one i ran after doing an actual long audit through gemini to make a much more detailed prompt about issues in the code and for that one, instead of doing an exhaustive run, it just never started, so no idea if it worked but the experience had no relation at all with the reliability or thoroughness claims
- BD7691 4mo ago
  [dead]
bmitc 4mo ago
Why doesn't Claude invoke LSPs? It always asks to install them, but then it never uses them, as mentioned in the comment you replied to.
thefivetoes 4mo ago
[flagged]

by bcherny 4mo ago

extr 4mo ago

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 maybe you would recommend that I just specify that as freeform input after effort level?

bcherny 4mo ago
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.
- extr 4mo ago
  Damn already there in 154. Thank you man.

bix6 4mo ago

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 slash commands and such.

bcherny 4mo ago
/code-review has a specific prompt that we've found is a good balance of precision, recall, and cost. You could totally roll your own prompt also.
- bix6 4mo ago
  And why would someone use the various levels? Is a low code review even worth running? And how do I know what level to use in the first place? This stuff all seems so nebulous to me and I’ve yet to see anything that says use x in y situation. So I default to higher effort levels than I likely need.
extr 4mo ago
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 language gotchas" and also "Look at test changes"...etc. Yes these are all somewhat implicitly already part of what "code review" means, but the models perform best with explicitness. If you want my 2c as a power user: just don't think about it and use /code-review xhigh --fix. This will cover like 98% of what you want out of code review. It's a good skill.
- bix6 4mo ago
  Thank you I will try this! Is there something equivalent when coding in the first place? Eg /code high “prompt”
  - extr 4mo ago
    Are you thinking of the /effort level in Claude Code? I would just go with xhigh as a reasonable default. Most important thing in prompting is specifying what "done" and "success" looks like to you. Ask Claude to help you come up with a well formed request and spend most of your time on that, then paste that into a brand new session.

new_account_101 4mo ago

[flagged]

arps18 4mo ago

Thanks, Boris, for reading and reviewing :)

mil22 4mo ago

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, /<skill>, 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.

wonkyfruit 4mo ago
What clicked for me recently was treating skills as composable. Having meta-skills that call smaller skills in order. The "skill vs command vs subagent" confusion partly dissolves once you let skills call other skills. The meta-skill holds the workflow state, the smaller ones each do one job well.

svieira 4mo ago

> reliably catches >99% of bugs In what scope?

8note 4mo ago

> # do an expensive and extremely thorough review (reliably catches >99% of bugs, costs $3-20 per review depending on complexity): /code-review ultra main suggestion would be to sound a lot less optimistic about that it finds 99% of bugs or that its at all thorough, and instead list that it is time capped, and will only find bugs that you explicitly tell it to look for. i used my three runs of ultrareview. the first run with no other prompting found a couple typos in markdown only the second one i prompted it with several themes of known open bugs in the code, and it found 6 items and then the third one i ran after doing an actual long audit through gemini to make a much more detailed prompt about issues in the code and for that one, instead of doing an exhaustive run, it just never started, so no idea if it worked but the experience had no relation at all with the reliability or thoroughness claims

BD7691 4mo ago
[dead]

bmitc 4mo ago

Why doesn't Claude invoke LSPs? It always asks to install them, but then it never uses them, as mentioned in the comment you replied to.

thefivetoes 4mo ago

[flagged]