Everyone's Building AI Commands. Nobody's Building the Layer Underneath
I’ve been building a context management system in Claude Code — Anthropic’s CLI that works directly with your files — and Obsidian for months. (Previous post covered the modular rules architecture — this one is about what sits underneath it.) Memory architecture, modular rules, enforcement hooks, session protocols. It works — not because I found the right commands, but because the underlying scaffolding holds everything together.
At some point I got curious how other people were approaching this. I bought an AI influencer’s “operating system” to see. Bespoke prompts, slash commands, custom rules, Obsidian templates — genuinely well-made. But it wouldn’t work for me — not because it’s bad, but because I’d have to gut it and rebuild it around my own context before any of it was useful.
What made my system work wasn’t the content — it was the architecture underneath. Memory, enforcement, context loading. None of that existed in what I bought. And it’s missing from most implementations I’ve seen since. Everyone’s building the content layer (commands, templates, folder hierarchies) but not the engineering layer that makes it reliable across sessions and contexts.
So I extracted the scaffolding from my system and open-sourced it. Free, because there’s no right or wrong way to organize your work — and the layer that makes any approach reliable shouldn’t cost money.
The Template Trap
There’s a growing market for these systems. Folder structures, slash commands, rule files, Git repos — packaged as products, priced like courses. Some are role-specific (PM commands for PMs, developer workflows for developers). Others are generic starter templates.
The problem is the business model, not the quality. Selling a finished system assumes the value is in the content — the commands, the templates, the folder hierarchy. But you’re going to rework most of it before it fits your actual workflow. Your role is different, your org is different, the tools you use and the cadence you work at are different.
What actually matters is the architecture underneath. Memory that carries state between sessions. Enforcement that blocks mistakes instead of politely suggesting you not make them. Context loading that swaps rules in and out based on what you’re actually working on. None of that is role-specific, and I haven’t found a paid system that includes it.
The pattern I keep seeing: elaborate command libraries with no memory layer. Close the terminal, open it again, and Claude Code has no idea what you were doing yesterday. That’s a command palette, not an operating system.
The Architecture
Memory is the layer nothing else works without.
Two markdown files in your vault, at different cadences. Work state tracks per-project status — what’s active, where you left off, when you last touched it — and updates every session close. A second file tracks decisions, patterns, and open threads, the slower stuff that only changes when something actually shifts. A session protocol governs the transitions: detect close signals, update state, confirm what changed.
A single memory file either gets too noisy (every session dumps into it) or too stale (you forget to update it). Two files with different update triggers solve both.
Context loading keeps the rest focused. Each rule file declares which file paths it applies to — rules for one project load when you’re working on it and stay out of the way when you’re not. A small core loads every session and everything else loads only when relevant. (Earlier post covers the modular architecture in depth.)
Enforcement turns suggestions into guarantees. Frontmatter — the structured YAML header on each markdown file, properties like type:, context:, parent: — is how the vault stays organized. A rule saying “every note needs a type property” is a suggestion until something validates it. A hook that checks after every file write and blocks when it’s missing — that’s enforcement:
type=$(sed -n '/^---$/,/^---$/p' "$FILE" | grep '^type:' | head -1)
if [ -z "$type" ]; then
echo "BLOCKED: Missing 'type' property in frontmatter"
exit 1
fiInstruction-only rules let violations accumulate silently for weeks, but hooks catch them at creation.
Identity comes from the setup interview. It generates a thinking-partner file calibrated from a conversation about how you work, not from a template with [insert domain here]. Mine knows which of my decisions are reversible and which aren’t — so it pushes harder on analysis when the stakes are locked in.
Structure makes the vault navigable. Frontmatter properties tell Claude how to traverse — follow the parent link to a project note, check recent meetings, find threads with stakeholder feedback (more on this in the next week.)
The Starter Kit
Most template repos give you a folder full of files to edit. This one interviews you instead.
Run /setup and it asks who you are, how you work, who you work with, what you’re building right now. Then it asks harder questions — what decisions are hardest for you, what kind of pushback is actually helpful, where your judgment gets tested. From those answers it generates your files: a thinking partner calibrated to your role, a user profile, your work state, your context-specific rules. Nothing is templated. Two people in the same role at the same company would get different outputs. Everything lives in your vault as editable markdown — you can open any generated file in Obsidian and see exactly what it produced. TIP: Use dictation (Wispr is perfect for this) to talk openly during setup; the more detail you provide - the richer the context.
Setup also handles an Obsidian Sync problem most people don’t hit until it’s too late: .claude/ is a hidden folder, and Obsidian Sync doesn’t sync hidden folders. So your rules, commands, and hooks are invisible to Obsidian and won’t follow you to another device. Setup migrates everything to Resources/Meta/Claude/ and symlinks .claude back — Claude Code still finds it, but now Obsidian can see, edit, and sync the whole config.
The other piece that matters: /update pulls scaffolding improvements from the repo as I add them — new commands, rule fixes, hook updates — without touching anything personalized. A manifest classifies every file as scaffolding (overwritten), content (never touched), or hybrid (scaffolding sections updated, your sections preserved).
What I’d Do Differently
Be skeptical of anyone selling a finished system for knowledge work. Including me. This system didn’t arrive complete — it emerged from daily use and corrective iteration. When the AI failed or missed something, I’d figure out why, then build the minimum scaffolding to address it. Most of the architecture described above exists because something broke without it.
That’s the honest version of “I open-sourced my setup.” Not a finished product. A framework for progressive refinement.
Voice rules came from getting caught. Someone on Reddit clocked a reply as AI-generated. That’s when I started cataloging the tells — diplomatic sandwich, validating before disagreeing, corporate hedging in casual clothes. Each rule emerged from a specific failure, not from sitting down and designing a style guide upfront. You can’t anticipate which patterns will leak through until they do.
Hooks went through three phases: none, over-engineered, simple. The first attempt was an Atlassian access control gate that locked the entire session and required an unlock command. Friction outweighed protection — I deleted four scripts and fell back to instruction-only rules. Then I spent weeks fixing frontmatter errors that should have been caught on write. The version that stuck is dead simple: check for a type: property after every file save, block if it’s missing. Enforce structure mechanically, enforce behavior through instructions.
Session logs solved a problem I didn’t know I had. Work state tells you where you left off. Session logs tell you why. The reasoning behind decisions, the paths explored and rejected, the handoff to the next session. I didn’t build them until I found myself reconstructing intent from outcomes — opening a project and trying to remember what I’d been thinking three days ago. The need was obvious in hindsight, invisible upfront.
The throughline: don’t over-automate. Don’t try to anticipate everything.
The real test is tomorrow morning. You open Claude Code, start working, and it already knows what you were doing yesterday.