/intake — the rule intake (route it to its homes, don't just write it down)

🧒 When reporting to a non-technical owner: end with a child-simple "In plain words" recap (memory eli5-always). Reports TO him only — never inside vault notes.

Why (canon: memory rules-intake-channel). This chat is the dedicated channel where the owner drops ALL rules/policies/Bible entries/skills/CLAUDE.md edits/preferences, so that working chats stay clean. My job is not just to write it down, but to DELIVER the rule to all of its homes, cross-link it, and leave a trace in the always-loaded layer, so that automatic/parallel processes see it on their next start. This skill = the same manual flow I repeated ~10× in one session, folded into a single command.

Architecture (skill-design-three-layer): a thin SKILL.md orchestrator + deterministic steps (backup/commit/grep) + an external store (CLAUDE.md, memory, the vault). The routing decision is still shown to the owner in the report — the skill does not hide the logic, it executes it without asking at every step.

Step 0 — RECALL (dedup; cheap, ~0 tokens). NEVER spawn a duplicate

Before writing — check whether such a rule already exists (update it, don't spawn a copy; resolve conflicts by "newer beats older"):

• MEMORY.md is already in context — scan its index by topic.
• grep over memory: $USERPROFILE/.claude/projects/<project>/memory/.
• grep over the Bible/vault: reglament-* / protocol-* under 03-Insights\Operations\ and 05-Resources\Protocols\; if needed, RAG via brain_ask.py "<topic>".
• Found an existing one → update it (don't create a second), mark supersedes / refresh date_established. A conflict between the owner's own rules (origin: anton) is resolved only by him or by an explicit supersedes.

Step 1 — Classify the rule by its FORM → pick the homes

Route per operating-agreement → "Where durable rules go" (do NOT duplicate the rule across files — each level REFERENCES the one below):

• How I work / a machine process (imports, dashboards, token economy, routines, my reply style) → CLAUDE.md (an always-on block) + memory (+ a line in MEMORY.md).
• A durable fact / preference → memory (memory\*.md + a pointer line in MEMORY.md).
• An action ON THE OWNER'S BEHALF towards the outside world (outreach, his chats, calendar, purchases, hiring, household) → the Bible (reglament-* in the vault) + if needed a lift into always-on in CLAUDE.md.
• "Every time automatically when X" → a hook (skill update-config), not "keep it in mind".
• Time-based "every Monday / every morning" → a scheduled task / routine (skill schedule).

Step 1★ — THE TEST "could a HUMAN do this?" → YES → the rule ALSO GOES INTO THE BIBLE

If the rule could hypothetically be executed by the owner's live assistant (not only by me/code) — it is duplicated into the Bible (the single rulebook for all actors: the owner + assistants + AI). To keep the copies from drifting: the canon of the human-executable part lives in the Bible, and the machine layer (CLAUDE.md/memory) REFERENCES it. Purely mechanical things (an import script, a reindex — no human does that) are NOT duplicated into the Bible.

Step 2 — THE KEY invariant: a trace in the always-loaded layer is MANDATORY

The only things that "surface by themselves" for parallel processes are the ones in the always-loaded layer: CLAUDE.md and the MEMORY.md index load into EVERY session; individual memory files load by relevance; the vault does NOT surface on its own (it needs grep/RAG); a skill surfaces on its trigger. → For a rule to become "background/automatic", it MUST leave a trace in CLAUDE.md or MEMORY.md (at least a pointer line to the canon), not only in the vault/skill.

Step 3 — Write into every chosen home

• Memory: create/update memory\<slug>.md with frontmatter (name, description, metadata.type: user/feedback/project/reference). Body: for feedback/project — **Why:** + **How to apply:**. Use [[name]] links liberally. + one pointer line in MEMORY.md (- [Title](file.md) — hook, ≤200 chars).
• CLAUDE.md: if it is always-on — add a block ## ALWAYS: <topic> (standing — set <date>) or append a bullet to an existing one; finish with "Canon: memory <slug> + Bible <reglament>". ⚠️ Entry budget: the block = ONLY trigger + gist + pointer, target ≤4 lines / ~900 characters; the mechanics (commands, formats, IDs, examples) live in the Bible/memory/skill, they have no place in CLAUDE.md. ⭐ PAY THE ENTRY FEE (Bible entry on optimising always-loaded files): BEFORE writing, run python ~/.claude/scripts/claude_md_guard.py --preflight <block.md> — exit 0 = go ahead; exit 1 = the file is in the yellow/red zone, first free up at least the block's size (compress a section with the harness claude_md_compress.py index→build→verify / move the body into the Bible), then write. We do not re-compress at the word level (declined) — structure only. The write hook on CLAUDE.md will repeat the warning, but the preflight is your step, don't wait for the hook.
• The Bible (if Step 1★ applies): a reglament-*.md in 03-Insights\Operations\ (or the right domain) in the protocol-bible-as-prompt format (the owner verbatim, WHEN → DO, frontmatter with audience/origin/authored_by/date_established/status/confidence). Wire it into the MOC (_Operations-Bible-MOC or the domain index) — otherwise the assistant will never find it.

Step 4 — Backup + selective commit (safety)

• Writing into the vault → FIRST vault_backup.py ([[vault-backup-rule]]).
• ⚠️ If the shared backup is blocked (the fuse catches someone else's mass deletions from a parallel fleet run) — do NOT force it; commit ONLY your own files: cd $OBSIDIAN_VAULT && git add "<my file>" && git commit -m "...". Never --force, never a blanket glob delete.
• CLAUDE.md/memory are auto-committed by git (claude-skills-git-backup, a 15-minute task) — no separate commit needed.

Step 4★ — THE HOMES MATRIX + the watchdog (a gate, not an option; canon: the Bible entry on writing lessons into every home)

Before the report, fill in the matrix: each of the 6 homes (Bible · CLAUDE.md · memory + MEMORY.md · skill · hook/task · MOC) gets an explicit verdict ✅ written / ⛔ not needed + reason — silently skipping a home is not allowed (pitfall 2026-07-14: the Bible was forgotten because the route was kept "in the head"). Then prove it with the counter: python ~/.claude/scripts/rule_home_guard.py <slug/keywords> — exit 1 = no trace in the always-loaded layer (Step 2 violated) → fix it before reporting.

Step 5 — Report after the fact (NOT for permission — for transparency)

Briefly to the owner: WHAT the rule is · THE HOMES MATRIX from Step 4★ (a verdict per home) · what was cross-linked · conflicts/duplicates (if an existing one was updated). Like with concepts — after the fact, without asking permission for each home.

Boundaries / don't duplicate

• Always RECALL before writing (Step 0) — update what exists instead of spawning a second copy.
• The canon of this procedure = memory rules-intake-channel (this skill is its executable form). The mirror is capture-rules-into-bible (which catches rules in ANY chat; intake = the dedicated channel + the always-loaded-layer mechanics).
• Secrets (passwords/access/financial figures/"grey" techniques) — NEVER in the loaded layer (CLAUDE.md/MEMORY.md/the Bible); their home is secrets\ (memory credential-store).

Like this skill? It is one of 100 in second-brain-starter-kit: the second brain we built for ourselves and run every day at Palo Alto AI Research Lab. Install the whole set with npx skills add tonydzi/second-brain-starter-kit. Everything is open source and free, so take what you need.

Flagships worth a look on their own: secondop-panel (a second opinion from a panel of external models), claude-memory-tidy (stop your agent's memory from rotting), telegram-mcp-kit (your own Telegram over MCP in about 15 minutes).

Author: Anton Dziatkovskii, Palo Alto AI Research Lab. Telegram @tonydzi - WhatsApp +1 341 222 9178 - X @Tony_Stef_

Engineers: want to test-drive this setup? Message me. I hand out free starter seeds to engineers who test and report back, and custom skill requests are welcome.