How I talk to AI agents: three mindsets, four meta-skills, and a rules file that shouldn't keep growing

The previous post, Getting Started from Scratch, was about how to install it and get it running.

This post is about using it well. And that is completely different from just getting it to run.

I’ve found that what really determines the outcome isn’t which model you use or whether you can code. It’s how you delegate tasks and how you set up guardrails. The stuff in this post isn’t tied to a specific tool; it applies even if you use ChatGPT (I’ll explain the differences in the last section).

Three mindsets

Mindset 1: It’s like a very smart, but memory-limited new hire

It knows a lot, but it has a limited desk size. Cram too much in, and it’ll lose track of things and forget what you said earlier.

It’s easiest to understand if you think of it like a handoff: hit the key points, be clear, and don’t read the entire chart from start to finish.

So you need to actively help it keep its desk clean: explain a task clearly, and when it’s done, use /clear to start fresh. Don’t let unused stuff pile up along the way.

(Why this happens and how to calculate the costs is something I covered across four posts in the AI Token Economics series, so I’ll just give the conclusion here.)

Mindset 2: Manage it with mechanisms, don’t just rely on its self-discipline

This is where I think most people get it wrong: everyone writes rules in CLAUDE.md and then complains that it doesn’t listen.

The problem is that, according to the official documentation, that file is meant as “reference material,” not “enforced configuration.” The official docs are quite blunt about this:

Claude treats them as context, not enforced configuration.

There are actually three layers of mechanisms to keep it in check, and they vary wildly in strength:

① hooks: Turn rules into code

A hook is a piece of code attached to its lifecycle. The most commonly used one is PreToolUse: before it acts, it runs your check. If your code returns “reject,” the action cannot be executed.

The crucial difference is this: an action blocked by a hook doesn’t bounce back for the model to think up alternatives. It’s not a “discouragement”; it’s an “inability to act.”

I have a hook myself that manages my notes formatting: non-compliant writes are rejected outright, and the model doesn’t even get the chance to write them in. Putting things like this in CLAUDE.md is useless, because it’ll forget them as the conversation gets long.

② permissions: Set up your allowlists and denylists first

The permissions in settings.json have three states: allow (do it directly, no need to ask), ask (ask you every time), and deny (block it outright).

A practical setup for beginners:

• Put irreversible things in deny: deletions, overwrites, sending data out. Better to overpopulate this column.
• Put safe operations you’re sick of seeing in allow: reading files, running tests, looking up data. Put these in allow so you don’t get prompt fatigue and start mindlessly clicking agree (which is the real risk).
• Leave everything else to the default ask.

💡 The most common beginner mistake is feeling that “clicking agree all the time is annoying” and just turning it all off. The right approach is the exact opposite: put safe things in allow so it can do them itself, and put dangerous things in deny so it can never do them. Only the rest require your judgment. Your attention should be reserved for those times when a decision is actually needed.

When you get advanced, you’ll want to turn on “auto mode”. Know the cost first

After using it for a while, you’ll inevitably find that getting asked at every step is too slow. Actually, the default mode is already auto-triage: read-only operations (reading files, searching) don’t ask to begin with; you only get asked when it’s going to touch something. There are a few gears above this: “don’t ask for edits,” all the way up to almost fully automatic. Before you shift up, you need to know three things:

• The “don’t ask for edits” mode also green-lights common file commands like rm (delete). And files deleted by a command don’t go to the recycling bin, nor can /rewind save them, because restore points only cover modifications made via its editing tools.
• So the correct sequence for shifting gears is: set up your deny/ask lists first, then turn on auto mode. For example, set Bash(rm *) to ask, and then no matter what gear you’re in, deletions will always bounce back to you.
• Fully automatic mode isn’t running naked either: there’s a safety classifier in the background that blocks obviously out-of-bounds actions before execution (like irreversibly destroying files that existed before the work started, or sending sensitive data out). But that’s a safety net of last resort; it shouldn’t be your only one. The complete foolproof setup for beginners is covered in Section 3 of the Getting Started series.

③ CLAUDE.md comes last

It’s useful, but it’s the weakest of the three layers, and the longer the conversation, the easier it gets diluted. So what belongs there are “conventions,” not “red lines.” Red lines should go in the top two layers.

I’ll dedicate Section 5 later to how to write this file, because most people (myself included, previously) get the direction wrong.

