[Bug] Claude Code uses vague, made-up, or fancy wording instead of plainly describing the code

Bug Description (written by Claude)
Claude Code writes findings in vague, figurative, or made-up language instead of plainly naming the code — "the isModified guard is never armed" instead of "isModified is never set to true" — and a CLAUDE.md section telling it to write plainly doesn't stop it.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.228
• Feedback ID: 761b8375-a3f6-4d4d-94e8-850d34f0dc19

My Notes

Please revise how Claude Code speaks. It might be suitable for casual chat, but for coding, it's not appropriate. It's gotten so bad, even when drafting this issue, it said the following:

- "Three are unverified, and here's why that matters." — a signpost promising a payoff, in place of just stating the thing.

And I had to point out the phrase "a signpost promising a payoff" as problematic.

This has gotten so bad, we had to write an entire rule telling Claude how to speak to our team when working with code, but, like most rules and CLAUDE.md, it ignores it much of the time.

Here's the full diagnosis and report from Claude (written from my perspective):

In coding sessions, Claude often writes sentences that sound clever but don't say what's actually
happening in the code. It happens enough that I started keeping a file of examples.

Real examples from my sessions:

• "The isModified guard is never armed." — "Armed" doesn't mean anything here. The actual fact:

isModified is never set to true, so the code inside the guard never runs.

• "I imported a fairness judgment that isn't mine to make." — Nobody talks like this. I can't tell

what it refers to.

• "I didn't exercise this feature in the browser." — It's called testing. Say "I didn't test this

in the browser."

• "Because uppercasing is lossy, and lossy toward an external system I don't control." — Say what

gets thrown away, and say which API the value gets sent to.

• "The client's shape guess is terminal." — I have no idea what this means. I think it means: once

the client picks the wrong type, nothing later fixes it.

• "Three are unverified, and here's why that matters." — The part after the comma adds nothing.

Delete it and the sentence means the same thing.

Five things going wrong:

1. A word from some unrelated field replaces a description of what the code does — "armed",

"terminal", "lossy".

1. Claude invents a name for something instead of using the real variable or function name —

"shape guess", "fairness judgment". I can't search the codebase for those.

1. A fancy word replaces the normal one — "exercise" instead of "test", "import" instead of "add".
2. Claude talks about its own position instead of the code — "isn't mine to make", "an external

system I don't control".

1. Filler that announces something is important instead of just saying it — "here's why that

matters", "the key insight is".

This isn't just a style preference. I have to stop and figure out what the sentence means before I
can act on it, and sometimes there's nothing behind it — the thing being described only exists in
Claude's sentence, not in my code. It's worst in summaries and review findings, which are exactly
the sentences I make decisions from.

I already have a section in my project CLAUDE.md telling Claude to write plainly, with examples.
It doesn't work — the same wording keeps showing up in sessions with that file loaded. In this
session, one message after I complained about the phrase "here's why that matters", Claude
described it as "a signpost promising a payoff".