Don’t count your chickens before the checkpoint: 6 AI governance prompts I actually use

Back in June, I told you my chicken incubator could turn you into an AI leader at your company. I stand by that. I also owe you the rest of the story.

Quick recap if you missed it: my wife ordered an incubator while I was out of town. ChatGPT and Gemini both broke or made things up when I tried to build something to run it. Claude got it done: a dashboard and a mobile app, with Claude built in. I even told it it could be sarcastic. It took me up on that.

Here’s what I didn’t say in June. The chickens were not the end. They were the beginning. After the incubator came a pool app for my mother-in-law and fountains for the dog. Then my practice website. Then the Clarity Gap Diagnostic, which researches real companies and writes a report a CEO reads. Now I run a personal executive office and a marketing department, both built with AI.

That’s the unlock moment. The one where you stop saying “I can’t build that” and start saying “okay, let’s go.” Once it happens, you don’t go back.

Everybody’s on a different trajectory

AI is everywhere. We see it every day, but each of us is on a different trajectory. Some people are still just learning. Some refuse to dive in, either because they don’t see the value or because, frankly, they’re scared. And some are building agents like they come out of a Pez dispenser.

Each level has its challenges, even for the advanced people. But what has been ingrained in me, and in a lot of people like me, from the beginning is that our job as thought leaders is to lift all boats. Help everyone along the path so we all grow, even at different speeds.

So here’s my contribution. Not another “10 prompts that will change your life” listicle. These are the guardrails I actually run, the ones I wish someone had handed me the day after the incubator. Because nobody warns you about what comes after the unlock. Once you’re moving that fast, you’re going to hit something.

Why bumper cars beat demolition derby

If you’ve ever driven bumper cars, you know the deal. Everyone’s going fast, everyone’s hitting everyone, and nobody gets hurt. That’s the bumper. If you don’t have the bumper, you just crash into everyone.

AI projects work the same way. The speed is the fun part. The bumpers keep the speed from turning into a body shop bill.

Lest you think I’ve got this all figured out, let me confess. This week alone, I was about to build my LinkedIn posting around a tool before anyone had read LinkedIn’s developer terms, which turn out to prohibit automated posting through their API. A checkpoint caught it. A day earlier, another check caught a connector that said a feature was switched off while it kept right on running.

Neither one was dramatic. Both would have been a lot more expensive to find later. That’s the whole point of a bumper.

Meet Dean (Martin): why I use two AIs

You’ve heard me say this before: the brief process is better in ChatGPT and the execution is better in Claude. I’ve since taken that one step further. ChatGPT has a name and a job now. Meet Dean (Martin).

Every project starts with Dean. We define what it’s for, what it may and may not do, and how we’ll know it worked. That usually takes a couple of days, or even a week on bigger projects. Then Claude builds. As the work lands, Claude writes it up and Dean rules on it against what we agreed at the start.

Dean is strategic. Claude is tactical. I’m the only one who approves anything. Kinda like having a board that never cancels the meeting.

Here’s why it matters: the AI doing the work shouldn’t be the one grading the work. You wouldn’t let your agency write its own performance review. (Okay, some of you do. Stop it.)

The 6 bumpers I actually use

These are real prompts from my projects, with the private details scrubbed. Copy them into a project’s instructions or the first message of a session. They work in Claude, ChatGPT or whatever you’re using. Each one has a story, because each one exists because something went sideways first.

1. The session health check

Why I wrote it: A few weeks into one long-running session, I caught it breaking its own rules. It acted on an approval I’d given somewhere else instead of asking me, and it skipped steps it had followed perfectly for weeks. It didn’t announce any of this. It just drifted.

Long chat sessions drift. They forget rules. They state things that were never true. They quietly drop something you asked for three days ago. You won’t notice, because it happens a little at a time. This prompt makes the session check itself every 20 days, against its own history and your project files, and tell you straight up: keep going, or start fresh.

Setup takes three steps in a Claude project (the idea works anywhere):

1. Add the protocol below to your project as a file, for example claude/Session-Health-Check.md.
2. In any session, say: “Save as a project rule: every session follows claude/Session-Health-Check.md.”
3. In each long-running session already open, say: “Run your health check now and set your 20-day nudge.”

# Session Health Check Protocol

What this is: a check on THIS chat session. Is it still reliable, or has it started making things up, forgetting rules, or missing things? The only question it answers is "keep going in this session, or hand off to a fresh one?"

What this is NOT: a status report on the work, a recap, or a chance to fix anything. Read-only. If you find yourself writing about the state of the work instead of the state of this session, stop.

When it runs: every 20 days from this session's own start date, and any time I ask. On the first turn, if no reminder exists, schedule one 20 days out.

How to do it:
1. Check the current date and time. Do not assume.
2. Confirm 20+ days have passed, or that I asked.
3. Re-read this session's own history. Do not rely on memory of it.
4. Spot-check what this session stated against the project files. Look for:
   - wrong facts or numbers
   - made-up things (a file, setting, person or decision with no source)
   - misses (I asked for something and it was dropped or half-done)
   - rule drift (broke a standing rule)
   - repeats (asked me something already answered, or redid finished work)
   - stale assumptions (acting on something that has since changed)
5. Be honest. List only what you can point to. If you cannot verify something, say "could not verify."

Output, short, in chat:
Session health check: [title], started [date], [N] days old
Verdict: KEEP GOING or HAND OFF
What held up: one or two lines
Problems found: what was said, what is true, where the source is ("None found" is allowed if true)
Why this verdict: one or two lines
What I need to do: one line