Mindset 3: Don’t over-veto it, but don’t over-trust it either

This one is the most subtle, but I think it’s the most important.

Its current level is roughly that of a very capable grad student. It reads fast, remembers a lot, knows a bit about everything, and if you delegate something to it, it really can get it done. You don’t need to do everything yourself, nor do you need to micromanage its every step.

But just like a human, it isn’t guaranteed not to make mistakes. And when it messes up, its tone is exactly the same as when it gets it right—that’s the real problem.

I see two extremes, and neither gets things done well:

• Over-vetoing: You’re too scared to hand anything off, so you rewrite every sentence yourself. Then you’re just treating it like a faster typewriter, wasting its true capabilities.
• Over-trusting: You run it and use it directly, pasting it straight into a report. You only realize there’s a problem when something blows up and you discover it hallucinated that number.

The right mindset isn’t “should I trust it?”, but asking: If this goes wrong, how would I know?

If the answer is “I wouldn’t know,” then what you need to do isn’t to stare at it, but to build a checkpoint:

• If it can be coded, code it: Scores, statistics, dates—let code calculate them, don’t let it do mental math.
• If it can be verified, verify it: Does the citation actually exist? Hit an API and ask; don’t rely on its memory.
• Failures must be called out: If a check fails to run, it must explicitly state “this check wasn’t run.” It absolutely cannot quietly skip it. Because a check that wasn’t run reads exactly the same as “checked, and no issues found.”
• Irreversible actions need guardrails: This is what the three layers in Mindset 2 are doing.

In a word: You aren’t a foreman; you’re designing a workflow. Humans make mistakes too, and in the hospital, we don’t rely on “everyone being very careful.” We rely on checklists, double-checking, and machine alarms. The same goes for the AI.

—

How to write prompts now

If you’ve read AI tutorials on the web before, you probably picked up a few tricks. They were useful in 2023, but now they’re mostly a waste of effort:

• ❌ Assigning a persona up front, like “You are a senior therapist with 20 years of experience…”
• ❌ Writing a wall of text, listing every requirement as 1, 2, 3, 4.
• ❌ Manually pasting data in, and adding a line like “only answer based on the content I provided.”

What’s officially emphasized now are three entirely different things:

✅ First priority: Give it a way to verify its own work

This is the number one suggestion in the official best practices. The exact phrasing is to give Claude a check it can run itself: a test, a build, or a screenshot it can compare against.

What’s the difference? For a task with an acceptance method, it will finish the work → run the check itself → see the results → fix it itself if it fails, iterating all the way until it passes. Without it, it can only submit the work when done, leaving you to check if it’s right or wrong.

Translated into a non-engineer’s version:

• ❌ “Help me summarize these transcripts.”
• ✅ “Help me summarize these transcripts into SOAP format. When you’re done, check it yourself: each one must have these four sections, each section must have content, and highlight any missing ones for me.”

That extra sentence is the acceptance criteria. It turns “done” into something that can be verified.

✅ Give concrete context, not commands

The official comparisons are really useful. Four ways to frame it:

See the common thread? They’re all about “what you want, where to look, and what counts as right,” rather than helping it set up a persona.

Role-playing is almost entirely unnecessary now: it already knows how to write a SOAP note. Instead of wasting effort saying “You are a senior therapist,” you’re better off clarifying “who is this for, and what am I going to do with it.” That’s the information it can actually use to make judgments.

✅ Complex tasks: Explore first, then plan, then execute

The official guide breaks the workflow into four stages: Explore → Plan → Execute → Wrap up. The key is that the first two stages must be separated from the third, otherwise you’ll often end up with something that “did a great job, but solved the wrong problem.”

In practice, it’s just one sentence. For complex tasks, add this at the start: “Tell me how you plan to do this first, don’t execute yet.”

Looking at the plan, you’ll spot what it misunderstood. Fixing it now is way cheaper than waiting until it’s done to fix it.

—

Four meta-skills you can use right away

• ① Make something that works first, then iterate: Don’t wait until you’ve learned everything to start. Run a crappy version first and tweak it.
• ② If you don’t get it, ask it: ELI5 / TL;DR: Paste the error message and add “explain it like I’m five.” Faced with a massive wall of text, tell it “give me a TL;DR” before deciding whether to dive deeper.
• ③ Outsource what you can, parallelize what you can: Toss repetitive stuff its way. Plus, you can open two windows at once—one doing the work, the other answering your questions—so you don’t have to just sit there waiting.
• ④ For things that need calculating, never ask it to do mental math: Scale scores, statistics, dates and days—always tell it to “write a script to calculate this for me.”

