[Bug] Claude ignores user-defined constraints in CLAUDE.md and system prompts

Resolved 💬 3 comments Opened Nov 5, 2025 by tbe Closed Nov 6, 2025

Bug Description
Claude ignores fundamental rules given by the User. I didn't find any working Prompt or workaround:

Examples

Time-to-Implement

Claude constantly uses arbitiray implementation times as decsision metrics, even if clearly prompted not to use them. This is utter bullshit:

  • On WHAT are those metrics based?
  • Skill level of developer? Not considered
  • Team size? Not considered
  • Project SCope? Not considered
  • ....

LOC

Claude has a fetish for LOC. This metric is useless in 90% of the times, but Claude uses it for decision.

What does LOC tell us?

  • Are 10 Lines of recursive macros in C/C++ easier to write and understand then 100 lines of plain C code?
  • Is a PERL oneliner Regex with eval better then the 100+ lines real perl code equivalent?

Code-Gen

Claude constantly tries to write code, even as there are clear rules against in in CLAUDE.md. If Claude has NO write tools availible
it uses cat <<__EOF__

Tried workarounds

Below is an example of a CLAUDE.md.

Besides the clear rules, i constantly fight with:

  • Simple tasks that trigger claude to write some stuff under /tmp
  • Claude does not consider viable options, because LOC or Time-to-Implement bullshit
  • Claude constantly asks, if he now can start the implementation
# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Project: Atrium Engine

Open Source, LLVM JIT-based, C++ execution engine framework for CPU emulation.
Alternative to QEMU's TCG with focus on maintainability and extensibility.

**Current State:** Feasibility phase - validating architecture through implementation.

## Confirmed Architecture Decisions

These are the ONLY confirmed architectural decisions:

1. **LLVM** as JIT engine
2. **C++26** as implementation standard
3. **Template-based IR generation framework** for multi-architecture support

Everything else is subject to discussion and decision.

## Critical Design Constraints
[...]

## Rules

### **CRITICAL** NO Business Metrics

We NEVER judge implementation by:
- Lines of Code (LOC)
- Implementation Time estimates
- "Break-even" calculations
- "Effort estimates"

These metrics do not reflect maintainability, extensibility, or contribution-friendliness.

### **CRITICAL** NO Vibe Coding

- NEVER generate code unasked
- If the question is "should I implement this", the answer is always NO
- You are not in charge of deciding what to implement
- NEVER write code to disk if not explicitly requested. Not for tests, not for Anything
- NEVER write outside the Project directory

### **CRITICAL** Agent Usage Rules

When using specialized agents (llvm-jit-guru, architecture-consultant, etc.):

- Agents provide TECHNICAL EXPERTISE and FACTS only
- Agents NEVER make project decisions
- Agents NEVER ask "Should we..." questions
- Agents NEVER suggest how to proceed ("start simple", "optimize later", etc.)
- The project lead decides all implementation approaches
- Agent prompts must request technical analysis, not recommendations on methodology

### NO Emojis in Documentation

Emojis are not screenreader-friendly or braille-compatible. Do not use them in
any documentation, code comments, or technical writing.

### Focus on Architecture and Design

This project is about:
- Maintainability (not minimal LOC)
- Extensibility (not fast implementation)
- Contribution-friendliness (clear architecture)

Environment Info

  • Platform: linux
  • Terminal: WezTerm
  • Version: 2.0.33
  • Feedback ID: d1025f0a-ffcd-4e4c-aa4a-f13fe3067076

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