Is there any lesson here for non-devs (like me) who are using CC to write some pretty long, gnarly notebooks. The problem I have recently run into is that CC vibe codes really long code with lots of checks. But, then when I want to modify it, CC has more code to read and it gets overwhelmed. If it didn't include as many checks to begin with, it would be easier to understand what is going on. Any advice? Have you seen…
What to Put in a Claude Code Skill for Reviewing Your Team's Code
11–14 of 14 posts
Re: What to Put in a Claude Code Skill for Reviewing Your Team's Code
#12What's the point of having the testing be done by Claude Code via a skill, rather than just hard-coding the set of tests to be run?
Re: What to Put in a Claude Code Skill for Reviewing Your Team's Code
#13> Auto-review on routine PRs produced too much noise. A one-line config change doesn't need a 12-point review Shouldn't you prompt the review to just be a one-line review then? I see real danger in having humans review "the easy fixes" manually, but then rely on Claude for the complicated stuff. I'd be curious to learn whether you have similar prompts and skills for producing code, as opposed to just code review.
what danger?
Re: What to Put in a Claude Code Skill for Reviewing Your Team's Code
#14I definitely see a lot of these anti-patterns in the code that CC writes. Many of these can be caught at the time the code is written without needing to wait for a PR review. To me, it seems like most of these instructions belong in CLAUDE.md instead of or in addition to a specialized review skill. Are there things in the review skill that don't belong in CLAUDE.md?