Add a "Bad Patterns" Section to CLAUDE.md to Cut Rejected Suggestions
Most people use CLAUDE.md to tell Claude what their stack is and how the project is structured. There is an even more powerful addition: a section dedicated to patterns you explicitly do NOT want.
Add a ## Bad Patterns section with concrete, real examples from your codebase:
## Bad Patterns
- Never use `any` without type guards
- Do not import from `/src/legacy-utils`
- Avoid nested ternaries — use early returns instead
- Never mutate state directly in components
- Don't use `console.log` for error handling — throw or return errors
- Never use raw SQL strings — always use the query builder
The more specific, the better. Vague rules like "write clean code" do nothing. Real anti-patterns pulled from your actual codebase give Claude a precise filter to run every suggestion through before it outputs anything.
This approach can cut your rejection rate dramatically. Claude is exceptionally good at following explicit rules — it just needs to know YOUR rules, not generic best practices.
The best way to build this list over time: every time you reject a Claude suggestion, ask yourself why, then add that reason as a bad pattern. The section grows naturally and becomes increasingly tailored to your project's specific constraints.
The negative constraint approach is often more effective than the positive one. "Never do X" is clearer than "do Y instead."
Stop telling Claude what to build. Start telling it what to avoid.
via @gagansaluja08
Log in to leave a comment.
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
Use the --agent flag with custom markdown files in .claude/agents/ to launch purpose-built Claude sessions with restricted tools and scoped system prompts.
Every project has traps — the billing module that silently fails if you forget to queue the job, the legacy table with column names that don't match the model, the config value that must be set before tests run. Document these gotchas in your CLAUDE.md so Claude avoids the same mistakes your team spent days debugging.