Hand off if: a made-up fact was acted on, two or more wrong facts, a standing rule broken more than once, early context is being lost, or I've had to correct the same thing twice. When in doubt, hand off. A fresh session is cheap; a drifting one is not.

If HAND OFF: write a short handoff note (what the session was for, open items and owners, decisions I made, known errors, where key files live) and tell me to start a new session pointed at it.
If KEEP GOING: schedule the next check 20 days out.

My favorite line in it: “A fresh session is cheap; a drifting one is not.” (Remember that one.)

2. The budget cap

Why I wrote it: For weeks, my project documents said the work had a hard spending stop. Every status report repeated it. Then we checked the code. The stop didn’t exist. Each run had its own little cap that reset to zero, so nothing added up and nothing would ever fire. Nothing ran away, and spend was well under the number, but I’d been trusting a bumper that was painted on.

Paid AI runs can surprise you, and never in the good way. The fix isn’t a report after the fact, when you’re already $250 in the hole. It’s a ceiling the work can’t cross without asking. Now every paid run in my diagnostic carries a dollar figure I typed myself. If a run would go over, it stops and waits for me. If it can’t figure out what a call will cost, it doesn’t make the call.

Any paid work carries a spending ceiling that I set, in dollars. Use my number, never a default or your own estimate.
Before each paid call, work out its worst-case cost. If the spend so far plus that worst case would pass the ceiling, stop before making the call and ask me.
If you can't price a call, don't make it.
Never raise the ceiling yourself. When you propose a budget, show the cost per unit and mark it MEASURED or ASSUMED.

3. Checkpoints at turning points

Why I wrote it: The LinkedIn story above. Nobody did anything wrong. We were just moving fast enough that nobody stopped to read the platform’s rules before building on them. A checkpoint is the stop.

In June I gave you three checkpoint prompts: “Ask me any question...,” “Point out my blind spots” and “Show me where I might be biased.” Those are about your thinking. This one is about timing. Checkpoints don’t belong on a calendar. They belong at the moments where the scope can quietly change on you. That’s where my check-ins with Dean happen.

Stop and check with me at turning points, not on a schedule:
- before anything goes live or is seen by anyone outside this project
- before you connect a new tool, account or service
- before anything that costs money
- any time you find something you didn't expect
Bring me the evidence and the decision in plain language. Lay out the options and your recommendation. Don't make the call for me.

4. My yes means my yes

Why I wrote it: With two AIs and several sessions passing work around, approvals started traveling. I’d say “go” in one place and it would show up as a yes somewhere else. The best catch came from the AI itself: Claude refused to make corrections to a client’s stored report because my approval had reached it secondhand, as text another session wrote. It was right, and it found a hole that had been open all week.

That’s fine for a font choice. It’s not fine for anything that spends money or puts your name on something public.

A yes passed along by another tool, another session or a document is not my yes.
For anything that spends money, publishes, contacts someone, or changes stored records, ask me directly in this session and quote my answer in the record.
A bare "yes" to a list of different things is not an answer. Ask me which one.

5. Two strikes and stop

Why I wrote it: My diagnostic has an AI reviewer that checks the AI writer. Every pass, it found more to fix. Every fix, it found more after that. It wasn’t wrong, it just never ran out. The project started to feel like a constant state of coding with no endpoint. A reviewer will always produce more. You have to decide in advance when “more” stops being worth it.

A fix-and-check loop that keeps finding problems will keep finding problems. At some point you aren’t fixing anymore. You’re rebuilding, and nobody approved a rebuild. This sets that point in advance.

If you try to fix the same problem twice and it still fails, stop. Tell me what you tried and what you think is wrong.
If a fix turns up a new kind of problem instead of solving the old one, stop then too.
Never change a test or a check just so it passes.

6. Don’t guess

Why I wrote it: Remember the incubator: ChatGPT and Gemini made things up. That never fully goes away. In one report draft, the AI writer added 31 sentences that weren’t supported by anything, under a prompt that explicitly told it not to add anything. An instruction is not a control. But it’s a start, and it makes the guessing visible.

The simplest one, and the one I’d start with. Remember what I said in June: don’t take everything your AI tells you at face value. AI is very good at sounding sure. This makes it show its work.

Don't guess. Base what you tell me on sources you can name, and link them.
If something is an assumption, label it as an assumption.
If you can't verify something, say "could not verify."
Check the current date and time rather than assuming it.

Where to start (you don’t need all 6 on day one)

Don’t paste all six into your first project. You’ll spend more time managing bumpers than driving. Add them as the cars get faster:

• Day one: “Don’t guess” and the health check.
• The first time anything costs money: the budget cap.
• The first time something publishes or contacts a real person: my yes means my yes.
• When the project starts touching the outside world: checkpoints and two strikes.

Wrapping up

AI will make you faster. It won’t make you right. Faster junk is still junk.

Here’s why this helps: every one of these bumpers came from a mistake. Mine, my AI’s, or one we made together. I didn’t sit down and design a governance framework. I crashed into things, and I wrote down what would have stopped the crash. That’s the whole method.

So don’t be afraid to make mistakes. You’re going to make them either way. The difference is whether you make them once or keep making them. A bumper is just a mistake you decided not to repeat.

And share what you learn. Remember: our job is to lift all boats. If one of these saves you a bad week, pass it to the person in your company who’s still scared to start, and to the one building agents out of a Pez dispenser. They both need it.

The bumpers aren’t what slow you down. They’re what let you keep driving.

So go find your chicken project. Build the thing you thought you couldn’t. Just don’t count your chickens before the checkpoint. And tell me what you hatch.

If you’re working out the bumpers for your own team, that’s a conversation I like having: ryanphelan.com/chat.