"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 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).
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 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).
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.