Why I rebuilt my AI second brain — three problems that surfaced after five weeks

Standards matter more when AI is your editor. v2.0 is the rebuild that proved it.

1. The cracks: five weeks in

Five weeks into using the AI second brain I'd built, three things were nagging at me.

The skills were getting fat. The project list was lying to me. Every area had its own dialect.

None of them were bugs. All of them were structural.

Quick context if you missed the original post: SMRITI v1.0 is an open-source second brain that pairs Obsidian with Claude Code. 13 markdown skill files give Claude Code daily-companion behaviors — morning brief, capture, weekly review, knowledge extraction. It worked. The Galaxy crossed 100 atomic notes. The morning brief landed on time.

By week four, those cracks were impossible to ignore. v2.0 is the rebuild that fixes all three. Below is what hurt, what I changed, and the cross-cutting lesson I didn't see until the rebuild was done.

2. One command, doing everything

The pain

One evening I was debugging why /close-my-day had skipped a step. I opened the skill file. Scrolled. Scrolled more. Skill file: 127 lines.

/close-my-day was doing everything. Pulling Todoist completions. Reconciling daily notes. Running the weekly review on Sundays. Extracting Galaxy candidates. Drafting tomorrow's quests. Mini-triaging captures.

Each was a block of inline logic. Token cost climbed every time I invoked it. Changing one phase meant reading all the others.

13 skills, most of the big ones bloating the same way. The biggest one ran past 200 lines.

The fix: skill = touchpoint, agent = depth

The skill stays thin. It's what you type. The depth moves into specialized agents that the skill dispatches.

/close-my-day  (79 lines — was 127)
  │
  ├─→  Task Sync agent           (pull Todoist completions)
  ├─→  Auto-Link agent           (Friday cascade)
  ├─→  Weekly Review agent       (Sunday cascade)
  └─→  Galaxy Extractor agent    (pull atomic candidates)

Mini-triage and tomorrow's quests draft stay inline in the skill — they're light enough.

• Skills (6). /start-my-day, /close-my-day, /checkpoint, /braindump, /triage, /consolidate. Each is a thin coordinator — read state, dispatch, present results, write back.
• Agents (8). Specialized sub-capabilities the skills dispatch. The clearest example is the Task Sync agent: it pulls completed Todoist tasks, finds the matching tids in vault Project files, ticks the checkboxes, and writes Completed:: fields. 270 lines of focused logic. Yes, that's longer than v1.0's biggest skill — that's the point. Depth lives in agents now. The skill stays thin; the agent takes the weight.

Why it matters

Each agent picks its own model. Galaxy Extractor runs on Opus because synthesis quality matters. Inbox Triage runs on Sonnet because it's template-driven. Task Sync runs on Sonnet because it's transactional. A monolithic skill can't optimize per-phase. A dispatcher can.

Agents run in parallel. Friday close fires Auto-Link and Librarian in one message. Wall-clock drops to the slowest agent, not the sum.

Skills shrank. /close-my-day went from 127 → 79 lines (38%). /start-my-day went from 148 → 107 (28%). The hard logic still exists — it just lives in agent files where it belongs.

Net: 13 skills → 6 skills + 8 agents. Fewer commands. More capability.

3. The list that always lied

The pain

Every Friday I'd open the area's Initiatives.md to plan the next sprint. Table of projects — status, priority, effort, owner. Looks great in screenshots.

It was always wrong. I'd close a project. Forget to update the table. Next Friday, three rows said "active" for projects I'd shipped two weeks ago.

The Project files had the truth. The companion file had a snapshot nobody re-snapped.

And every project lived in one flat 01 - PROJECTS/ folder. Work next to learning next to personal. The folder lost its signal.

The fix

Two changes, one outcome.

Kill the companion file. The Initiative Index is now a live Dataview query (Dataview is an Obsidian plugin that reads frontmatter from notes and renders queryable tables). It reads directly from the Project files themselves. No more hand-maintained tables.

Add this to the area's Playbook under ## Initiative Index:

TABLE status, priority, effort, planned, completed
FROM "01 - PROJECTS/Work"
WHERE status != "cancelled"
SORT priority ASC, planned ASC

The Playbook shows the truth because the truth is the Project files.

Move Projects under per-area folders. Instead of a flat folder, Projects live under per-area subfolders:

01 - PROJECTS/
├── Work/
│   ├── 001-q3-platform-migration.md
│   └── 002-pr-policy.md
├── Learning/
│   └── 014-fastapi-deep-dive.md
└── Personal/
    └── 003-q3-personal-checkpoint.md

Project IDs are area-scoped — work-001, learning-014. Never reused. When you cancel a project, the file stays in place with status: cancelled. The ID stays bound to the file. No tombstoning, no ambiguity, no "which work-014 are we talking about?"

