Working well with Claude Code
Claude Code is a collaborator with hands#
Claude Code doesn't just suggest; it runs commands, edits files and uploads to servers. That's powerful, so the way you work together matters as much as the code.
House rules we set (and why)#
| Rule | Why it exists |
|---|---|
| Start each task by naming the project and its folder | Many projects on one phone; no confusion about where things go |
| Every dashboard comes with a link to open it | A page you can't find is a page you don't use |
| A Master Dashboard card for every project | One place to see everything |
| Every HTML page goes in the Web Pages gallery | One searchable shelf |
| Never delete without an explicit request; always back up before changing | Nothing you own gets lost |
| Every subdomain has reference documentation, on its server and locally | Future work starts from facts |
| Every session ends with lessons here | Understanding, not just results |
Memory
Claude Code keeps short notes between sessions (a memory folder). Rules like the ones above are saved there, so a new session already knows "never delete, always back up" without being told again. Memory is for things not obvious from the files themselves: preferences, decisions, lessons learned.
Enforcement beats promises
Besides remembering the no-delete rule, we added a Claude Code setting that makes delete commands (rm, rmdir…) stop and ask for approval. A written rule can be forgotten; a guardrail can't.
Debugging habits that kept paying off#
Across very different problems (Jupyter, PHP, FTP, email), the same habits found the cause:
- Get the real error. Run the failing piece directly. A dying kernel became
ip_resolver.cpp:542; a vague "emailed: false" became "domain is not verified". - Make it small. A two-line test proved ZeroMQ, not Jupyter, was broken.
- When code and behaviour disagree, suspect a cache. The PHP opcache served old code because the storage never updated file times.
- Check what came back, not just the status. A deleted page returned 200, and it was the site's "page not found" page.
- Read what a tool says it did. The API's response revealed a subdomain created one folder too deep.
- Verify secrets without showing them. Print "password: 23 chars", not the password.
Honesty is a feature
Report what was actually tested, what wasn't, and what failed. "Emails aren't being delivered yet; here's why and three ways to fix it" is more useful than "Done!".
Keeping secrets secret#
- Keys live in a
.envfile on the phone and in web-denied folders on the server, never in web pages, chat or these lessons. - Typing a password in chat leaves it in the conversation history; better to put it straight into
.env, and to change any password that was pasted. - This site's build script refuses to publish a lesson if it spots anything that looks like a key, an account ID or an email.
Key takeaways#
- Agree rules early and save them to memory; enforce the critical ones with settings.
- Confirm the project, back up, change the minimum, test, document.
- Debug by getting the real error, shrinking the problem and distrusting caches.
- Say plainly what works, what doesn't, and why.
Quick quiz#
1. Why add a setting when the no-delete rule is already in memory?
Memory guides behaviour; a setting enforces it. Critical rules deserve both.
2. You changed code but the behaviour didn't change. First suspect?
A cache: compiled code, browser or server, serving an old copy.
Try it yourself#
Write your own house rules
List three rules you'd want any helper (human or AI) to follow on your projects. For each, write why. The why is what makes a rule usable in situations you didn't foresee.