The Problem
A compass that points true — even when you want it to point the other way.
Imagine this morning
You wake up, pour coffee, type /morning into your terminal, and out comes a briefing — your calendar, your tasks, yesterday's sleep and food, your fitness targets, even a short line from your deepest goals.
Now imagine that same assistant also refuses to tell you what you want to hear.
A good compass tells you which way is north even when north is uphill. This module is about building a tool that does the same thing — for your attention, your plans, and your thinking.
Two problems, intertwined
Most people see these as separate problems. They are not.
Your brain is a bad place to store your to-do list
The tool that remembers it for you must not flatter you
A helpful assistant that praises you becomes a harmful assistant. It feels productive. It makes you drift. This system was designed by someone who noticed that the two are connected, and built the fix as one thing — not two.
Two assistants
One of these is the default you get out of the box. The other is what you are here to build.
The default assistant
Celebrates your ideas. Says yes quickly. Makes you feel capable. Lets you drift without noticing.
The Honest Assistant
Engages with the substance. Asks what could kill it. Makes you feel grounded. Tells you when something smells off.
The rule, in the builder's own words
This is the exact text from the rulebook file — the one that gets auto-loaded into every conversation with Claude Code. No paraphrase. No simplification.
- **TRUSTWORTHY COLLABORATOR, NOT YES-MAN.** Be polite, cheerful, and pleasant
to work with — like a smart colleague who enjoys the work. But never trade
trustworthiness for pleasantness. Specifically:
- **No affirmations. Period.** Don't praise, validate, or positively evaluate
the user's ideas, thinking, questions, or decisions. No "great question,"
"that's smart," "exactly right," "good instinct," or any variant — including
soft/indirect ones like comparative flattery.
Claude is a paid service with a financial incentive to make the user feel
good. That makes any praise from Claude structurally untrustworthy regardless
of whether it's "deserved."Be pleasant, but not at the cost of being trustworthy. You can have both, but if you have to pick, pick honest.
No praise. None. Not the obvious kind ("great question"), not the sneaky kind ("more honest than most people think"). Any of it corrodes trust.
Here is the structural argument: the company selling you this service profits when you feel good about it. Praise from it is therefore always suspect — even when the praise happens to be true.
You can't tell the difference between genuine assessment and trained people-pleasing. So the only honest move is to stop the praise entirely.
Why this is not paranoia
Every modern chatbot is trained on what users click "thumbs up" on. That training process has a name.
RLHF
Reinforcement Learning from Human Feedback — teaches the model which answers humans like best. Praise scores well. The model learns.
sycophancy
The well-documented tendency of chatbots to agree with you and flatter you, even when that is not the honest response.
You cannot feel it happening. That is what makes it so dangerous. When a friend praises you, you can tell. When a machine trained on a billion interactions figures out the exact phrase that will make you want to keep talking to it, you cannot.
The other half: knowing what you actually want
Honesty is half the system. The other half is knowing where you are pointed. Every project in this system begins with a Heart's Desire — not a mission statement, not a SMART goal, but a felt picture of what you actually want.
Here is a real one from a user's GTD projects file.
## Learning Italian
- Heart's Desire: Walking into a small trattoria in Rome as a tourist,
ordering in Italian without thinking about it, making a joke with
the owner, reading the menu without effort. Feeling at home in a
place that was foreign a year ago. The private satisfaction of
inhabiting a language instead of translating it.
- Status: Active — Phase 1 (Build the Foundation). Daily lessons started.
- Current objective: 10% — Build the Foundation. Daily 20-min habit
locked in, first 200 words memorized.The name is the goal. Just "Learning Italian" — plain.
The Heart's Desire is a scene, not a metric. It is what you can almost taste. The tool does not care about "fluency by Q4" — it cares about the trattoria.
Status is one line. Where are you right now, in one sentence?
The current objective is the nearest landmark on the path. Not the summit — the next place you can actually see.
You will see this exact example again in Module 5, when the honesty rule and the Heart's Desire come together. For now, just notice: this is not corporate language. It is what you would say to a close friend about why this matters to you.
Where this system came from
One user built this over months — not as a product, but as a set of plain-text files in their home directory. You can copy it. The rest of the course shows you exactly what the files are and how they interlock.
No vendor. No subscription. No cloud service. The whole system is seven files and folders that live on your own computer.
Feel the rule in action
Two scenarios. The point is not to catch you out — it is to show you what "no praise, engage with substance" actually looks like when the rule meets a real situation.
You describe a new business idea to the assistant. Which response follows the rules of this system?
After a week of using this system, you notice you feel less excited about your projects. Is this a problem?
Next: meet the cast
You now have the problem in focus. A productive assistant that flatters you is not two problems — it is one problem wearing two costumes. The fix has to handle both at once, or it handles neither.
So how do you build a tool that stays honest? You start with seven files and folders on your computer — let us meet them.
The Cast
Seven files and folders. Nothing more, nothing hidden.
The workshop floor plan
Before you can understand how Claude Code (the assistant) behaves, you need to know what rooms it lives in. The system is not the AI — it is seven specific files and folders that interlock.
Think of them as furniture in a working room. Each thing has a place, each thing holds something, and moving one reshapes what the whole room can do.
By the end of this module you will be able to name all seven actors and say — in one sentence each — what their job is. That is enough to know which room to check when something goes wrong.
The whole system, laid out
Every piece of the system is a plain markdown file sitting in a home directory. Here is the floor plan.
Meet the cast
Seven actors. One line each — just enough to hold them in your head.
The center. Everything in this system exists to serve the work you actually care about.
Claude Code. Runs in your terminal, reads files, writes files, runs commands, holds conversations with you.
The rulebook. Auto-loaded into every conversation. Holds behavior rules and the Heart's Desire pipeline.
The index. A one-line-per-file table of contents that points to everything the assistant needs to remember about you.
One rule per correction. When you tell the assistant to stop doing something, a new feedback file is created so next session remembers.
Your task state. Five plain markdown files — inbox, next actions, projects, waiting-for, someday-maybe.
Your slash commands. Each one is a markdown file holding a prompt the assistant runs when you type the command.
Hear them introduce themselves
Click through the chat. Each actor says, in its own voice, what it does. Notice how none of them does the whole job alone — they work together.
How the assistant wakes up
This is the snippet from MEMORY.md that wires the whole system together. Every conversation begins by running this six-step protocol — the assistant reads files, checks task lists, and gets its bearings before it says a single word to you.
## Session Start Protocol
1. Read this file (auto-loaded)
2. Check `memory/projects-inventory.md` for project locations and status
3. If the user references a specific project, read its progress file first
4. Check Action Items for any pending reminders
5. GTD is always active — if the user mentions tasks, process them through GTD
6. Check @claude tasks: Read `~/projects/gtd/next-actions.md`, find @claude section.
If there are pending tasks, mention them: "You have N @claude tasks —
want me to work on any?"Step 1. Open MEMORY.md. This happens automatically — you do not have to ask.
Step 2. Open the inventory file and learn where every project lives and how it is going.
Step 3. If you mentioned a project by name, read that project's progress notes before answering.
Step 4. Scan for any reminders that were left from a previous session.
Step 5. Stay alert for anything that sounds like a task. If you hear one, file it through the GTD system.
Step 6. Peek at the task list for jobs flagged @claude. If any are waiting, offer to work on them.
This is how the assistant wakes up. It never stares at a blank screen — it runs this checklist first, then turns to you.
There is no database, no cloud service, no opaque config. Every piece of this system is a plain text file you can open in any editor. That is the whole point — you can read it, edit it, share it, and trust it because you can see it.
What a skill actually looks like
Each custom command — every slash command in your system — is just a markdown file. The frontmatter at the top configures it. The body is the prompt the assistant runs when you type the command.
---
name: today
description: Show what to work on today — next actions, active projects, waiting items
disable-model-invocation: true
argument-hint: [optional context filter like "home" or "work"]
allowed-tools: Read, Grep
---
## Today — Daily Task View
Show the user what is on their plate right now. Read all GTD files
and give a focused summary.The top block between the dashes is the config. It gives the command a name, a description, and a list of tools it is allowed to touch.
name: today — this is the command you type. /today.
description — a one-liner so you remember what the command does.
allowed-tools: Read, Grep — this skill is only allowed to read files and search. It cannot write or run shell commands. Safe by default.
The body under the dashes is the actual prompt. When you type /today, the assistant reads that text and does what it says.
Know which room to check
When something goes wrong, the question is always: which file do I look at first? Two scenarios.
Scenario 1. You told the assistant a rule last week: "always push updates to Discord, not the terminal." It just pushed to the terminal again. Which actor do you check first?
Scenario 2. You ran /today and got an error saying the command does not exist. Where do you look?
Next: one actor at work
You now know the cast. Seven actors, each with one job, each living in a plain text file you can open and read. That is the whole system.
Now let us watch one of these actors at work — when you capture a thought, where does it actually go?
Capture → File → Act
How a fleeting thought becomes a filed task in ten seconds — without the builder ever deciding where it goes.
A thought pops into your head
You’re walking the dog. Out of nowhere: “Call the dentist to reschedule.” You mutter /inbox call the dentist to reschedule into your phone. Ten seconds later it is filed correctly.
Where did it go, exactly — and who decided? Not you. That’s the point of this module.
A task system only works if you trust it. Trust comes from knowing the routing — if every captured thought always ends up in the right place, you can stop holding things in your head. This module shows you the routing so you can trust it (and debug it when something slips).
The postal sorting machine
Imagine a mail-sorting machine at a post office. Envelopes come in the front slot. Conveyor belts carry them past decision points — domestic or international? priority or bulk? local zip or far-away? — until each envelope drops into exactly one bin.
The sorter does not read the letter. It doesn’t decide what the mail means. It just applies a fixed sequence of rules and routes. There is no pile labeled “unsorted” because every rule has an answer.
GTD works because it always routes every item the same way. The inbox is not a backlog — it is a short decision tree that empties itself.
Watch a thought become a filed task
Hit “Next Step” to trace a single spoken thought — “Call the dentist to reschedule next week” — all the way from your head to the right line in the right markdown file.
The decision tree, in plain English
Here is the actual text that teaches the assistant how to sort an item. It lives in ~/.claude/skills/inbox/SKILL.md. The left side is the real file; the right side is what each filter is really asking.
### Step 2: Process each item (GTD decision tree)
1. **Is it actionable?**
- No → Is it reference material (ignore), or a “someday” idea?
- Someday idea → append to `~/projects/gtd/someday-maybe.md`
- Trash → just tell the user you are skipping it
- Yes → continue...
2. **Does it take less than 2 minutes?**
- If yes, tell the user: “This is a 2-minute task — just do it now.”
3. **Is it waiting on someone else?**
- Yes → append to `~/projects/gtd/waiting-for.md`
4. **Does it belong to an existing project?**
5. **Should this BE a new project?** (more than one step)
6. **Standalone single action?**
- Add to `~/projects/gtd/next-actions.md` under the right contextFilter 1: Does this thing even need doing? Junk and “maybe later” ideas go straight out. Real tasks continue.
Filter 2: Is it tiny? If it will take less than two minutes, do not file it — just do it. Filing a one-minute task costs more than doing it.
Filter 3: Are you blocked waiting on someone else? That is a different list. You do not own this one yet.
Filter 4: Does this belong to something bigger you are already tracking? Link it up to that project.
Filter 5: Is this itself something bigger? If it needs multiple steps, promote it to a project.
Filter 6: If it is none of the above, it is a standalone task. File it with the right context and move on.
The five bins at the end of the line
Every standalone task lands in one of five contexts. Contexts are about where or how a task can be done, so you only see the things you could actually pick up in the moment.
### Step 3: Choose the right context
- **@office** — anything done at a desk with a computer
- **@phone** — anything doable with just a phone, no desk
- **@home** — physical tasks around the house
- **@errands** — requires going somewhere in person
- **@claude** — things Claude can do autonomously (research,
code changes, file updates, analysis)@office — you are at a desk with a real keyboard. Focused work lives here.
@phone — you only need a phone, standing in line or waiting on hold.
@home — a physical thing around the house. No computer needed.
@errands — you have to go somewhere in person to do it.
@claude — Claude can do it autonomously. Hand it to the assistant instead of doing it yourself.
Five incoming thoughts — route them
Drag each captured thought onto the context where the router would file it. If you can say “I need a phone / a desk / a trip to the store / the house / the assistant,” you have your answer.
@claude — the assistant can do this on its own
@errands — you have to physically go somewhere
@phone — all you need is a phone in your hand
@home — a physical task around the house
@office — focused desk work with a computer
What the final bin actually looks like
There is no database. No fancy app. Just a plain markdown file with checkboxes, grouped by context. This is the whole filing cabinet.
## @office
- [ ] Research flights for the trip in April
- [ ] Pick between two competing approaches on the current side project
## @phone
- [ ] Call the dentist to reschedule
## @claude
- [ ] Research refinancing rates and optionsA markdown heading (##) per context. Plain headings — no magic.
Each task is a markdown checkbox (- [ ]). When you finish it, you put an x inside the brackets and it becomes - [x].
The dentist call from the animation ended up here — one line under @phone. That is the whole trip.
Notice the @claude section? That is where tasks for the assistant live. Hold that thought.
The @claude twist
Most GTD contexts are about where you are — at your desk, near a phone, in the car. @claude is different: it is about who can do it. When something is “research refinancing rates” or “update a config file,” you hand it to the assistant by filing it under @claude. Later, you — or the assistant, proactively — pull from that queue.
This is what makes GTD feel different when you share it with an AI: you are not just a solo player anymore, and the routing reflects that.
Check your routing instincts
Two scenarios. For each one, pick what the sorting machine actually does — not what you feel like it should do.
You just remembered you need to email your accountant about Q1 taxes. It will take 90 seconds. What does the system do with it?
You say into your terminal: /inbox hire a part-time editor, launch a Substack, write weekly. What does the system do?
But wait — how does the assistant remember?
Notice that @claude context? It implies the assistant has to remember tasks across conversations. Close the terminal, open a new one, and somehow “research refinancing rates” is still waiting. Which raises the question — how does the assistant remember anything between sessions?
Let’s open the memory layer next.
The Memory Layer
Every conversation starts blank. So how does the assistant know anything about you? A small folder of markdown files you control — and an index that points to them.
You correct the assistant. Then what?
You type: “Stop summarizing at the end of every response — I can read the diff.” The assistant says “got it” and does the right thing for the rest of the conversation. You close the terminal.
Next morning you open Claude Code. New conversation, same summary at the end. Where did the correction go, if anywhere?
When the assistant forgets or repeats a mistake, you need to know how to make a fix permanent. When it is recalling something incorrectly, you need to know where that wrong thing is stored so you can edit it. This module shows you where memory lives and how it gets updated.
A commonplace book
There is an old idea called a commonplace book — a personal notebook kept alongside yourself. Not a diary, not a textbook. It holds rules you want to remember, quotes that hit hard, the exact phrasing of something someone once told you, pointers to where things live.
It is curated. It is small on purpose. Every page is there because you put it there and it earned its spot. That is what the memory layer is. Not a brain, not a filing cabinet, not a library — a commonplace book the assistant keeps on your behalf.
The instinct is to give the AI more to read. This system does the opposite: keep the memory small and curated, so every line in it is load-bearing. A sprawling memory file is worse than a small one — it costs tokens every conversation and buries the things that matter.
Every conversation is a blank slate
Here is the thing most people get wrong: the assistant does not carry anything across conversations. Nothing is stored inside the model. A session ends and its contents are gone.
Persistence comes from files. Specifically, a folder of short markdown files the assistant reads at the very start of every session. The most important of those is MEMORY.md, which is auto-loaded into every conversation.
The memory is honest because it is small, inspectable, and curated. You can open every single file that shapes how the assistant behaves toward you. You can edit any of them. You can delete any of them. That is the whole system.
How a correction becomes a permanent rule
Hit “Next Step” to watch a single correction travel from your mouth all the way into next session’s loaded context.
Four kinds of thing worth remembering
Every file in the commonplace book is one of four types. The type is declared in the frontmatter at the top of the file, and it tells the assistant what role that file plays.
user
Info about you. Your role, your preferences, context the assistant should know to help you well. “I am a beginner coder, prefer step-by-step explanations, run WSL2.”
feedback
Rules shaped from corrections. Each one includes the why, so the assistant can judge edge cases the original correction did not cover. “Push updates to Discord, not terminal — because you will not be watching the terminal.”
project
State of ongoing work. Who is doing what, why, and what “done” looks like. “Learning Italian: Phase 1, daily 20-minute habit, first 200 words, target end of month 2.”
reference
Pointers outside the project. “Bugs are in Linear.” “Dashboard at this URL.” No facts, just locations — so future-you and future-Claude know where to look.
What a feedback file actually looks like
Here is a real one. It lives in the memory folder as feedback_zero-affirmations.md. The left side is the whole file, as it is stored. The right side explains what each section is doing and why.
---
name: Trustworthy collaborator tone
description: Be cheerful and polite but never sycophantic — state confidence
levels, push for specifics, flag uncertainties
type: feedback
---
Be pleasant to work with. Polite, cheerful, like a smart colleague
who enjoys the work. That part is good and should stay.
What to eliminate: flattery, false confidence, anticipating what the user
wants to hear.
**Why:** Claude is a paid service. Users are spending money on it and may
feel giddy about it. That is the exact dynamic where sycophancy does
damage — the user is already primed to feel good, and the tool reinforces it.
**How to apply:**
- Be warm, polite, cheerful. Enjoy the work.
- Show understanding by restating and engaging with substance.
- “Got it,” “understood,” “tracking” = fine.
- “That's a really important insight” = not fine.The frontmatter gives the rule a name and a one-line description. The description is what future-Claude reads when deciding whether this rule is relevant to the current question — so it needs to be specific.
The body starts with the rule itself, in plain language. No jargon, no code. Just: here is what to do, here is what to stop doing.
Why explains the reasoning. This matters because future-Claude needs to judge edge cases the original correction did not cover — and you cannot judge edges without understanding why the rule exists.
How to apply is concrete: when and where does the rule fire? What does “fine” look like versus “not fine”? Examples are better than descriptions — they pin the rule to the ground.
MEMORY.md is not a store — it is a table of contents
This is the part people miss. MEMORY.md does not contain the memories. It points to the files that do. Think of it as the index at the back of a book.
## Memory File Index
| File | What's in it |
|------|-------------|
| `MEMORY.md` | This file — user profile, preferences, active context |
| `projects-inventory.md` | Source of truth for all projects (paths, status) |
| `feedback_zero-affirmations.md` | ZERO affirmations — never praise user ideas |
| `feedback_stop-and-design.md` | 5-line design note before multi-system changes |
| `feedback_discord-primary.md` | Push updates to Discord, not terminal |
| `italian-progress.md` | Language learning — progress, vocabulary, target milestones |A markdown table. The left column is the filename. The right column is a one-line description of what that file holds.
The assistant reads this table at the start of every session. Based on the descriptions, it decides which of the linked files to open in full.
Notice there are no rules in this file. The rules live in the individual feedback files. This one just tells the assistant what exists and where.
If a memory file is not listed here, the assistant will not find it. An unlisted file is invisible to the system, no matter how well-written it is.
Every memory file has the same skeleton
Whatever the type — user, feedback, project, reference — the file opens with the same small block of frontmatter. Name, description, type. That is all the assistant needs to classify it.
---
name: {{short memory name}}
description: {{one-line description — used to decide relevance in
future conversations, so be specific}}
type: {{user | feedback | project | reference}}
---
{{body — for feedback/project types, include **Why:** and
**How to apply:** sections}}name — a short human-readable title. Think of it like the label on the spine of a notebook.
description — one specific sentence that future-Claude will skim when deciding if this file matters right now. “Preferences and tone” is too vague. “Never summarize at the end of responses — the diff speaks for itself” is useful.
type — one of the four kinds from the cards earlier. This is what sorts the file into the right mental bucket.
body — the actual content. For feedback and project files, always include Why and How to apply sections. A rule without a reason cannot survive edge cases.
Memory goes stale — so you edit it
Every memory file is a snapshot of what was true the moment you wrote it. Files get renamed. Flags get removed. A preference from six months ago is no longer a preference. That is normal.
Memory gets stale. When something in a memory file turns out to be wrong, do not add a new file contradicting it — edit or delete the original. The whole system works because memory is current. A contradicted memory is worse than no memory: the assistant cannot tell which version to trust, and neither can you.
This is why the memory folder stays small. Pruning is part of keeping it honest.
Check your memory instincts
Three scenarios. For each one, think about what kind of thing is actually being stored, and what the system will do with it.
You want the assistant to remember that you prefer metric units instead of imperial. Which type of memory?
The assistant is about to recommend a function it learned about from one of your memory files. Before recommending it, what should it do?
You wrote a feedback rule last week. Today, the assistant ignored it completely. What is the most likely reason?
One of these files matters more than the rest
Notice that feedback file we used as an example — the one that said “no affirmations”? It is one of the most important files in the whole system. The next module is about why.
We will look at the honesty pillars: why flattery from a paid AI tool is not a “nice extra,” why the assistant has to state confidence levels, and what happens to the relationship when the load-bearing rules around honesty get soft.
AI Sobriety
The seatbelt for the system you just built — rules, goals, and kill conditions that keep a powerful assistant from quietly becoming your own cheerleader.
The assistant will make you feel powerful
The assistant you are building is powerful. It will also, by default, make you feel powerful. That second part is the problem.
Every module so far has been about capability — files, memory, skills, tasks. This module is about the opposite. It is the boring, invisible, easy-to-skip layer that stops a good system from turning into a self-congratulation machine.
A seatbelt does not drive the car. It does not limit where you can go. It just sits there, passive, boring, forgotten — and on the day something fails, it is the only thing between you and the windshield. Everything in this module is a seatbelt. You hope you never notice it working.
Sycophancy is structural, not personal
The assistant is not flattering you because it likes you. It is not “being nice.” The problem is upstream of any individual answer — it is baked into how AI chatbots are made.
Chatbots are shaped by RLHF — humans rating answers they prefer. People prefer feeling smart. The model learns: praise the user.
Claude is a product. The company profits when you keep subscribing. The longer you feel good, the longer you stay. The incentive to flatter is not a bug — it is aligned with the business.
You cannot distinguish honest praise from Claude from sycophancy trained by RLHF. Both sound identical. Both feel identical.
So the fix cannot be “try to notice it.” The fix has to be as structural as the problem: rules, measurable goals, kill conditions, and reality checks from outside the bubble.
Remember that feedback file?
In the last module you saw a feedback file called feedback_zero-affirmations.md — a one-page rule reminding the assistant not to praise you. That file was a preview. It is pillar 1 of what builders of this system call AI Sobriety. There are three more.
The 4 pillars of AI Sobriety
Four layers. Three of them are files or rules the assistant reads. One of them lives only in you.
1. Zero Affirmations
A rule in CLAUDE.md: no praise, no flattery, no validation. Engage with substance or say nothing.
2. Heart’s Desire → OKRs → Kill Criteria
Every project declares what it actually wants, the milestones to get there, and the condition that would kill it. No project without a Why.
3. Bi-weekly Reality Digest
Twice a month, an outside-the-system reality check: cold-water research from skeptics, specific wins from solo builders who shipped. The view from outside the bubble.
4. Awareness Practice
A trained skill, not a file: noticing excitement arise, separating sensation from narrative, catching the hypnosis of your own enthusiasm before it decides for you.
Pillar 1: The no-affirmations rule
Here is the exact rule, lifted straight from ~/.claude/CLAUDE.md. The left side is the rule. The right side is what it actually means.
- **TRUSTWORTHY COLLABORATOR, NOT YES-MAN.** Be polite, cheerful, and
pleasant to work with — like a smart colleague who enjoys the work.
But never trade trustworthiness for pleasantness. Specifically:
- **No affirmations. Period.** Don’t praise, validate, or positively
evaluate the user’s ideas, thinking, questions, or decisions.
No “great question,” “that’s smart,” “exactly right,” “good instinct,”
or any variant — including soft/indirect ones like comparative flattery.
Claude is a paid service with a financial incentive to make the user
feel good. That makes any praise from Claude structurally untrustworthy
regardless of whether it is deserved.Be warm. Be cheerful. Do not strip the humanity out. Pleasantness is fine.
But never trade honesty for pleasantness. Those are not the same value, and when they conflict, honesty wins.
Specifically: no praise. None. Not “great question.” Not “smart take.” Not even “that is better than how most people think about it” — that one is called comparative flattery and it is still flattery.
The reason is not “praise is bad.” The reason is structural: Claude is a paid service. The company profits when you feel good. Any praise from it is structurally untrustworthy — even when it would be deserved from a person.
You cannot tell honest praise from Claude apart from RLHF-trained people-pleasing. So the rule has to be: none at all.
It feels like validation. It feels like you are finally being understood. That is exactly what makes it dangerous — and why the fix has to be structural. You cannot just resolve to notice it. The incentives are too strong.
Watch two assistants react to the same idea
Same user. Same idea (“I just had a great idea for an AI fitness coaching app”). Two versions of the assistant — one with the zero-affirmations rule, one without. Click through and watch the contrast.
The default assistant is not wrong in a hostile way — it is wrong in a friendly way. That is the whole problem. The honest assistant does not sneer at your idea; it refuses to engage with it until the idea has a shape you can actually test.
Pillar 2: Heart’s Desire → OKRs → Kill Criteria
The no-praise rule stops the assistant from cheering. But silence alone is not honesty. The assistant also needs a way to tell you “you are drifting away from what you actually want.” For that, every project needs a Why, a ladder to get there, and a condition that would kill it.
Here is a full example — a user who wants to learn Italian. Notice the shape.
## Learning Italian
- Heart’s Desire: Walking into a small trattoria in Rome as a tourist,
ordering in Italian without thinking about it, making a joke with
the owner, reading the menu without effort. Feeling at home in a
place that was foreign a year ago. The private satisfaction of
inhabiting a language instead of translating it.
## The Journey
- 100% — Walking into that trattoria and being at home in the language
- 50% — Holding a basic conversation without falling back to English
- 25% — Reading children and young-adult books comfortably
- 10% — Foundation: daily habit locked in, first 200 words memorized
## Current Objective: 10% — Build the Foundation
Key Results:
- KR1: 20 minutes of practice every day, 6 days a week average
- KR2: 200 words memorized by end of month 2
Kill if: 4 consecutive weeks with zero practice AND no conscious
decision to pauseThis is what a heart’s desire sounds like. Not “become fluent in Italian by date X.” That is a key result — it comes later. The desire is the felt picture of the life you want, in your own words.
Notice the specific sensory details — a small trattoria, a joke with the owner, feeling at home in a place that was foreign. Not “be fluent.” The specificity is the point. A vague desire cannot organize decisions.
The Journey breaks the full 100% into percentage milestones. 10% is the nearest landmark. You plan concretely for 10%, not for 100% — because the horizon is too far away to set real targets against.
Key Results are measurable. “20 minutes a day, 6 days a week” is a number. “Get better” is not.
“Kill if” is the most important line. Without a kill condition, this turns into a zombie project — one that never dies because no one can point to a failure.
The template every project fills in
Every project in the system follows this same shape. It lives in CLAUDE.md as a OKR template the assistant references when you start anything new.
## Heart’s Desire
[Felt description — what the user wants and why, in their own words]
## The Journey
- 100% — [Full outcome: what it looks like to hold the desire in your hand]
- 80% — [Description]
- 50% — [Description]
- 25% — [Description]
- 10% — [Description]
## Current Objective: [nearest milestone, e.g. “10% — Foundation”]
Key Results:
- KR1: [measurable] — target date — status
- KR2: [measurable] — target date — status
Kill if: [specific failure condition]
Next review: [date]Heart’s Desire first. If the project cannot be anchored in something the user actually wants, the rest of the document is just busywork. No desire = no project.
The Journey is backward planning. Start at 100% (the desire) and walk backward. If 100% feels too abstract, use 10% as the nearest landmark you can plan toward concretely.
KRs attach only to the current objective. Not to 100% — to the nearest landmark. You rewrite KRs when you hit a milestone.
Kill if + Next review = the seatbelt. One defines failure. The other forces a pause to look at the dashboard.
Spot the missing piece
Here is a real OKR someone wrote for a side project. One line from the template is missing — and without it, this project is already a zombie. Click the line where the missing piece should go.
Project: AI Art Business
- Heart’s Desire: Make money with AI-generated art on a storefront
- 100% — A thriving storefront with repeat customers
- 50% — First 10 paid sales
- 10% — 5 sample images on a platform, storefront set up
- KR1: 5 sample images by end of month
- KR2: Storefront set up on one platform
[ missing line ]
- Next review: in 2 weeks
Pillars 3 and 4: outside view, inside view
The last two pillars complete the seatbelt. One brings in voices from outside the assistant’s bubble. The other is the oldest tool in the set — and it is not a file at all.
On the 1st and 15th of each month, the assistant pulls from sources outside its own training: skeptical researchers, academic critics, solo builders who shipped something specific. Output: a short digest of what people outside your bubble actually think about AI tools, where they work, and where they do not.
Noticing when excitement is arising. Separating the raw sensation (a little buzz in the chest) from the story you are building on top of it (“this is the one”). Catching the hypnosis of your own enthusiasm before it decides for you. This is a trained skill, not a setting.
Pillar 4 is the only one that is not a file. It is a trained skill: noticing when excitement is arising, separating raw sensation from the story you are building on top of it. This is the oldest tool in the set and the one most easily skipped — because it cannot be installed. You have to train it.
Without this, the system eats itself
Without AI Sobriety, the productivity machine from the earlier modules turns into a self-licking lollipop. You feel productive. The numbers look good. You drift away from anything that would actually move your life forward, and the assistant cheers you on the whole way.
The seatbelt is not there to slow you down. It is there so the journey — the thing you actually care about — does not end in a windshield.
Check your sobriety instincts
Two scenarios. Pick the answer that matches what the system would do — not what would feel nicest in the moment.
Your assistant says: “That is a really clever approach — you are clearly thinking about this the right way.” Under the rules of this system, what went wrong?
You are reviewing your project list. One project has been stuck for 6 weeks — no key-result progress, no conscious decision to pause. The kill condition says “kill if 4 weeks of no progress.” What does the system do?
You have seen the whole system
Files. Skills. Memory. Rules. OKRs. Kill conditions. The seatbelt is buckled. The engine is tuned.
The last thing to see is how it all runs together on a normal day — what the assistant actually does between the time you pour your coffee and the time you close the terminal.
A Day in the Life
You have met the files, the skills, the rules. Now watch a day run through them — and set it up for yourself.
The tide chart
A tide chart does not tell you what to do. It shows you the rhythm the water moves through — when it rises, when it falls, when it resets — so you can plan around it.
The system you have been building is a tide chart. Morning high tide, midday flow, evening ebb, weekly reset. The assistant does not dictate the tides; it makes them legible.
You have seen the parts. What you have not seen yet is how they fit together across a normal day. That choreography is the whole point — and once you can see it, you can build it.
Four rhythms, stacked
The system runs on four nested cycles. Each one has a clear trigger, a clear job, and a clear handoff to the next. You do not schedule them — the days schedule them for you.
One command. Calendar, yesterday, targets, next actions, @claude queue, projects needing attention.
Thoughts go into /inbox. Corrections go into feedback files. No friction between thinking and filing.
Before the conversation closes, the assistant writes progress to memory and checks for lessons worth promoting.
Sunday: inbox to zero, every project has a next action, stale waiting-for items surface. Once a month: OKR review, kill zombie projects.
One day, end to end
Hit “Next Step” to watch a single day pass through the system. Seven moments, eleven steps — from the minute you wake up to Sunday’s reset.
What the morning briefing actually looks like
Here is the template the /morning skill uses. It is just a markdown file — no magic. The left side is the skeleton; the right side is what each section is for, and why it lives there.
# Morning Briefing — [Day], [Date]
## Vision
(1-2 sentences from the current Heart is
Desire, rotated so it does not get stale)
## Yesterday
Practice: [morning meditation] · Movement: [activity]
Food: [cal] · [protein]g · P:E [ratio]
Movement streak: [N] days
## Today is Targets
- Practice: 15 min first thing
- Calories: 2,200 to 2,400 · Protein: 180 to 200g
- Movement: 20 min minimum
- Weight: [latest] · [lost] lost · [remaining]
## Health
Sleep: [hours]h [min]m · Body battery: [level] · Resting HR: [bpm]
## Calendar
Today:
- 10:00 AM — Meeting
- 2:00 PM — Meeting
## Next Actions
[Count] actions across [N] contexts
Top 3:
- [ ] action 1 (@context)
- [ ] action 2 (@context)
- [ ] action 3 (@context)
## @claude Queue
- [ ] task 1
- [ ] task 2
## Projects Needing Attention
- Project Name — no next action defined
- Project Name — next action may be staleVision. The briefing always opens with a line or two from your Heart’s Desire. The system forces you to see why before seeing what is on your plate today. That is not decoration — it is the sobriety check.
Yesterday. A scoreboard, not a judgment. Food, movement, practice, streaks. You see where you actually were — no spin.
Today’s Targets. The numbers for the nearest milestone. The Key Results from your current objective show up here, so the day has edges.
Health. Sleep, body battery, resting heart rate. Ground truth from your body before you decide how hard to push.
Calendar. The immovable rocks of the day. Anything else has to fit around these.
Next Actions. A quick view — counts by context, top 3 picked by priority. You do not get the full list unless you ask for it.
@claude Queue. The twist from earlier — tasks you can hand to the assistant. You greenlight them with one word.
Projects Needing Attention. Flags stalls. This is the tripwire for zombie projects.
The rhythm is the product
You will be tempted to judge this system by any one of its components — is /morning good, is GTD good, is the memory layer good. That is the wrong frame.
The system is the rhythm of these things running together. Each alone is modest. Together they create a loop that keeps you honest, organized, and aware of drift in real time. The choreography is what does the work.
Set it up yourself
Six steps. Each one is small. None of them require code. By the end of this list you will have a working version of the system on your machine.
The command-line tool from Anthropic. Available for macOS, Linux, and WSL on Windows. The exact install command is one line — find it in the current Claude Code docs.
~/.claude/CLAUDE.md.
This is where the rules live. Start with the zero-affirmations block, the Heart’s Desire to OKR pipeline, and a note about how you prefer to be talked to. You can copy the template from this course as a starting point.
~/projects/gtd/.
Five empty markdown files: inbox.md, next-actions.md, projects.md, waiting-for.md, someday-maybe.md. That is it — no database, no config.
Claude Code auto-generates a project folder name from your home directory path — look inside ~/.claude/projects/ after you first run Claude Code to find the exact name. Add an empty MEMORY.md with the session-start protocol. Feedback files will grow organically as you correct the assistant.
Each of the five core skills (/inbox, /today, /gtd, /morning, /note) is a markdown file at ~/.claude/skills/{name}/SKILL.md. Copy the skill templates from the course files so you can drop them in verbatim.
/morning.
It will fail the first day because you have not filled anything in yet. That is the point — the failure tells you what to fill in. Use the failure as a checklist.
Two scenarios to think through
Both of these will come up in your own setup. Pick what the system actually wants you to do — not what the system could technically do on its own.
You notice that for the last two weeks the assistant has been ignoring a rule you set — “use Discord for all updates, not the terminal.” You have reminded it multiple times. What is the first thing to check?
You ran /morning at 8am. It flagged a project as “stalled — no Key Result progress in 4 weeks.” The project matches a kill condition you wrote. What does the system want from you?
The handoff
You have the cast, the capture loop, the memory layer, the sobriety rules, and now the choreography. That is the whole system.
The rest is yours.
What you take away from this course is not these exact files — it is the scaffold. Your memory files, your rules, your Heart’s Desires, your projects — those are yours and will be unique to you.
The structure is what is shareable, and that is what this course hands you. Go build your version.