The locked schema

Each Project file carries 18 frontmatter fields — status, priority, effort, planned/completed dates, recurrence pattern, Todoist linkage, tags. Each field earned its place by being load-bearing for dispatch, queries, or stability.

The point isn't the field count. The point is that the schema forces decisions to be visible.

• status is one of 8 values. No freeform. You can't fudge a project as "kinda done."
• effort is one of 7 values. You can't claim a 30-minute task is "ish, maybe."
• recurring: true + iteration: N lets one file hold 50 iterations of weekly work instead of generating 50 files.

Feels restrictive for a week. Then it's muscle memory.

4. Five areas, five dialects

The pain

I move between areas every day. Work in the morning. Learning at lunch. Personal in the evening.

Each area's CLAUDE.md had drifted into its own vocabulary.

Work documented its weekly rhythm as "Operating Loop." Learning called it "Daily Cadence." Personal didn't document it at all.

When I wanted to know the rhythm, I had to translate every time. So did the AI. Every skill reading an area's CLAUDE.md had to handle three conventions.

The fix: every area gets the same Playbook

Six canonical sections, always the same, always in the same order. Here's a real Learning-area Playbook filled in:

## Mission
Learning is where I spend protected hours on AI/ML mastery — concept
clinics, hands-on experiments, and Galaxy notes that compound into
long-term competence. This is the area I won't let work crowd out.

## Operating Rhythm
### Daily
- 12:00–14:00 protected study block (Slack DND, no calls)
- 21:00 close ritual + Galaxy candidates pass

### Weekly
- Sunday: next topic plan + audit current topic for AI-moves-fast drift
- Galaxy target: 2 atomic notes / week

## Initiative Index
(Dataview query renders open + closed Projects from
 01 - PROJECTS/Learning/)

## Library
- Phase plan, topic prerequisites, Galaxy MOC entries
- Reference papers, cohort notes, external course bookmarks

## Signal Log
- Topic-level surprises ("retrievers + rerankers asymmetric" — 2026-05-20)
- Blog post candidates surfaced mid-study
- Tools to investigate (LangSmith, Phoenix evaluation)

## Cross-cuts
- Inputs: research papers (RSS / Readwise) → Inbox → triage → Learning
- Outputs: Galaxy notes → blog posts; Decisions → Work architecture

When every area has the same shape, three things change.

You move between areas without translation. "What's open in Learning?" → Initiative Index. "What's the rhythm?" → Operating Rhythm. No mental tax.

AI doesn't relearn. Every skill knows where the Initiative Index lives. The Auto-Link agent knows Library entries are link candidates. The Inbox Triage agent knows every area has a Signal Log where a half-baked idea can sit until it ripens.

New areas are cheap. setup.sh ships an interactive Area loop — type a name, it copies the Example-Area template, substitutes your name across the Playbook + CLAUDE.md, creates the matching Projects folder. ~30 seconds per area.

The trade-off: some loss of structural freedom. I wanted a "Reading Queue" section in my Learning area's Playbook — it ended up inside Library. Library is for stable reference material; a Reading Queue is more of a status surface. The fit isn't perfect, but it's good enough. That's the price of conformity. I'll take it.

5. Why Standards matter more when AI is your editor

The cross-cutting lesson I didn't see until v2.0 was done.

v1.0 had no Standards layer. Every skill was its own interpretation of how the vault should work. Every area's CLAUDE.md was a dialect. Drift was automatic — and worse, drift was invisible because everything still worked.

And here's why this matters when AI is the primary editor.

Every skill is an instruction file. When you author skill N, you're consciously matching skill N-1's conventions. When you author skill N+3 three weeks later, you've forgotten which conventions were deliberate and which were accidental. Two incompatible versions of the same idea both work. Both ship. Drift accumulates.

On a team, PR review catches the drift. Solo with AI, there's no PR review.

The Standard is the enforcement layer. It's the thing that lets you author skill N+3 and have it land coherent with skills 1 through N+2 because there's a written reference for "how we do it here."

v2.0 ships 8 canonical Standards under 02 - AREAS/SADHANA/Standards/. The four highest-leverage ones:

• Project Template — Epic / Task / Sub Task hierarchy, the 18-field schema, status vocabulary.
• Initiative Index Standard — the Dataview query shape, status grouping, column order. This is what makes Section 3's queryable project structure possible.
• Frontmatter Standards — the 5-field minimum on every note. Got muscle-memory in three days.
• Skill Authoring Standard — skill size limit (110 lines hard cap), frontmatter, the pre-add gate (more on this below).

The other four cover tags, themes (optional), permissions, and model routing.

The pre-add gate

The single most useful artifact across all 8 Standards is a three-question gate in the Skill Authoring Standard. Before adding skill N+1:

