The repo is a small workaround for a now-familiar annoyance: take Claude’s response, pass it through Gemini, and rewrite it into plainer language. The pitch is not better reasoning. It is better reading. That landed because a lot of people say Claude’s recent models, especially Opus 5-era releases, produce code comments, UI copy, and explanations that sound like overcooked social media prose. People described comments that narrate the refactor in progress, preserve temporary planning context, leak internal edge cases into user-facing strings, and generally read like the model is writing to impress the operator rather than help the eventual reader.
The strongest practical advice was to stop treating this as a prompting problem alone. Short word-count limits help more than long style manifestos. Fresh sessions beat long contexts. Once context grows or gets compacted, Claude starts ignoring style rules and drifts back into its default voice. Several people said the only reliable fix is deterministic enforcement. They ban comments by default, add hooks or linters for anything measurable, or make the model write tests that fail when it slips. A recurring theme was that comments should survive without the diff. If they explain the current change, they belong in the commit body, not in code.
The mood was sour toward Anthropic more than enthusiastic about Claudette itself. People see the tool as a bandage for a product problem. Some think Anthropic trained or tuned Claude toward an upbeat, anthropomorphized assistant persona that is good for engagement and bad for real work. Others think the style is just collateral damage from optimizing coding benchmarks, token use, or safety behavior. Either way, many said they have already moved to older Claude versions or competing models for cleaner prose. The useful conclusion was blunt: if you care about readable code, docs, and UX copy, assume the model’s default style is unstable and put guardrails outside the model.
If Claude’s tone is slowing your team down, treat style control like a build constraint, not a prompt wish. Keep sessions short, enforce terse output with hooks or linters, and reevaluate whether Claude is still the right default for coding and docs in your stack.
Strongly negative toward Claude’s current writing style and mildly skeptical of the posted tool as a real fix. People are frustrated by verbose, self-important prose, stale context leaking into code and UI text, and the need for hacks around a product they feel should handle this natively.
Key insights
01
Comments should survive without the diff
Inline comments are being polluted with change narration, legacy behavior notes, and references to transient planning docs. The useful standard is a survival test: if a comment only makes sense next to the current diff or PR, it is changelog text in the wrong place and should be deleted or moved to commit history. That reframes the problem from "Claude is too verbose" to "Claude confuses working notes with durable documentation."
Add a review rule that every new comment must still be true and useful a year later. If it mentions what changed, what used to happen, or an issue tracker artifact, reject it automatically.
Once the context window fills up, style control degrades fast. People reported that compacting often strips away exactly the constraints they care about, while starting a fresh session at a token threshold keeps output much cleaner. The exception was orchestrator-style use, where compaction can work if the session is mostly a planning hub and the compact step is guided carefully, but that is a specialized workflow, not a general fix.
Set a visible context budget and restart sessions before they get large. Use compaction only for workflows where preserving plan state matters more than preserving exact style behavior.
Prompt reminders get ignored. Deterministic checks do not. The highest-signal advice was to move any style or codebase rule that can be measured into hooks, linters, or tests, because models respond much more reliably to concrete failures than to another paragraph in CLAUDE.md. Several people are already having the model generate those enforcement tools once a rule is known.
Turn recurring complaints into machine-checkable rules. Start with banned comment patterns, string length caps, or prohibited phrases, then fail commits or CI when they appear.
The problem is not just verbosity. It is audience confusion. People pointed out that Claude often writes code comments, docs, and UI text as if the future reader shares the entire conversation and all the model’s internal concerns. That is why it spills implementation edge cases into tooltips and labels, or writes docs that feel like hype instead of reference material.
Review AI-written text by asking who it is actually for. For product copy and docs, force a separate pass that strips internal context and keeps only what the outside reader needs.
There are signs Anthropic knows this is a problem. People mentioned a concise mode, promised improvements, and community style repos that try to redirect Claude’s voice. But the consensus from hands-on use was that these controls are fragile. They help early in a session, then the model slides back into the same stock register. That makes them useful as nudges, not reliable controls.
Use built-in concise modes and style files as first-pass defaults, but do not count on them for consistency. Pair them with reset points and enforcement outside the model.
A few people pushed back on the outrage and said the prose problem is overblown outside power users. If you are focused on task completion rather than reading every sentence, the style can register as mildly annoying at most. That matters because it suggests Anthropic may rationally prioritize coding performance and mainstream usability over polishing a problem that mostly hurts heavy interactive users.
Do not assume your team shares the same pain threshold. Measure whether the style issue is actually slowing throughput before investing in custom tooling around it.
Several people thought the project solves the problem in the most expensive way possible. If your goal is only to rewrite tone, a local model, a cheap sidecar model, or even a better system prompt may get most of the value without paying a second frontier model to paraphrase the first. That criticism shifts the question from "does this help" to "is this the right place in the stack to fix it."
Before adding a second paid model, test a local rewriter or a simple postprocessor on your own outputs. The style cleanup step is cheap enough that it should compete on cost, not just convenience.
The blanket claim that compaction is useless did not hold for everyone. In long-running orchestrator sessions that manage plans, delegate subtasks, and review results, compaction can preserve enough project state to beat constant restarts. It is lossy, but when the session’s job is coordination rather than exact wording, that trade-off can be worth it.
Match session strategy to the job. Use fresh sessions for implementation and writing quality, but keep compaction in play for higher-level project coordination if re-briefing is the bigger cost.
github.com