👇 After this module

Your morning and evening protocols are running. Your energy is tracked. Your content rhythm is set. Your root system knows how you work.

Morning and evening protocols 🌅

A protocol is a sequence of steps your root system runs when you say a specific phrase. You design it once. It runs the same way every time. No willpower required, no forgetting steps.

Your morning protocol activates when you say "good morning" to your root system. It checks your calendar, reviews yesterday's notes, sets today's priorities, and checks in on your energy. All of this happens in the first two minutes of your work day, before you open a single tab or check your inbox.

Your evening protocol activates when you say "wrapping up." It logs what you accomplished, rates your energy for the day, captures any learnings worth keeping, and sets tomorrow's intention. This is how nothing falls through the cracks. Every day closes cleanly.

You design these once. Your root system runs them every day. They become your rhythm.

These protocols are yours to customize over time. Want a gratitude prompt in the morning? Tell Claude to add one. Prefer to check your calendar yourself? Tell Claude to skip that step. The protocol file lives at .claude/commands/morning.md and you can edit it directly or just ask Claude to change it for you in plain language.

How memory stays clean

In Module 2, you learned that nothing expires automatically. Claude has no internal timer. Memory stays clean because two commands work together: /save-session writes everything as you go, and /review walks every layer when you choose to clean up.

Your only job when you run /review is to answer in plain language: keep, promote, delete, still true, drifted. Nothing gets deleted without your explicit approval.

The weekly one: planning

Morning and evening are your daily bookends. There is one more cadence, and it runs once a week. The important part: work is only a quarter of it. You look back at last week across all four languages, notice what got your attention and what got skipped, then choose your three most important actions for the week ahead and make real commitments in Soul, Heart, and Body alongside Mind. That is what gives the week a spine.

Energy and cycle tracking 💪

Your root system can track anything you want to measure about your day. Energy on a scale of 1 to 10. Sleep quality. Whether you moved your body. How focused you felt. Your mood. This is the Body dimension of the Four Languages, and it is one of the most powerful parts of the system.

To set it up, you simply tell your root system what to track. That is it. No apps, no spreadsheets, no habit trackers with notification overload.

Your root system logs this data to your daily files. Over time, you start seeing patterns. Which days you have more energy. What affects your focus. Whether sleep quality correlates with productive days. Whether skipping movement shows up as lower energy two days later.

For those who want it, your root system can also track your cycle. This is completely optional. If it is relevant to you, it becomes another data point that helps you plan your weeks with more awareness.

You choose what to track. Start with one thing. Add more when it feels right. The goal is not to measure everything. The goal is to notice patterns you would otherwise miss.

The Four Languages check-in 🌱

The daily check-in is four questions, one for each language. It takes about two minutes. It keeps all four dimensions visible so none of them get quietly neglected.

Your root system asks these questions as part of your morning or evening protocol. You answer in plain language. "Energy is a 6, slept okay, going for a walk later." "Working on the sales page, need to email Sarah back." That is all it takes.

Over time, this daily check-in reveals something powerful: which languages get your attention and which get neglected. If you notice you always have a strong Mind answer but your Heart answer is "nothing this week," that is information. Not a judgment. Just something to notice.

The check-in is not a test. There are no right answers. It is a mirror that keeps all four parts of your life visible, even on busy days when it would be easy to let some of them disappear.

Your content rhythm ✍️

You have your morning and evening protocols. You are tracking your energy. Now add the third rhythm: content. A simple, repeatable weekly rhythm for making and publishing content that sounds like you, rather than a content strategy deck or a 90-day editorial calendar.

Start with your voice

Before you write a single post, teach your system how you actually sound. Run /build-your-voice once. It reads your real writing, the posts and emails that already sound like you, and builds two files that live in your system from then on.

It builds two files, and it is worth understanding why there are two:

A rules file on its own gets you writing that follows your rules and still reads like a competent stranger who skimmed a summary of you. The corpus is what makes a draft sound like you wrote it, because the system imitates your real sentences instead of a generic idea of good copy. The rubric then catches it when it drifts. You need both, which is why a single tone-of-voice document was never quite enough on its own.

Step 1: See what you already have

Voice is how you sound. The next question is what you keep coming back to. Feed your existing content into your system: blog posts, newsletters, the social posts you are proud of. Your root system reads through everything and surfaces the themes you return to, so you are working from your own back catalogue instead of a blank page.

Step 2: Write with your engine

Now you have your voice files and your themes. /content is the one engine that uses them. Ask it for a post, an email, a newsletter, or a caption, and it reads your rubric and the matching corpus before the first word, writes from your real sentences, then critiques and scores the draft against your voice before you ever see it. What reaches you needs the least editing, and you are still the one who decides it ships.

One command does four jobs. It drafts a post in your voice, checks a draft you paste in and scores how much it sounds like you, sharpens a piece you already have, and sweeps a whole folder for slips before you publish. Whichever job you have that day, it is the same command.

Teaching your system how you sound and enforcing it are two different jobs. /content is the careful writer that gets a draft to near-final. The voice gate hook you set up in the Hooks lesson is the fast mechanical layer underneath it, scanning everything Claude writes to your public pages for banned phrases and slips the moment they land. The engine gets the quality right; the hook makes sure nothing off-voice slips through.

Step 3: Find your content pillars

Content pillars are the 3 to 5 themes you always come back to. Your content analysis already surfaced them. Now you make them explicit.

Your pillars are a starting point, not a cage. When you sit down to create and do not know what to write about, they give you a direction. When you have too many ideas, they help you filter.

Step 4: Plan your week