1. Can an existing skill extend to cover this?
2. Can a hook, cron, or agent replace the need for a user-invocable command?
3. If neither — retire one skill, or justify with a concrete re-eval trigger.

v1.0 hit 13 skills because there was no gate. v2.0 sits at 6 because the gate fires on every new idea. The cap counts user-invocable skills only — agents and standards don't count, so the system grows in depth without sprawling at the surface.

6. What I didn't see coming

Writing a new skill feels easier now. The hard work happens in the agent. The skill is just a switchboard. I expected the split to add cognitive overhead. It removed it.

Standards stuck faster than I expected. Once Frontmatter Standards locked the 5-field minimum, every note from that day forward had those 5 fields without me thinking. About three days of deliberate practice, then muscle memory.

L1 cache earned its keep. L1 is a pre-assembled context file at .claude/cache/L1-static.md — tags, frontmatter rules, sync rules, area context, all in one read. Replaces 5-10 source-file reads per skill invocation. I haven't measured token counts precisely (the prompt size varies too much for one number), but the bigger win was perceived latency. Skills feel snappier.

Standards made new agents cheap to write. Inbox Triage was the last agent I added during the rebuild. I opened the Skill Authoring Standard, copied the structure, filled in the depth — done in an evening. Without the Standard, this would have been three evenings of "what's the right pattern here?" The retrofit pain I paid in v2.0 buys me speed in everything that comes after.

7. What I'd do differently

Start with Standards, not skills. v1.0 → v2.0 was a forced migration. If I'd written even a minimal Standards layer first and authored skills against it, the rebuild wouldn't have been necessary.

The recursive Standard problem. How do you write a Skill Authoring Standard with no skills to test it against? I dodged this in v1.0 — wrote zero standards, shipped 13 skills, then tried to retrofit Standards on top. Half the rules in v2.0's Skill Authoring Standard are reverse-engineered from v1.0 mistakes. The right move is iterative: write a minimal Standard, ship one or two skills against it, refine the Standard, ship more.

Documentation outpaced the code. I assumed 8 Standards docs would take a weekend. They took five evenings. The Standards layer ended up roughly 3× the line count of the skills it governs (~1,500 lines vs ~460). If you're building one of these, budget the writing time as its own phase.

Agents are easier to retire than skills. I planned 10 agents. Shipped 8. Two got cut during integration testing — not dispatched by any shipping skill, depended on infra I hadn't built. Cutting an agent meant deleting one file. Cutting a v1.0-style skill would have meant breaking a user-facing command and forcing every user (me included) to relearn the flow. Agents are cheap to add and cheap to remove. Skills aren't.

8. What v2.0 doesn't ship

I want to be transparent about what v1.0 features got cut or moved:

• Inline capture (/capture in v1.0) — folded into /braindump. One capture surface, less to remember.
• Standalone connect skill (/connect) — became the Auto-Link agent, dispatched automatically from Friday and Sunday /close-my-day. Removes the manual command.
• Standalone weekly review (/weekly-review) — became the Weekly Review agent, auto-dispatched from Sunday /close-my-day.
• Standalone extract / promote skills — became the Galaxy Extractor and Knowledge Promoter agents, dispatched by /consolidate and the weekly cascade.

If you used any of these as standalone commands daily in v1.0, the muscle memory shifts in v2.0 — the work still happens, but it's auto-dispatched rather than typed.

9. Try it

v2.0 is open source. Three steps:

git clone https://github.com/deepakgoyal-ai/smriti.git
cd smriti
./setup.sh

setup.sh is interactive — 8 steps. Name, day-start, day-end, optional Todoist Sprint Board IDs, then the Area loop where you scaffold your first real Areas. ~5 minutes start to finish on a fresh clone.

Migrating from v1.0? SETUP.md has a dedicated section. Breaking changes are real — vault layout shifted, 7 skills converted to agents, Standards became canonical. My own vault migration took about 30 minutes (file moves + frontmatter additions, no MCP config changes).

What you need:

• Obsidian (free)
• Claude Code (Pro plan recommended)
• A clean clone or a v1.0 vault to migrate
• A daily journaling habit — if you don't already journal daily, this won't compound

Daily time commitment: ~5 minutes morning (/start-my-day), captures during the day (zero overhead — just type), and 5-10 minutes evening (/close-my-day). The Sunday close is the longest at ~15 minutes because it runs the weekly review.

What ships: 6 skills, 8 agents, 8 Standards, 1 L1 cache template, opt-in Todoist sync, an Example-Area scaffold, a sample Project, a couple of sample Galaxy notes.

If v1.0 still works for you, stay. v2.0 is what I'd ship if starting from scratch today.

Notes, skills, agents, standards — all markdown. Your knowledge is yours.

Built by Deepak Goyal. Follow the journey: GitHub · LinkedIn