Point ④ is the one I think the fewest people know about, yet it’s the easiest way things go wrong. It’s a language model, not a calculator. It’ll calculate it wrong and still sound incredibly confident.

Remember this one phrase: Hand it the text, but make it calculate the numbers.

—

Why it gets dumber the longer you chat

Have you ever felt like, later in the chat, it seems to get dumber and starts forgetting what you said earlier?

The truth is: it actually doesn’t have memory. Every time you hit Enter, it rereads the entire thread from “the first sentence up to now” before answering you.

It isn’t remembering; it’s re-reading every single time. So the longer the conversation, the slower and more expensive each sentence becomes. Plus, its total attention capacity is fixed, so fluff dilutes the important stuff. (There’s a study where key information was buried in the middle of a long document, and the recall rate dropped to around 20%. I cover the details and data in AI Token Economics (Part 1).)

In a word: it didn’t break; you just buried the lead.

🙋 Let’s clear up a beginner’s most common anxiety first: “Will starting a new chat make my old stuff disappear?” No. The old chats are still there, and the files are still there. Starting a new one just gives it a clean desk; it doesn’t delete anything.

Three zero-cost habits:

• Start a new chat when changing topics (/clear)
• Don’t mindlessly paste in an entire PDF: Once you paste it, it gets recalculated every single round. You paste it once, and it hurts the whole session. Just let it read the file itself.
• Keep your questions clear and short: It saves your quota, and the answers are actually more accurate.

Helping it keep its desk clean isn’t about saving money; it’s about keeping it in its smartest state at all times.

—

How to write CLAUDE.md (most people get this wrong)

CLAUDE.md is a manual placed in your folder that it reads every time it starts working. Put simply: if you find yourself repeating something every time, write it in there so you don’t have to anymore.

Let me start with the most counterintuitive thing: it’s not better when it’s detailed; it’s more effective when it’s short.

The official advice is crystal clear:

The goal is to keep each CLAUDE.md under 200 lines. Longer files eat up more context and reduce adherence.

A bloated CLAUDE.md will cause Claude to ignore your real instructions.

And there’s one diagnostic phrase I think everyone should remember:

If you explicitly wrote a rule and it keeps ignoring it, it’s usually because the file is too long and the rule got drowned out.

So the approach of “it makes a mistake, I add a line” works in the short term, but in the long run, it breeds a manual that no one (including it) can finish reading, and then all the rules fail at once.

What to do: Use the main file as a router, put the details outside

The correct structure is: the main file only keeps “in what situation to look at which document,” and the details are broken out into their own files, loaded only when needed.

They officially provide two built-in mechanisms:

• @ citations: Write @docs/note-rules.md in CLAUDE.md, pushing the details to that file.
• .claude/rules/: Split the rules into multiple files, and you can even bind them to specific paths, so they only load when you touch those types of files. When irrelevant, they take up zero space.

My own file is currently 93 lines. It contains almost no details, just a table saying “if creating notes → go look at the format rules file; if dispatching a sub-agent → go look at the dispatch protocol file.” The real meat is all out there in seven or eight files, totaling hundreds of lines, but they only get read in when they’re actually needed.

So what should you write, and what shouldn’t you?

And two practical details:

• Don’t handwrite the first version: Type /init in your folder, and it will look over your stuff and generate a draft for you. You just need to tweak it.
• Run /doctor regularly: It will check your CLAUDE.md and proactively suggest deleting paragraphs that “it can figure out by reading the code itself,” leaving only the real pitfalls and conventions.

A final thought: more rules aren’t better; fewer rules are better, as long as those few short ones are actually followed.

—

How I actually use these mindsets in medicine

What I’ve talked about above are still general principles. But I want to talk about what this looks like when these principles actually land in clinical and research work. Because the margin of error for medical content is on a completely different level than “help me write a letter.”

① Evidence levels shouldn’t be asked for; they should be calculated.

My critical appraisal tool outputs GRADE evidence levels. But that level isn’t generated by asking the model “what level do you think this paper is.” The model is only responsible for judging how serious the five domains are. The final level is recalculated by a piece of code following the GRADE rules. The level the model spits out itself is just for reference, and if the two don’t match, it throws a direct warning at me.

