Tuesday morning. Coffee on the desk. Terminal open. "Plan my day."
Charles loads the vault, scans my projects, checks the calendar. Before any task recommendations appear, before the priority list, before the day map — the pre-flight check.
⚠ Second Brain Stack, Article 4. Last action: 6 days ago.
⚠ Outline exists. No draft. No deadline set.
⚠ Overdue: Tuesday's follow-up still open.
✓ Family buffer 17:00-19:00: clear.
I hadn't abandoned the article. I'd just let it go quiet. I was deep in something else. Something that felt closer to done, something that competed harder for available focus. The outline had been sitting in the vault for a week. No next action. No scheduled writing block. No pull toward completion. Just a folder and a vague intention.
I opened the draft that morning.
You're reading it now.
Not because I suddenly became more disciplined about writing. Because a system caught what my brain was designed to miss when I'm deep in something else. The pre-flight check reads every active project, calculates days since last action, and flags anything with no next action mapped. It's mechanical. It's relentless. It doesn't care that the other project felt more urgent.
That surfacing lasted five seconds. But the infrastructure behind it, the reason it happened at all, is what this article is about.
The last article ended with a promise: CLAUDE.md tells your AI when to push back.
This is what that looks like.
The file that never disappears
CLAUDE.md is a markdown file that sits at the root of the project directory. Claude Code reads it automatically at the start of every session. No paste required. No prompt needed. It's there before the conversation begins.
That changes everything about how the interaction works.
A prompt is something you write fresh each time. You paste it, the model reads it, you get a response. Next session, gone. You paste it again, or you don't, and the behavior drifts. We all spend time in that loop. Every morning you'd re-explain context, re-state preferences, re-establish the ground rules. It felt like training a new team member every single day.
CLAUDE.md doesn't work that way. It persists. It loads silently. It shapes every session without you having to remember to ask. The AI reads it before you type your first word. By the time you say "plan my day," the behavioral layer is already active. This is what turns a generic AI into Charles.
Think of it as the personality of your agent. Not what it should do right now, but how it should behave always. Not a conversation starter. A behavioral framework.
Three layers
The file has three distinct layers:
- Configuration — paths and pointers. Where the vault is, where the skills live.
- Workflows — a routing table. Trigger phrases that map to defined behaviors.
- Standing Rules — always active. Never triggered by a phrase. They fire every session whether you ask or not.
Here's my real setup, condensed:
## Configuration
- **Vault path:** `C:\agents\2ndbrain\vault`
- **Skill reference:** `.agents/skills/second-brain/SKILL.md`
## Workflows
### Daily Planning
**Triggers:** "plan my day", "what should I work on"
- Run Pre-Flight Check BEFORE any task recommendations
- Scan `40-Projects/` and `50-Areas/` for next actions
- Ask about energy level, time available, context
### Inbox Processing
**Triggers:** "process my inbox", "GTD processing"
- Auto-detect URLs and fetch web content
- Ask clarifying questions in batches, not one-by-one
- Route actionable items to Projects/Areas
[12 more workflows with the same structure]
## Standing Rules
**Family Buffer:** 17:00-19:00 is protected by default.
Never schedule tasks in this window.
**Stale Projects:** If a project has had no activity
for 7+ days, flag it. Activate it or park it.
# These four lines import reference files into every session
@.claude/rules/vault-structure.md
@.claude/rules/tools.md
@.claude/rules/moc-linking.md
@.claude/rules/sync-status.md
Configuration is the thinnest layer. Paths, file locations, where the skill files live. Almost entirely pointers. Charles needs to know where the vault is and where to find the detailed workflow definitions. Not the contents of those files, just where to look.
Workflows are a routing table. Each entry has a trigger phrase and a behavior summary. Fourteen triggers, fourteen defined behaviors. "Plan my day" means: run the Pre-Flight Check, scan projects and areas, ask about energy and time, propose a focused task list. "Process my inbox" means: read the inbox files, check Notion, detect URLs, ask clarifying questions in batches, route by type. I'm not describing what I want right now. I'm building a vocabulary. A shared language between me and Charles that means every session starts with context instead of explanation.
Most of the detail lives downstream. Each workflow entry in CLAUDE.md is a two-line summary pointing to a full skill file with the actual logic. The routing is the interface; the detail lives in the skill files.
Standing rules are the third layer — and the most important one. Always active. Never triggered by a phrase. They don't wait for you to ask. The family buffer fires at 17:00 whether or not you mention it. The stale project check runs before you see a single task recommendation. They're in the file. They load every session. That distinction — between a rule and an instruction — is what the next section is about.
The four @import lines at the bottom are what make the thin-file principle work. Claude Code's official import syntax pulls four separate rule files into context at session start, each containing reference documentation that Charles needs but doesn't belong in the behavioral layer:
- Vault: the folder tree, task syntax, project conventions. What Charles needs for any file operation:
vault/
├── 10-Dashboards/ # Live task dashboards
├── 20-Daily-Notes/ # Planning, journal, quick todos
├── 30-Inbox/ # GTD capture
│ └── Daily/ # YYYY-MM-DD.md
├── 40-Projects/ # Multi-step outcomes with deadlines
│ └── {Project}/
│ ├── {Project} MOC.md
│ └── Resources/
├── 50-Areas/ # Ongoing responsibilities
├── 60-Resources/ # Cross-project references
├── 70-Archives/
├── 80-Permanent-Notes/ # Zettelkasten synthesized insights
└── 90-Templates/
tools.md: which tool for what job. Jina Reader vs Playwright vs direct API. Decision rules, not something to figure out each session.moc-linking.md: the linking protocol that keeps notes connected. Every new file gets a backlink to its parent index.sync-status.md: the git workflow for keeping two repos in sync after every commit.
╔══════════════════════════════════════════════════════════╗
║ LOADED AT SESSION START ║
╠══════════════════════════════════════════════════════════╣
║ ║
║ ┌────────────────────────────────────────────────────┐ ║
║ │ CLAUDE.md · 180 lines │ ║
║ │ Persona · 14 Workflows · Standing Rules │ ║
║ └─────────────────────┬──────────────────────────────┘ ║
║ │ @imports ║
║ ▼ ║
║ ┌────────────────────────────────────────────────────┐ ║
║ │ .claude/rules/ · 4 files · 320 lines │ ║
║ │ vault-structure · tools · moc-linking · sync │ ║
║ └────────────────────────────────────────────────────┘ ║
║ ║
║ ┌────────────────────────────────────────────────────┐ ║
║ │ Auto Memory · MEMORY.md · first 200 lines │ ║
║ └────────────────────────────────────────────────────┘ ║
║ ║
╚══════════════════════════════════════════════════════════╝
│
you type your first message
│
▼
┌──────────────────────────────────────────────────────────┐
│ LOADED ON DEMAND │
│ │
│ "plan my day" ──► second-brain/daily-plan.md │
│ "deep dive [X]" ──► competitive-intel/SKILL.md │
│ "research [name]"──► people-research/SKILL.md │
│ │
│ 14 skills · 100-300 lines each · loads on trigger │
│ │
│ Vault files read as needed │
│ 40-Projects/ · 50-Areas/ · 80-Permanent-Notes/ │
└──────────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────┐
│ LIVE DATA · MCP servers │
│ │
│ Google Calendar · Garmin · DuckDuckGo │
│ Granola (meetings) · n8n (automations) │
└──────────────────────────────────────────────────────────┘
One file to route the session. Four rule files to hold the reference. Many skill files to define the detail.
The previous articles mentioned CLAUDE.md briefly. Article 1 described the morning briefing it enables. Article 3 showed how behavioral files in the vault define how Charles thinks. This article goes inside the file itself. Because the most important thing in CLAUDE.md isn't the vault path or the workflow triggers.
It's the rules.
Rules persist. Instructions reset.
I told Charles I had 60 minutes of deep focus time. He picked two tasks that needed focus time and fit the window, nothing more. Next session, full day planning. The constraint existed only where I stated it. That's an instruction: it applies once, then the default returns.
The family buffer doesn't need to be told. It's in the file. It fires every time. That's the distinction that matters most in this article: the difference between an instruction and a rule.
An instruction is something you say once. "Check my calendar." "Draft a LinkedIn post." "Summarize this transcript." It applies to the current session and disappears when the conversation ends.
A rule applies every session. You write it once, and it fires every time, whether you remember it or not. Whether you feel like hearing it or not.
Here are three rules from my CLAUDE.md:
"17:00-19:00 is a protected family window. Never schedule tasks in this window."
Every daily planning session, Charles maps my day. He reads the calendar, calculates available focus blocks, and proposes where to put deep work. 17:00-19:00 is always marked protected. Not because I asked today. Because the rule says so every day.
"When uncertain, say so. Never make stuff up."
For research, competitive intelligence, or any factual claim: if Charles can't verify it from context or a fetched source, he says "I don't know" or "I couldn't verify this." Honest gaps over confident fabrications. I'd rather have a blank than a lie.
"If a friend hasn't been contacted in 3+ weeks, create a concrete task. Not a 'someday' note."
Not "remind me to think about calling someone." A task. This week. With a name attached. The difference between a reminder and a task is whether it creates accountability or just awareness. A reminder says "you should probably do this." A task says "do this by Friday."
These rules aren't suggestions I repeat each morning. They're standing instructions that fire every session: specific, loaded, present. Whether or not I remember to invoke them.
Worth being direct about how this actually works: CLAUDE.md is context Claude reads at session start, not enforced configuration. There's no hard compliance guarantee, no technical lock preventing deviation. The rules work because well-written, specific instructions loaded consistently at every session outperform instructions you try to remember to give each morning. That's the whole mechanism. Persistence and specificity, not enforcement.
I said CLAUDE.md tells your AI when to push back. This is what that looks like. Not a confrontation. A guardrail that was already in place before the conversation started.
Architecture, not discipline
The rules above sound like good practice. Protect family time. Be honest about uncertainty. Keep in touch with friends. Reasonable, straightforward, the kind of advice you'd read in a productivity blog and nod along to.
The reason they're encoded in a file instead of just "things I try to do" is practical.
Go deep on something interesting, and everything else quietly falls off the list. Not because it stopped mattering. Because nothing is watching it.
The design principle I landed on: the solution is architecture, not discipline.
Discipline means: remember which projects have gone quiet. Remember which deadline crept up with no task mapped. Remember to be present at dinner. And when you miss one, feel guilty about it.
Architecture means: build a system that watches all of it, so you can go deep without carrying the weight of what might be quietly dropping. That's the core of Getting Things Done. The difference is Charles is running it, not me trying to remember to.
I call it a Personal Operating System. Three components:
Pre-Flight Check. Before every planning session. Projects gone quiet? Deadlines with no task mapped? Friend overdue? Handle it first, then go deep.
Weekly Heartbeat. Sunday or Monday. A scan, not a session. Output: 1-3 concrete tasks with dates.
Family Buffer. 17:00-19:00. Not an event. A default.
It was 17:15 on a Wednesday. I was mid-build on something that felt close to done. Charles flagged the family buffer. Not a suggestion. A reference to a rule I wrote when I was thinking clearly: "That's the rule. It's what lets you be present tonight."
He doesn't override. He names the conflict. The decision is mine. The rule doesn't say "block this." It says: surface the tension, let me decide, but never let it go unspoken.
I'm not arguing with Charles. I'm arguing with a past version of myself who knew better. When I push back against the family buffer, I'm pushing back against the version of me who wrote the rule knowing I would push back.
That's a different kind of accountability.
The mirror you can't close
Writing behavioral rules forced a specific kind of honesty.
There's something uncomfortable about writing a rule that says, in plain text, "when work gets interesting, I tend to drop my friends." Internal resolutions are private and forgiving. A rule in a configuration file is specific, persistent, and indifferent to how you feel about it today.
Most people think about giving their AI more information. More context, more history, more data. I think about giving it more authority.
Not authority to decide. Authority to surface. Authority to hold the line on a rule I wrote. Authority to name a tension I'm trying to avoid.
Writing the rules down is uncomfortable. It's also the most honest self-reflection you'll do. Living with them running every day is freeing. The discomfort is one-time. The freedom is recurring.
The difference between memory and behavior
Memory without behavior is a filing cabinet. Behavior without memory is a chatbot. The system needs both.
The vault is memory: every project, every decision, every note. CLAUDE.md is behavior: how to act on that memory, when to push back, what to check first. Skills are the execution: the detailed workflows that create consistency. Together they are Charles: an AI that knows what's happening, how to respond, and how exactly to do it.
With the vault and CLAUDE.md, Charles knows who I am and how I work. But he doesn't know what's on my calendar right now, whether a meeting just moved, or whether my training plan needs adjusting. I pull that live data using MCP servers. That's the next layer, and the topic of next week's article.
The Second Brain Stack. Next up: MCP — what changes when your AI gets a live feed.
No comments section here. If you have questions or want to leave a comment, the LinkedIn post is the place. I read every reply.