I’ll go first. My new favorite line in my Claude.md. Helps me get around any ambiguity I have with my llm about what is being built or understood by tasks.
CRITICAL: Always make detailed plan with sections for Analysis, specifications, to do list to achieve the spec, and a step by step manual testing strategy for any request a user makes. Always, even when "accept edits on", ask the user to confirm the plan in its entirety. If the user requests changes to any of the plan, make a new plan considering their requests and present it to the user. Never ever start editing files until the user has approved the plan without requesting changes to it. Do not consider the task done until all of the testing Manual Checking strategies successfully passes.
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."
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're asking for it's default behaviour.