"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.
"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.
Won't this just make that even worse?
It might be an architecture or programming language thing. And I use this prompt more for code reviews and debugging.
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.
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 usually issue this myself, maybe I should add it to my Claude.md, because it almost always finds something to fix:
"Check for bugs and unintended side effects introduced by our changes."
You might not be aware and think it's your Claude file, but CC tends to do almost exactly what you're asking on its own now.
You're asking for it's default behaviour.
It does indeed if it’s in plan mode, kind of just not as detailed. Me being an engineer I can spot certain things or question assumptions it may make
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.
When writing tables in markdown files, text align data in the columns for readability with a plain text editor.
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.