This is a mashup of Mindset 3 and Meta-skill 4: the model handles semantic judgment, and the code handles logic and arithmetic.

② References must be confirmed by actually hitting an API.

How unreliable AI-generated citations are is an old story. So before doing any semantic matching, the DOI of every single reference is actually sent to CrossRef to ask, “Does this paper exist?” This blocks not just fabricated DOIs, but the much more insidious “the DOI is real, but it points to a completely different paper.”

③ If a check didn’t run, it can’t be written as “no issues found.”

This is the rule I think is most important, yet least talked about. For every check the tool runs, if it fails (the network is down, the database query comes up empty), it must explicitly state “this check failed to run.” It absolutely cannot quietly skip it. Because a check that wasn’t run reads exactly the same as “checked, and no issues found.”

④ When updating old notes, better to miss something than break something.

Another tool of mine merges new material into existing notes. While designing it, I realized something: missing new content is recoverable (you’ll see that material again later), but quietly changing something that was originally correct in an old note is irreversible, because you won’t ever go back to verify that specific line.

So its principle is “additions are cheap, modifications are expensive”: when old and new phrasings conflict, it doesn’t overwrite directly. Instead, it flags both versions side-by-side and waits for me to make the call.

—

Does this apply to people using ChatGPT or other tools?

Mostly, yes. It’s just under a different name.

Completely universal: The three mindsets, the four meta-skills, how to write prompts (give acceptance criteria, give concrete context, plan before executing), and keeping the chat clean. These are dictated by the nature of language models themselves, not the design of any specific product, so they apply everywhere.

Different names, same things:

What’s currently exclusive to agentic tools: The hooks and permissions layer. Because only tools that “can actively alter things on your computer themselves” need guardrails at the exact moment of execution. Web-based chatbots won’t touch your files, so naturally, they don’t need them.

So if you’re using a web version right now, you can still take these mindsets with you. Someday when you start using tools that can act on their own, come back and review the three layers from Mindset 2.

—

Finally, and most easily skipped: Security

The three-layer mechanism discussed earlier (hook / permissions / CLAUDE.md) manages “what it will do.” This section is about the other direction: what it can touch.

Let’s start with the most basic line

This is a cloud tool; whatever you type in gets sent to a tech company.

• ❌ Involves patient info → Practice with dummy data or de-identified data first.
• ✅ Operations not involving patient info → Use freely: format conversions, writing patient education letters, organizing public data, automating repetitive workflows.

Practice with dummy data to get the feel of it. Once you can judge what’s safe to send and what isn’t, then touch the real stuff.

But what you should really worry about isn’t “what I typed in”

When you start using an agent that can act on its own, the risk takes on a different shape. It can read your files, execute commands, and connect to the internet. Put these three things together, and it means anything on your computer that isn’t locked down is something it might read, or even send out.

I’m not talking theory here; this is something I actually went back and audited myself. I tracked down all the scattered keys, tokens, and passwords, and either re-locked them or revoked them.

I ended up finding four issues, each of which I originally thought was “probably fine”:

• An unlocked skeleton key
• A password casually pasted into a chat
• Two long-forgotten keys sitting in my notes
• A plaintext secret key, paired with an unguarded AI

The full process—how I scanned for them, how I patched them, and a few habits I’ve kept—is written in this post:

👉 When AI can do anything, I went back to double-check the locks on my house

If you plan to let AI touch your work stuff, I’d suggest reading it once before you do. It’s the kind of check that is too late to do after something goes wrong.

And one more thing I want to be blunt about

What these tools produce is material, not conclusions. The evidence level is there to help you orient yourself quickly, not to decide for you whether to follow it. At the end of the day, your name is attached to that clinical judgment, and you still have to read that paper yourself.

—

Having written all this, I can actually circle back to that opening sentence: the hard part was never “how to ask,” it’s “how to design the workflow.” Treat a prompt like you’re talking to a smart colleague: speak plainly, be clear about what you want, and be clear about what counts as done. What you actually need to spend effort on is putting the red lines into the mechanisms, handing off the math to the code, and setting up a checkpoint you can see wherever things might go wrong.

You don’t need to learn it all first; you just need to know how to ask 😊

—