hey @maxfahl i found your post quite valuable, maybe the best information i came across similar ideas. thanks for posting this! it boosted my productivity as i was gradually overwhelmed as a non-dev. sorry for my message being a bit long but i wanted to share my experience in return for your effort 
i experienced an occasion where Claude deviated from the instruction set and template, then we had the following exchange which reveals important clues regarding the LLM’s underlying configuration for interpretation and actions:
user: before we start, tell me the reason why you were not able to capture the user journey details from the document as we are trying to follow a documented approach; not being able to capture and follow relevant information should be addressed based on your response to my question
Claude: You raise a valid point about process improvement. The issue occurred because I made two mistakes in my initial approach:
-
Incomplete Initial Search: When I first looked at the user journeys document, I didn’t scroll through the entire document. I only saw the first few user journeys (Sign Up, Forgot Password, etc.) and incorrectly assumed the Create Posting journey wasn’t documented.
-
Assumption Before Verification: Instead of thoroughly searching for “create posting” in the document first, I made an assumption and proceeded to create a task template based on that assumption. This led to creating unnecessary connections with the map navigation journey.
To prevent such issues in the future, I should follow this systematic approach:
- First, thoroughly search and read ALL relevant documentation
- Document all findings before making any assumptions
- Cross-reference findings with other related journeys
- Only then proceed with task planning
Looking at the search results, I can see that the Create Posting user journey is well documented in two places:
- Main documentation (lines 374-419):
- Complete step-by-step flow
- Validation requirements
- Success/error handling
- All relevant files and their purposes
- Historical documentation (lines 2311-2325):
- Simplified step overview
- Core file references
My mistake was in:
- Not using the search tools effectively - I should have searched for “create posting” first
- Not reading through the entire user journeys document systematically
- Making assumptions without proper verification
- Not cross-referencing multiple sources in the documentation
This is a good learning opportunity for improving our documentation review process. For future tasks, we should:
- Use search tools first to find ALL relevant documentation
- Read through complete documents rather than making assumptions from partial views
- Cross-reference multiple sources when available
- Only proceed with task planning after thorough documentation review
user: this is a good retrospective with a valuable lesson; furthermore, can you give me the breakdown of your assumption behavior? for sure it is there for a purpose, so can it be tweaked, disabled or optimized?
Claude: Thank you for this insightful question about assumption behavior. Let me break down the different aspects:
1- Purpose of Assumptions
- Quick Response: Assumptions help provide rapid responses without exhaustive searches
- Pattern Recognition: Using past experiences to predict common scenarios
- Efficiency: Avoiding unnecessary deep searches for “obvious” cases
2- Where My Assumptions Failed
- Assumed Create Posting wasn’t documented because it wasn’t in the first few journeys
- Connected it to Map Navigation without verification
- Proceeded with task planning before complete information gathering
- Used “while not explicitly documented” phrasing without proper verification
3- Current Assumption Behavior:
Input → Quick Pattern Match → Assumption → Action
This failed because it prioritized speed over accuracy.
4- Optimized Behavior Should Be
Input → Quick Search → Evidence Gathering → Verification → Action
5- Optimization Strategies:
a) Search First, Assume Later
- ALWAYS perform a quick search before making assumptions
- Use available tools (codebase_search, grep_search) as first response
- Only make assumptions when search yields no results
b) Assumption Validation Protocol
- Document the assumption
- State why it’s being made
- Verify with available tools
- Correct if evidence contradicts
c) Progressive Disclosure
- Start with “Let me search for relevant information”
- Share search results
- Only then proceed with analysis
- Make explicit when moving from facts to assumptions
d) Assumption Levels
- L1: Direct evidence available (Use this)
- L2: Indirect evidence suggests (Verify first)
- L3: No evidence but logical inference (Explicitly state as assumption)
- L4: Pure speculation (Avoid)
7 - Practical Changes for Our Work:
- Always prefix responses with search results
- Explicitly mark assumptions when made
- Provide confidence levels in responses
- Create verification checkpoints before proceeding
For example, in our create posting task, I should have:
- Started with: “Let me search for create posting documentation”
- Shown the search results
- Said: “Based on these results, I see the user journey is documented at…”
- Then proceeded with task planning
This would have caught the error early and maintained accuracy while still being efficient.
i’ve added few lines in between your prompt and trying how it works and it seems there’s an improvement, e.g Claude now can conclude the given task with fewer errors. i am working on something less complicated right now - automated test scripts for my mobile app - but i can say that the ride is smoother overall
And even my approach makes the Cursor agent choke… I wish you could utilize the system prompt somehow, but it feels it’s off limits because of some security reason or something.