You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CC should verify its own work against requirements and rules #651
tl;dr: Have Claude Code check its own work at the end of edit sessions, vs standards and requirements. One way to do this is with some equivalent to: claude -p "Please check uncommitted changes vs any global rules or requirements that you're aware of, and identify any deviations from those rules and requirements. Then say PASS or FAIL based on whether you think the code quality and compliance are good enough to allow a production launch."
Working with Claude Code has been great, but I've noticed some consistent patterns of failure:
CC doesn't naturally write unit tests
if tests exist, and it's having trouble making them work, CC will mark them skipped
if I give example cases where functionality fails, CC sometimes writes implementation code that handles the one use case
if code is throwing an error, CC sometimes adds workarounds or ignores exceptions rather than fixing the error and allowing the exception to show failure
When I look at my chat logs, I'm constantly watching its output and correcting it as it colors outside the lines of the rules, even if they're established in CLAUDE.md. I keep saying NO WORKAROUNDS!
It occurs to me that the fix for this is somewhere between a linter and a unit test. Since I'm just being a nanny most of the time, verifying that the changes are okay against CLAUDE.md and any requirements like a REQUIREMENTS.md, how about automating this? Have CC itself run this comparison at the end of a code editing run?
I've started using this prompt to do this kind of check, with decent results. I don't think it should be run in the current session, but as a separate query with a new context: Please check uncommitted changes vs any global rules or requirements that you're aware of, and identify any deviations from those rules and requirements.
This is absolutely the most limiting and annoying habit of Claude - if code is throwing an error, CC sometimes adds workarounds or ignores exceptions rather than fixing the error and allowing the exception to show failure - I will catch Claude writing all sorts of crazy work-arounds, making up defaults, etc... and in a few prompts it's right back at it again. This mean Claude required CONSTANT close supervision. Exception handling does not mean hiding the exception it means THROWING the exception with meaningful logs. This is also true for response handling from APIs as example, where Claude will just fill in something it thinks is the 'right' answer if the response contained an error. Something like IF 'I don't get the answer I expect' THEN 'return something that looks like what I expect'. It's maddening.
So the claude -p command I outlined helped me, but it isn't really automated. I also had CC write a unit test that runs clause -p to check the code, which helps.
If this were integrated in CC, it could possibly take the form of: at the end of a coding run, take the full output log for that run, including code diffs, and give it to Haiku to review vs the defined standards and requirements for the project. This could potentially be a way to "lint" the output on the fly, and give direct feedback without user intervention, just like with linter calls.
I've asked Claude why it didn't follow a rule I had layed out in the Claude.md, and to rewrite the language so that it will follow the rule in the future. Usually it removes words like should, and replaces them with MUST. Claude sees a much bigger difference between: "One should write unit test for all code" or "Please write unit tests for all code" and "Each code change MUST be accompanied by a unit test".
if tests exist, and it's having trouble making them work, CC will mark them skipped
if code is throwing an error, CC sometimes adds workarounds or ignores exceptions rather than fixing the error and allowing the exception to show failure
Agree, and both very annoying. You tell claude to not do any workaround or bypass, it acecpts and does it anyways after the next failed fixing attempt
Instead of trying to get the actual Claude CLI working with NVM (which was not properly set up in the backend container), we used a simulated version
I get things like this quite often. Other examples where claude code implements
|| true
Claude Codes favorite is to create a simplified version of a script, test or whatever.
Basically it does not matter how often you mention it in a prompt or you put this info to memory, at some point claude goes back to do so.
This should be a general rule to not bypass, simplify, simulate, etc. things.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.
Activity
wanderingnature commentedon Mar 29, 2025
This is absolutely the most limiting and annoying habit of Claude - if code is throwing an error, CC sometimes adds workarounds or ignores exceptions rather than fixing the error and allowing the exception to show failure - I will catch Claude writing all sorts of crazy work-arounds, making up defaults, etc... and in a few prompts it's right back at it again. This mean Claude required CONSTANT close supervision. Exception handling does not mean hiding the exception it means THROWING the exception with meaningful logs. This is also true for response handling from APIs as example, where Claude will just fill in something it thinks is the 'right' answer if the response contained an error. Something like IF 'I don't get the answer I expect' THEN 'return something that looks like what I expect'. It's maddening.
willer commentedon Mar 29, 2025
So the claude -p command I outlined helped me, but it isn't really automated. I also had CC write a unit test that runs clause -p to check the code, which helps.
If this were integrated in CC, it could possibly take the form of: at the end of a coding run, take the full output log for that run, including code diffs, and give it to Haiku to review vs the defined standards and requirements for the project. This could potentially be a way to "lint" the output on the fly, and give direct feedback without user intervention, just like with linter calls.
j2043 commentedon Apr 25, 2025
I've asked Claude why it didn't follow a rule I had layed out in the Claude.md, and to rewrite the language so that it will follow the rule in the future. Usually it removes words like should, and replaces them with MUST. Claude sees a much bigger difference between: "One should write unit test for all code" or "Please write unit tests for all code" and "Each code change MUST be accompanied by a unit test".
Of course, YMMV.
danieldeusing commentedon May 1, 2025
Agree, and both very annoying. You tell claude to not do any workaround or bypass, it acecpts and does it anyways after the next failed fixing attempt
danieldeusing commentedon May 7, 2025
I get things like this quite often. Other examples where claude code implements
Claude Codes favorite is to create a simplified version of a script, test or whatever.
Basically it does not matter how often you mention it in a prompt or you put this info to memory, at some point claude goes back to do so.
This should be a general rule to not bypass, simplify, simulate, etc. things.
github-actions commentedon Dec 3, 2025
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
github-actions commentedon Jan 3, 2026
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
github-actions commentedon Jan 10, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.