Once a week, usually on a Monday, you stage the whole week's content in one pass. How many posts, which platforms, and which day each one goes out. A weekly rhythm your root system helps you hold, rather than a spreadsheet you fill in once and forget.

Step 5: Start your content vault

Ideas do not arrive on schedule. They come during walks, in the shower, at 2am. Your content vault catches them all so nothing gets lost.

Step 6: Vault, queue, schedule

The vault catches the idea. Two more commands carry it to published, so you never go from idea to post in one panicked sitting. /queue turns a vaulted idea into a draft in the pipeline when you have a spare minute. /schedule sends a finished draft out when it is ready.

Fit it into your morning rhythm

One last piece, and it lives inside the protocols you built earlier this module. Teach your morning check-in which days you post, so it reminds you at the right moment and you stop holding it in your head. You do not need a separate skill for this. Tell Claude your rhythm in plain words: which days you post and where, when you plan the week, and when you rest. Then ask it to add a content line to your morning protocol.

The four layers of your root system 🪴

You have been building with several different types of files without necessarily knowing how they relate to each other. Your root file from Module 1. Your fact files and memory system from Module 2. The skills you have been running all module. They are all doing different jobs.

Your root system has four layers. Each one solves a different problem, and knowing which one to reach for saves you from building the wrong thing for the situation.

Layer 1: Memory (you already know this)

In Module 2, you built your memory system: fact files, patterns, learnings. Memory tells Claude what is true about you, your business, your preferences, your history. It persists across sessions. Claude reads it for context.

Memory is informational. It tells Claude what is true. It does not tell Claude what to do. Think about how your own memory works: you can know perfectly well that checking your phone first thing in the morning ruins your focus, and still do it anyway. Knowing something and acting on it are different capacities. Claude's memory works the same way. It can remember every preference and every lesson from past sessions, and still not follow them in the moment.

Layer 2: Rules

Rules are instructions Claude reads at the start of every session. They shape how Claude behaves across everything: what tone to use, what to avoid, what to check before acting. Your starter system came with rules like the absolutes (hard behavioral boundaries) and the voice gate (writing style enforcement).

Rules are always on. Claude loads every file in .claude/rules/ automatically. You do not need to trigger them or ask for them.

Layer 3: Skills

Skills are step-by-step procedures Claude follows when you type a command. You have been using them all module: /morning, /evening, /content. Skills are loaded on demand, only when you call them.

Layer 4: Hooks

Hooks are shell scripts that run automatically before or after Claude takes an action. Claude does not control them, cannot skip them, and cannot override them. The system runs them.

A hook can warn Claude ("you just wrote an em dash, fix it") or block an action entirely ("this email contains banned phrases, it will not send").

The key difference: trust level

Memory, rules, and skills all depend on Claude choosing to follow them. Claude can forget a rule. Claude can skip a step in a skill. Claude can miss a fact in memory. These tools work most of the time, but they rely on attention.

A hook does not rely on attention. It runs at the system level. If a hook says "block this," the action is blocked. Period.

Hooks: gates Claude cannot bypass 🛡️

Rules depend on Claude paying attention. Most of the time that works. But when a mistake would be visible to a client, a customer, or the public, "most of the time" is not good enough.

Hooks solve this. They are shell scripts that run automatically, at the system level, outside Claude's control. Claude cannot skip them, forget them, or override them.

A real example

Your starter system includes a rule that says "no em dashes in public content." That rule lives in .claude/rules/ and Claude reads it every session.

In one session, Claude wrote 38 em dashes across an entire website despite the rule being loaded. The rule was there. Claude just did not follow it.

The fix was a hook. The voice-gate.sh script runs automatically after every file edit. It scans for em dashes, banned phrases, and AI-sounding language. If it finds violations, it warns Claude immediately, in the same response, so the fix happens before moving on.

Two types of hooks

How hooks work

A hook is a small script file in .claude/scripts/. You connect it to an event in .claude/settings.local.json. The event tells the system when to run the script. The script tells the system what to check.

You do not need to write the script yourself. Describe what you want to catch, and Claude will write the script and configure the settings file for you.

When to create a hook

Most of the time, a rule is enough. Hooks are for the situations where "Claude forgot" is not an acceptable answer. Three questions:

If all three are true, write a hook. If not, a rule is probably fine.

Put it into practice 🛠️

You now understand the four layers: memory, rules, skills, and hooks. This lesson is where you create your own. Work through each section at your own pace.

Create a custom rule

A rule is a markdown file in .claude/rules/. Claude loads every file in that folder at the start of every session. You do not need to reference them or ask Claude to read them. They are always active.

What a rule file looks like

That is a complete rule file. Save it as .claude/rules/brand-voice.md and Claude follows these instructions in every session, across every task.

Good rules vs bad rules

Create a custom skill

A skill is a markdown file in .claude/commands/. The filename becomes the command name: weekly-review.md becomes /weekly-review. Skills are only loaded when you call them.

What a skill file looks like

Think about something you do repeatedly. Something where you find yourself explaining the same thing to Claude every time. That is a skill waiting to be written.

Modifying existing skills

Your starter system came with skills that were built for a general user. You are meant to change them.

Install the voice gate hook

Your starter system includes a voice gate. Run /voice-gate in Claude Code and it installs the hook for you. From then on it runs automatically after every file edit and catches voice violations before they reach production. To read what it catches, open .claude/commands/voice-gate.md; to tune it, edit the patterns in .claude/scripts/voice-gate.sh or add your own banned words in heart/content-hub/voice-guide.md.

You can check your active hooks anytime by typing /hooks in the prompt.

One principle for all of this: keep only what works

When you update a rule, skill, or hook, delete the old version. Do not keep both. Do not add "v2" sections. One method per task. If the new way works, the old way is gone.