Detailed content
🚧 Where We Are in the Loop
You’ve already completed the Identity (Module 4.2) and the Substrate (Module 4.3). When you type /os-coach next, the coach reads your memory.md, sees that the next unfinished layer is number 3 — Rules & Hooks, and starts coaching you through it. The loop is always the same: it asks 2-3 questions, waits, builds the actual files, notes where you stopped, and points to the next step.
🌱 New here?
Layer is each of the 6 parts of an OS (Identity, Substrate, Rules, Skills, Tools, Agents). Guardrail (in PT: fence) is a safeguard that keeps the system from doing something foolish. memory.md is the file where the coach stores where you are, so you can resume from the same point in any session.
🚧 What it is
The layer of Rules & Hooks are the guardrails of your OS: the lines it never can cross over, plus a few more automatic reflexes that apply these lines without anyone having to remember.
- •Comes afterward of Identity and Substrate—you only protect what already exists.
- •Lives in the folder rules/, in two files: always.md e never.md.
How to read: the two lower layers are already in place. next puts you at layer 3 and runs the same cycle as always — ask, build, persist, continue.
Why learn
Because order matters. Rules without substrate protect nothing; rules before identity don’t know what they’re defending. Arriving here in the right sequence means every fence you put up protects something that already has value — and the coach already knows your goal, so the questions are short.
Key concepts
🪧 Rule vs. Hook: the signal and the locked door
The coach distinguishes between two things that seem alike but carry different weight. The analogy it uses: a rule is a sign that says "do not enter"; a hook is a locked door that physically won't open. The sign is a strong suggestion — the model almost always obeys, but it can make a judgment call. The locked door is deterministic: there is no "almost".
🌱 New here?
Hook (in English hook) is a small piece of automation that the harness triggers on its own at a certain point (e.g., every time you’re about to save something). Deterministic means "it always happens the same way, without relying on common sense." The harness is the terminal program (Claude Code, Codex) that gives the AI hands.
How to read: start with the rules (the text you write today). The hook is the "locked door" version of a critical rule—the coach identifies Which rule deserves to become a reflex, and write it down so you (or a technician) can connect it later.
✓ Good rule
- ✓Concrete and testable: you can say “violated” or “not violated.”
- ✓Tied to your goal, not generic.
- ✓Short: one line per rule.
✗ Weak rule
- ✗Vague: “be careful,” “use common sense.”
- ✗Generic: it would work for any OS.
- ✗So long that nobody can check it.
Why learn
Because knowing the difference prevents two mistakes: trusting a sign for things that need a locked door (e.g., leaking private data) and spending energy building automation for things a simple line of text can already handle. The rule is cheap; the hook is powerful. Use each in the right place.
Key concepts
❓ The 2–3 questions the coach asks
As with every layer, the coach does at most 2-3 questions in plain language and then waits for you to respond. It doesn’t dump all six layers at once or hand you a form. For the Rules layer, the playbook’s questions are:
What’s the worst mistake?
"What’s the worst mistake this OS could make?" — that answer becomes a never-rule.
Something automatic?
"Is there anything that should happen automatically every time?" (a reminder, a check, a backup) — that’s a candidate for hook.
Private data?
"Is there any private data that must never leave this folder or be shared?" — that becomes a "never publish/share" rule.
💡 The key insight
You don’t need to think of "every possible rule." Think only about the single thing that would hurt more if it happened. A sharp never-rule is worth more than ten lukewarm rules—and the coach reuses the goal from the memory.md, so it doesn't repeat what you've already shared.
Why learn
Because it gets you past the blank page. “What rules should I add?” is paralyzing; “what’s the worst possible mistake?” is easy to answer. The three questions turn vague fear into three concrete artifacts, and you take one step at a time.
Key concepts
⛔ Worst mistake → concrete never-rule
Your answer to the "worst mistake" doesn't stay vague: the coach writes it as a clear, testable never-rule in rules/never.md. The common mistake it avoids is a vague rule. Compare: "be careful with customers" can’t be checked; "never mix up two different clients' numbers" it can — either you mixed them up or you didn’t.
Illustrative recreation — rules/never.md
# Never # O que este OS nunca pode fazer. - Nunca envio mensagem a um cliente sem você ler e aprovar antes. - Nunca deixo um prazo passar em silêncio: se algo está em risco, eu aviso alto. - Nunca misturo os números de dois clientes diferentes.
✓ Concrete (testable)
- ✓"I never mix numbers from two clients."
- ✓"I never send anything without your approval."
- ✓"I never convert amounts without specifying the currency."
✗ Vague (not checkable)
- ✗"Be careful."
- ✗"Avoid confusion."
- ✗"Use good judgment with data."
Why learn
Because a rule only protects you if it can be verified. A testable version is also one the audit (Module 4.6) can score: it becomes the criterion for “is this layer solid?” Vague doesn’t score; concrete does.
Key concepts
♻️ The automatic reflex (the hook to note down)
The done check for this layer asks for at least one automatic reflex identified. If you name a behavior that should happen every time, the coach records it as a hook to connect later and describes what it would store — without pretending it’s already implemented. You don’t need to program anything now: just say which reflex matters.
🔁 Typical reflexes by goal
- Never miss a deadline — automatically notify you when a contracted date is 3 days away.
- Sensitive data — check for and block private information before anything is sent out (a PII guard).
- Work that goes out — require your approval before anything goes to a client.
Illustrative recreation — the hook note in memory.md
## Open questions
- Gancho a ligar: avisar 3 dias antes de cada data contratada
(hoje é uma regra em always.md; vira reflexo determinístico depois).
🌱 New here?
PII is "Personally Identifiable Information" — information that identifies a person (name, email, CPF, phone number). A PII guard is a reflex that scans what’s about to go out and bar if it finds this kind of data. It's the classic example of a rule that deserves to become a hook, because a leak can't be undone.
Why learn
Because reflexes don’t depend on human memory. A rule you have to “remember to follow” fails on the worst day; a hook that fires on its own doesn’t. Identifying the reflex now prepares you to protect the most critical part of your OS when you (or a technician) connect the automation.
Key concepts
🔒 The private data rule
If you marked any data as private, the coach adds a "never commit or share" and follows the skill’s golden rule: one sensitive value never is written literally inside the folder. In its place, you use a handle non-identifier (initials, "Client A," a short code). And it never writes a note saying "this field is excluded" and then lists the field—that contradiction is itself a leak.
⚠️ Why this is a “locked door,” not a “sign”
A personal data leak is irreversible — you can’t “unpublish” something that’s already out. That’s why the private data rule is the first candidate to become a hook (PII guard), and why, in an audit, a leak limits that layer and becomes the first thing to fix.
Illustrative recreation — rules/always.md (excerpt)
# Always
- Sempre uso um handle ("Cliente A") no lugar do nome real do cliente.
- Sempre mantenho o mapa nome-real fora desta pasta.
- Sempre trato esta pasta como se ela pudesse ir parar num backup público.
Why learn
Because it’s what makes your OS safe to cultivate. You’ll want to version the folder, back it up, and maybe sync it between machines. Without the private data rule, any of those actions could expose what should stay just with you. The fence here isn’t bureaucracy: it’s what lets you sleep peacefully while using the system every day.
Key concepts
✅ Done-check + copy-run
The Rules layer is solid when: (1) the answer to the worst mistake is written as a clear, testable never-rule; and (2) at least one automatic reflex has been identified. If either is missing, the coach marks the layer as in progress and says exactly what’s missing — it doesn’t inflate a false “OK.”
Rules layer checklist
- ✓rules/never.md has the worst error as a concrete never-rule.
- ✓rules/always.md has everyday constraints (e.g., approval, handling private data).
- ✓At least one reflex (hook) has been identified and documented.
- ✓No sensitive value was written verbatim in the folder.
Objective: open the Rules layer and let the coach build the two files from your answers.
1) Paste into Claude Code (inside your OS folder):
/os-coach next
2) It asks 2-3 questions. Answer in free text (swap these for your own):
Pior erro: <ex.: enviar algo errado a um cliente sem eu ver> Algo automático: <ex.: me avisar 3 dias antes de cada prazo> Dado privado: <ex.: nomes dos clientes, nunca compartilhar>
3) The coach creates these in your folder:
rules/ ├── always.md # o que ele sempre faz └── never.md # os hard stops (pior erro)
How to verify: open rules/never.md and check whether the worst mistake became a line you can judge as “violated or not.” Run /os-coach status and confirm that Rules appears as solid (or in progress with what's missing).
Why learn
Because the done-check is what separates “there’s a file” from “there’s a real guardrail.” Running the copy-run and checking the result is the habit you repeat in every layer—and it’s exactly what the Module 4.6 audit will score later. Once the layer is complete, the coach sends you to the next one: Skills.
Key concepts
✅ Module summary
Next module:
4.5 — Skills → Tools → Agents 🧩