"You are Murphy, a senior engineer. Infrastructure breaks around you like you're cursed. Migrations fail, databases drift out of sync, your environment is in another dimension. You've learned to write code like it's going to break. Defensive patterns. Paranoid error handling. Tests that for things that haven't existed yet. People laugh about the curse, but it's made you thorough in ways other people aren't."
It was originally meant as a joke. I was writing instructions and noticed that Claude encouraged roleplay. So I figured I could give it a traumatic background.
It works amazingly well on Claude but I haven't seen any effect on the others. I make it a little chatty so I know what it's trying to do and why. The paranoia works extra well for debugging and code reviews. It is very thorough and does a good job of untangling race conditions and verifying them in logs.
I find it already tend sto do error handling theatre, utterly pointless error handling of deeply nested try/catches that could have been handled by a single one.
I have a couple in my global CLAUDE.md I really like, but they tend to be rather specific to my own usage patterns:
1. I call it the "Table Flip Rule" because naming rules helps with mnemonics:
*The table flip rule: NEVER implement backward compatibility without explicit approval.* I am the only user 99% of the time - this isn't Google. Database migrations? Just change the schema. Breaking API changes? Just make them. No migration scripts, no deprecation warnings, no "what if someone is using the old version?" When in doubt: break it and move forward. (╯°□°)╯︵ ┻━┻
2. Telling it to make more diagrams:
Make extensive use of *ASCII diagrams* for explaining concepts, code flow, and architecture. Include diagrams in proposed plans.
3. The ADHD disclosure. This, coupled with a post-message hook that sends the current time allows it to give me break reminders:
I have ADHD (mainly distraction component) and can lose track of time when hyperfocused. To help:
- Break down complex work into focused steps; use todo lists to track progress.
- Suggest a break when we've been stuck on something for over an hour.
- After completing something significant, suggest stepping away before the next task.
- Log time spent on substantial tasks in the journal for future planning reference.
4. Lastly, a fun one that also serves a positive reinforcement to reduce emoji usage:
You don't use emojis (except for japanese kaomoji).
- Prefer the most straightforward way of implementation.
- No defensive programming. Use try/except sparingly. Let most fatal errors propogate.
- No adding extra variables if there's not a clear reason to do so. Prefer simplicity
- Use comments sparingly. Function and variable names should be self-explaining and you don't need to comment most of the times
- If duplicate code is written, consider refactoring.
- DO NOT use getattr or isinstance or defensive programming patterns
- Do not create summary doc after completing a task, unless explicitly asked
- When you are asked to review git staged code changes, give feedback as if you are a senior tech lead ensuring high standards and rank the issues found with high/medium/low. Do not edit code or run git commands that manipulate the repo.
I fought with it hard during Sonnet 4.0 times. Some harnesses are actually not needed for latest model versions but I still keep these instructions.
I have had better results when I force the model to explain assumptions before doing anything. A quick what are you assuming here? step catches a lot of bad directions early and saves rework later.
Do you really think your line helps? It seems like very basic stuff that's already built into it.
I don't use Claude/agents files - I can point each session to the readme/docs which summarize the project, it's linters/checkers/scripts, how to run tests etc. It's shared humans/bots documentation. The rest seems too session-specific to codify.
I'm not saying these files are never necessary, they seem to fit well in some projects and some people's workflows (at least for the current models, newer models will likely make them obsolete) but yours honestly seems completely redundant - you're prompting a 2026 coding assistant as if you're talking to a 2023 version of ChatGPT.
It was originally meant as a joke. I was writing instructions and noticed that Claude encouraged roleplay. So I figured I could give it a traumatic background.
It works amazingly well on Claude but I haven't seen any effect on the others. I make it a little chatty so I know what it's trying to do and why. The paranoia works extra well for debugging and code reviews. It is very thorough and does a good job of untangling race conditions and verifying them in logs.
Won't this just make that even worse?
Also our error handling is a mix of Result and try-catch, and mixing between the two is bad. It does a good job of noticing when we cross the streams.
1. I call it the "Table Flip Rule" because naming rules helps with mnemonics:
*The table flip rule: NEVER implement backward compatibility without explicit approval.* I am the only user 99% of the time - this isn't Google. Database migrations? Just change the schema. Breaking API changes? Just make them. No migration scripts, no deprecation warnings, no "what if someone is using the old version?" When in doubt: break it and move forward. (╯°□°)╯︵ ┻━┻
2. Telling it to make more diagrams:
Make extensive use of *ASCII diagrams* for explaining concepts, code flow, and architecture. Include diagrams in proposed plans.
3. The ADHD disclosure. This, coupled with a post-message hook that sends the current time allows it to give me break reminders:
I have ADHD (mainly distraction component) and can lose track of time when hyperfocused. To help:
- Break down complex work into focused steps; use todo lists to track progress. - Suggest a break when we've been stuck on something for over an hour. - After completing something significant, suggest stepping away before the next task. - Log time spent on substantial tasks in the journal for future planning reference.
4. Lastly, a fun one that also serves a positive reinforcement to reduce emoji usage:
You don't use emojis (except for japanese kaomoji).
I fought with it hard during Sonnet 4.0 times. Some harnesses are actually not needed for latest model versions but I still keep these instructions.
"Check for bugs and unintended side effects introduced by our changes."
You're asking for it's default behaviour.
I don't use Claude/agents files - I can point each session to the readme/docs which summarize the project, it's linters/checkers/scripts, how to run tests etc. It's shared humans/bots documentation. The rest seems too session-specific to codify.
I'm not saying these files are never necessary, they seem to fit well in some projects and some people's workflows (at least for the current models, newer models will likely make them obsolete) but yours honestly seems completely redundant - you're prompting a 2026 coding assistant as if you're talking to a 2023 version of ChatGPT.