I used to have 40+ tabs open at all times. Doc pages I might need, tutorials I already read, Reddit threads I was going to reply to "later." Every reboot was a prayer, please come back, all of you.

Then I started noticing something. The tabs weren't helping me work. They were making me feel like I had 40 unfinished things hanging over my head. Every one of them was a tiny open loop my brain was tracking in the background. It's exhausting and you don't even realize it until you close them.

Looks familiar?

Then I started noticing something. The tabs weren't helping me work. They were making me feel like I had 40 unfinished things hanging over my head. Every one of them was a tiny open loop my brain was tracking in the background and honestly I know there was a time where we liked to brag how many tabs we got open at the same time. But over time I realized, it's exhausting and you don't even realize it until you close them.

Claude Code helped me break the habit, not because it manages tabs, but because it replaced the reason I kept them open. I was hoarding tabs because I was afraid of losing context. Now the context lives in my project files, my session history, my knowledge graph. That doc page you read once and kept open just in case? Claude already saw it 3 sessions ago and remembers the fix. When I find something useful I don't leave a tab open, I tell Claude to remember it and close the tab. Done. Loop closed.

The less tabs I have open the calmer I feel now. That sounds dramatic but it's true. It's like cleaning your desk, the work didn't change but your head is clearer. I went from 47 tabs to maybe 4 or 5 and honestly my focus got better, my anxiety dropped, and I stopped treating every reboot like a hostage situation.

Close the tabs. your brain will thank you.

CLAUDE.md tells Claude how to build. It has the architecture, the conventions, the stack.

But it doesn't remember that time it pushed to the wrong repo. Or that it concatenated strings instead of adding numbers — you know it smashing "10" and "5" together to get "105" instead of actually doing the math to get 15. Or that it spent three rounds debugging a prompt when the API was returning a 429 the whole time.

That's what my lessons file is for. I didn't write it by hand — I built a custom `/reflect` skill that reviews each session and writes the lessons for me. The file lives alongside my CLAUDE.md and gets read at the start of every session, before Claude touches any code.

It's not a log. It's a blacklist of dead ends.

What's in mine after ~4 months:

>Git operations — wrong-repo pushes, path expansion bugs, things that silently succeed but hit the wrong target

>Data integrity — local variables that looked like object properties, string concatenation disguised as math (like the "105" bug above), mutable state in loops that corrupted data for months without errors

>Debugging patterns — checking HTTP status before blaming prompts, knowing when an LLM report should just be a template

>React patterns — useEffect scope traps, stale closures, state that doesn't reset when entities change

>Deployment — exact checklists of what to verify before and after every deploy

Each entry has the same shape: what happened, why it was wrong, and a one-line rule that prevents it next time. Claude reads the rule. The mistake doesn't come back.

sample of my lesson.md file

**The difference between a good CLAUDE.md and a great one is how many failures it remembers.**

Most people only write instructions for what Claude should do. The entries that save the most time are the ones that say what it should never do again.

The skill that makes it work:

The lessons file gets read automatically every session — I wired that into my CLAUDE.md rules and hooks so Claude never starts without it. That part is passive. I don't have to think about it.

The active part is \/reflect` — a custom skill I run at the end of every session. It reviews what just happened, catches anything that went sideways, and writes new lessons back into the file for me. I don't sit there journaling. Reflect does the writing, the hooks make sure Claude reads it next time.`

One session's mistake becomes the next session's guardrail, without me having to document every single fix by hand.

If you're not tracking your dead ends somewhere, you're re-solving them. I did exactly that for weeks before I started this file. Now \/reflect`` catches the patterns for me, and Claude reads them automatically. It pays back every single session.

The Invisible Geometry of Knowledge

I’ve been building a local knowledge base for Claude Code: a folder of markdown files rich with wikilinks that Claude traverses whenever it needs context. It works remarkably well. But for a long time, the system was invisible to me unless i typed in commands in terminal or went on the hunt in my directories. I knew the nodes were connected, but I couldn't see the shape of the thought.

So, I spent a couple of hours building a visualizer.

It parses every markdown file in ~/.claude/knowledge/, extracts the wikilinks, and renders the entire system as an interactive, 3D force-directed graph. You can orbit the structure, zoom into clusters, and click nodes to expose their content.

[Project Node] ─── [Business Logic] (Quiet Corner) │ ▼ [Decision Record] ──► [Patterns Nucleus] ◄── [Project Node] (The Bridges) (Architectural Gravity)

Link to Video here as well: https://www.youtube.com/watch?v=XlVVk2vYzFQ

My personal Knowledge Graph Sample

What amazed me was the clusters. I expected the graph to be one big tangle. Instead it organized itself into clear neighborhoods which was exactly how I envisioned it:

- A dense cluster of engineering patterns (dirty-checking, persistence layers, cache integrity) — these link to everything

- Project nodes orbiting the patterns they use most

- Decision records bridging projects to the patterns that informed them

- A quiet corner of business nodes that only connect to project nodes

The patterns cluster forms the densest nucleus of the graph. This is architectural gravity at work: as the foundational layer of the codebase, these files serve as the universal connective tissue, the singular anchor point that every slash command and project node inevitably references.

How it works:

1. `parse-graph.js` reads the markdown folder, extracts frontmatter + wikilinks
2. Outputs `graph-data.json` with nodes and edges
3. `index.html` renders it with 3d-force-graph (Three.js under the hood)
4. `refresh.sh` regenerates the data and pushes — Cloudflare Pages auto-deploys

No build step. No database. The whole thing is 3 files.

If you are maintaining a knowledge graph, or even just a dense CLAUDE.md with deeply cross-referenced sections, visualizing the topology is worth every minute. It immediately exposes reality: you will instantly see which concepts are the true intellectual anchors of your project, and which ones are merely floating islands, waiting to be linked or pruned.

Source: github.com/anja687gutierrez-jpg/knowledge-graph-3d

I've been building Woolly — a desktop pet (think Clippy but a sheep, and actually useful) in pure Swift. I mentioned him a couple times before but never deep dived on him. Here is the deal: No frameworks, no Electron, no web views. Just a pixel sheep that walks across my screen and says things.

https://preview.redd.it/hsrbsfda672h1.png?width=862&format=png&auto=webp&s=4c2c3ec8f17faa0adc8b1c9d29aa7e942ca33c23

​What started as a joke turned into something I actually rely on. Here's what he does now:

He watches what I'm doing:

• Categorizes everything into Social / Productive / Creative / Browsing and calls me out when Social > Productive
• Reads my screen occasionally and roasts what he sees
• Detects when I'm in Zoom/Meet and goes silent automatically

He knows my money:

- Pulls insider buy alerts from Finnhub for my actual portfolio (25 stocks)

- Warns me before FOMC, CPI, jobs reports — and tells me what each one means for MY specific holdings

- Quad witching and 13F filing deadline alerts

- Scans Google Flights for cheap flights to Germany (my hometown is close to Brandenburg so connection flights and deals make a huge difference)

He knows my life:

- Reads my Apple Calendar — custody schedule, flights, doctor appointments, birthdays, bills

- Gives me actionable suggestions: "Pack tonight" before a flight, "bag ready?" before custody switch

- Scans my ~/tasks/todo.md (190 items) and reminds me about the urgent ones

- Morning brief every day: calendar + weather + outfit advice + email count + top tasks

He knows my projects:

- Scans all my git repos for uncommitted changes, stale branches, missing node_modules

- Reads my knowledge graph (110 nodes across 24 projects) and suggests work on forgotten projects

- Tracks my commit streak and roasts me if I break it

**The bubble system is the interesting part.**

Every ~30 seconds, Woolly builds a candidate pool from 21 different bubble types. Each has a weight (insider buy alerts = 5, fortune cookies = 1). He filters out the last 2 types shown, then does a weighted random pick.

But now each bubble has an **emotional tone** that changes the color:

**Roast** (warm peach + red border) — Gordon Ramsay roasts, screentime callouts, ambient nags

**Uplift** (soft green + green border) — hype, streaks, milestones, daily report

**Concern** (warm yellow + gold border) — calendar reminders, todos, break reminders, CPU warnings

**Love** (soft pink + rose border) — greetings, relationship memories, custody reminders

**Excitement** (bright gold + amber border) — stock alerts, economic events, flight deals

The full map is in the image. ~6,800 lines of Swift, 13 data sources, zero dependencies.

​****He even winds down with me.**** After 9pm, he strips all the roasts and productivity stuff and switches to:

- Tomorrow's calendar preview so I can plan ahead

- Health nudges (hydrate, blue light, deep breaths)

- Movie and book suggestions — heavily weighted toward Studio Ghibli because he knows me

- A goodnight summary at 10pm with commits shipped, screen time, and tomorrow's first event

He's not an AI chatbot (though he can chat via Ollama/Gemini). He's a deterministic intelligence layer that sits on my screen and keeps me honest. The roasts alone have probably saved me 30 minutes of Reddit doomscrolling per day.

The funniest part? He started as a walking sheep that said "Baa~" and now he's basically a personal operations center with legs.

My son, husband and I are always looking for stuff to do on weekends — Bluey live shows, Disney on Ice, circus, county fair, whatever. The problem is I always find out about events *after* they've sold out because I'm not checking five different websites.

So I built a Cloudflare Worker that pulls family-friendly events from the Ticketmaster Discovery API and serves them as an `.ics` calendar feed. I subscribed to it in Apple Calendar and now upcoming events just... show up alongside my regular schedule.

https://preview.redd.it/dc0r6cwenr1h1.png?width=2880&format=png&auto=webp&s=184583923a7b34ad5f4ac488485bc17841e4788b

What it does:

- Queries Ticketmaster for family/kids/Disney/circus events in the LA metro area

- Deduplicates across multiple keyword searches

- Generates a valid `.ics` feed with event times, venues, ticket links, and price ranges

- Auto-refreshes daily via cron trigger

- Caches in KV so calendar clients get instant responses

**The whole thing is ~120 lines of JavaScript.** No frameworks, no build step, no database. Just a Worker, a KV namespace, and a free Ticketmaster API key.

### How to build your own

**Full source code + config:** https://gist.github.com/anja687gutierrez-jpg/83ce4ee27eb5985c05563508e45b64c8

Here's the quick setup:
**1. Get a Ticketmaster API key** — sign up at developer.ticketmaster.com. Free, 5,000 requests/day, takes 2 minutes.
**2. Scaffold the Worker**
```bash
npm create cloudflare@latest -- my-family-calendar
cd my-family-calendar
```
**3. Drop in the code** — grab `worker.js` and `wrangler.toml` from the Gist above. The two things to customize are the `SEARCHES` array (your family's interests) and `DMA_ID` (your city — LA is 324, NYC is 345, Chicago is 602).
**4. Create KV + deploy**
```bash
npx wrangler kv namespace create CALENDAR_KV
# copy the id into wrangler.toml, then:
npx wrangler deploy
curl https://my-family-calendar.YOUR-SUBDOMAIN.workers.dev/refresh
```
**5. Subscribe in Apple Calendar** — File → New Calendar Subscription → paste your `/calendar.ics` URL → set auto-refresh to daily.

### A note on API terms

Before you deploy, **read the [Ticketmaster API Terms of Use](https://developer.ticketmaster.com/support/terms-of-use/).\*\* A few things worth knowing:

- **Caching:** The terms allow caching event data "for reasonable periods in order to provide the service you are providing." This Worker refreshes daily and only stores what's needed for the calendar feed — that's reasonable. Don't hoard data indefinitely.

- **Don't replicate Ticketmaster:** You can't build a Ticketmaster replacement. A personal calendar that links back to their site for ticket purchases isn't that — it's basically a notification tool that drives traffic *to* them.

- **No monetizing the API:** The terms prohibit deriving revenue from the API itself. This is a free personal tool, so no issue. But if you're thinking about building a paid product on top of it, that's a different conversation.

- **Swap-in providers:** If you use Eventbrite, SeatGeek, or another events API instead, check *their* terms too — each provider has different rules around caching, attribution, and commercial use.

• This project is a personal tool for your own calendar. As long as you're not reselling the data or building a competing ticketing platform, you're in the clear.

### What I'm seeing

Mine pulls ~200 events right now — Bluey's Big Play, Disney Frozen, Ringling Bros, KIDZ BOP, LA Angels family Sundays, LA County Fair, puppet shows. All just sitting in my calendar waiting for me to notice them.

Total cost: $0. Cloudflare Workers free tier covers this easily.

---

The best part is I don't have to remember to check anything. Events just appear in my calendar like any other appointment. If Bluey is coming to town in October, I'll see it in June when tickets go on sale — not in November when my family asks why we didn't go.

My MCP concierge doesn't use AI for 80% of queries — and predicts better without it. Here's why:

I build tools that talk to AI — an out-of-home ad ops dashboard with an AI concierge that watches what report you check and what campaigns you review, it also proactively nudges you when weather is going to be bad or holidays are coming up. I even built in a roast (Gordon Ramsey style roasts)...(handling some 860+ campaigns -- > growing every day), a desktop pet assistant that runs all day on my Mac, and an MCP server that acts as a knowledge engine for Claude Code. All three started the same way: send everything to the LLM and let it figure it out.

https://preview.redd.it/3eb9q2na7m1h1.png?width=2854&format=png&auto=webp&s=f0f38222b4de832da8f49c272719561a84b76d04

All three broke the same way too.

What went wrong with AI-first:

1. The LLM hallucinated campaign data that existed in my own ad ops spreadsheet
2. My desktop pet asked a local 7B model "what's the CPU load?" — the model hung for 45 seconds on the system prompt, then guessed wrong. The actual answer was one C function call: `getloadavg()`
3. My MCP server routed "show me commits from today" to an LLM that fabricated commit messages instead of just running `git log --since=midnight`
4. Rate limits on Gemini's free tier (20 req/day) meant the assistant died by lunch
5. 2-8 second response times for questions that should be instant

The fix: deterministic-first, AI-last as fallback and a warning label

Now every query goes through 4 layers before any model sees it:

Layer 1 — Direct commands (pattern match, instant)**

These are things that have ONE correct answer and code can get it faster than any model:

- "cpu" / "slow" / "laggy" → `getloadavg()` — reads CPU load in microseconds, no model needed

- "weather" / "outfit" / "what should I wear" → cached wttr.in data + temperature-based outfit logic

- "battery" / "power" → `pmset -g batt` on a background thread

- "git" / "uncommitted" → `git status --short` across 8 project directories

- "streak" / "how many commits" → counts consecutive commit days across repos

- "music" / "now playing" → AppleScript to Spotify/Apple Music, returns track + artist

- "todo" / "tasks" → reads my actual todo.md file, shows unchecked items

- "time" → `DateFormatter` — not a 2-second API call to ask a model what time it is

- "mood" → returns Woolly's internal mood score (0-100, shifts based on my behavior)

- "projects" → reads my CLAUDE.md project registry, returns the list

That's 20+ commands handled in code. Zero tokens. Zero latency. Zero hallucination.

Layer 2 — Knowledge graph match

I maintain 110 nodes of structured knowledge (patterns, decisions, runbooks, project docs). If your question matches a node name or description, you get the real documented answer — not a generated approximation of it.

"What is cache integrity?" → returns my actual `cache-integrity.md` synthesis, not a model guessing what I might mean.

Layer 3 — High-confidence multi-keyword search

Scores your query against facts, memory entries, and session data. If 2+ keywords match with high confidence, return that result. Still no model involved.

"recent work on desktop pets" → finds matching session data, returns it directly.

Layer 4 — LLM fallback (only if layers 1-3 found nothing)

Open-ended questions, creative responses, things that genuinely need reasoning. Gemini 2.5 Flash first, local 7B as backup. Context capped at 800 chars because the small model chokes on anything bigger.

Where this runs in production:

• OOH ad ops dashboard (Ops Hub v2):** The AI concierge "Victor" runs a deterministic report engine for pipeline insights — campaign counts, stage breakdowns, overdue detection, material gaps across 860+ out-of-home advertising campaigns. All computed from real spreadsheet data, no model involved. The LLM only kicks in for natural language questions like "which campaigns should I worry about this week?"
• Desktop pet (Woolly):** A macOS app running in a single main thread. The deterministic handler resolves 20+ commands instantly. Critical constraint: anything on the main thread must be synchronous and fast — no Process() calls, no network requests, or the entire UI freezes. Learned that one the hard way when `topCPUProcess()` shell-outed on the main thread and locked the app for 45 seconds. Now deterministic = in-memory only. LLM runs on background thread with a 30-second safety timeout.
• MCP knowledge server (Elody):** 20 tools for Claude Code. Intent detection routes "show me commits" to `git log`, "search my knowledge" to local file reads, "find code for X" to grep. The LLM only handles things like "explain why this pattern matters" or open-ended chat.

**Bonus: predictive nudges — no model required**

People assume "anticipating user needs" requires AI. It doesn't. Woolly runs a prediction engine on a 30-second tick loop that combines simple signals:

- Friday after 5pm → "Close the laptop. The code will still be broken on Monday."

- Same app for 90+ minutes → "Your spine called — it wants a divorce. MOVE."

- Calendar event in 30 min while deep in Terminal → "Meeting in 28 minutes. Wrap up."

- Switched from Xcode to Chrome → "That's called procrastination with extra steps. Back to work."

- 2+ hours without a commit → "Ship a checkpoint before the universe takes it from you."

- Late night coding → "Your code quality is dropping faster than your battery. Sleep."

- Weekend morning, 30+ min in → "Working on a weekend? Bold. Make it count or close it."

All of this is `if/else` on time, app history, and calendar data. Zero tokens burned. The model couldn't do it better — it would just do it slower and occasionally get the day of the week wrong.

**The results across all three:**

- ~70-80% of queries never touch an LLM

- Deterministic responses: under 100ms. LLM responses: 2-8 seconds.

- Zero hallucination on deterministic answers — it's either right or it says "I don't know"

- Apps stay functional even when Gemini is rate-limited or Ollama is down

- API costs dropped to near-zero for daily usage

**When to actually use the AI:**

- Open-ended questions that don't match your data

- Creative responses (my desktop pet does Gordon Ramsay-style roasts — that needs a personality, not a lookup table... well, actually 60 of the roasts ARE a lookup table, and the model only generates novel ones)

- Summarizing or synthesizing across multiple sources

- Anything genuinely ambiguous

**The mental model:**

Think of it like a restaurant. You don't call the head chef to get someone a glass of water. The host handles that. The server handles standard orders. The chef only gets involved for something that actually requires skill and judgment.

Most "AI agent" projects call the chef for everything. Then wonder why service is slow and the bill is insane.

Build the boring layers first. Let the model do what only a model can do.

Someone recently told me that having 900 lines in one file is "irrational." Sir, my coworker eats 900 lines for breakfast and asks for seconds.

I've been building with Claude Code daily for about 5 months now — production apps, internal tools, stuff I actually use at work. And I keep bumping into the same advice from people who learned to code before AI could write it for you:

"Max 150 lines per file" — Claude reads 900 lines the way you read a sticky note. A single file with clear sections is actually easier for it to work with than 10 tiny files it has to hop between. When something outgrows a single file, I feel it. Then I split. Not before.

"You need a framework" — I've shipped production tools with zero dependencies. Browser APIs are absurdly powerful now — canvas, IndexedDB, drag-and-drop, media recording. Frameworks solve team coordination problems. My team is me and an AI that doesn't need onboarding just lessons and guidelines it learns along the way from you and for you.

"Plan everything before writing line one" — My production dashboard is tens of thousands of lines. It started as a single file. Half my tools still are single files — because they do one job and they do it fine. The ones that grew earned their architecture. The ones that didn't never needed it.

"If you need maintenance you did it wrong" — Respectfully, no. Nobody gets it right the first time. The difference is that fixing things with AI takes minutes instead of days. Build, break, learn, fix. That loop IS the process now.

>I'm not saying best practices are wrong. I'm saying they were designed for a world where humans had to read, understand, and maintain every line. When your coworker can digest your entire codebase in seconds, some of the rules change. Not all of them. But some.

Made a cheat sheet with this and a few other things I figured out the hard way. Not a tutorial — more like the stuff nobody tells you until you've wasted a few sessions learning it yourself.

The no-gatekeeping guide to Claude Code — from install to shipping your first tool.

>Feel free to tell me I'm wrong — I know this one's gonna rustle some jimmies. 😄

I record a lot of screen walkthroughs for work, showing teammates how a workflow works, demoing features, documenting processes. The recordings are useful but nobody watches a 5-minute silent screen recording. And honestly, I was too self-conscious to narrate them myself — I have a German accent and kept imagining people laughing instead of listening. I wanted them to look professional.

So I kept doing the same thing over and over: watch my own recording, pause, write what's happening, paste it into a TTS tool, download the audio, sync it in a video editor. For a 5-minute video that's 30-40 minutes of tedious work.

I built Narrator to kill that loop.

How it works:

1. Drop in your screen recording
2. Give it one sentence of context — "this is a demo of the admin dashboard's shipment tracking flow"
3. It extracts frames, sends them to Gemini 2.5 Flash in batches, and gets back a timestamped narration script
4. You can edit any line inline before generating
5. Hit generate — it produces TTS audio (6 built-in voices, no API key needed), burns subtitles, adds transitions between segments, and exports a final MP4

Sample of Narration

The whole thing runs locally. Your video never leaves your machine — only the extracted frames go to Gemini for analysis.

What I actually use it for:

- Work walkthroughs for my ops team ("here's how the new receivables workflow works")

- Quick feature demos I can send in Slack instead of scheduling a meeting

- Documentation that doesn't go stale the way written docs do

The stack:

- TypeScript + Express backend

- React 19 + Tailwind frontend

- Gemini 2.5 Flash for frame analysis

- Microsoft Edge TTS (free, no API key)

- ffmpeg for all the video processing

Built the whole thing with Claude in two days. The AI script generation, the TTS pipeline, the transition engine, the subtitle burning — all wired together. Claude helped me figure out the ffmpeg incantations for xfade transitions, which I definitely would not have gotten right on my own.

A 5-minute video takes about 2 minutes to process and costs roughly $0.01-0.05 on Gemini's paid tier. Free tier works too — 20 requests/day, so I recommend you to upload short clips first, I went all in with a 15 minutes video and was reminded by Gemini that free tiers requires a lot more patience!

Just open-sourced it: https://github.com/anja687gutierrez-jpg/narrator

MIT licensed. You need Node.js, ffmpeg, and a free Gemini API key to run it.

If you make screen recordings for any reason — tutorials, demos, documentation, onboarding — this might save you a lot of time.

Happy narrating! 😄

I've stopped downloading apps for half the things I need. If I need it, I just build it as HTML with Claude.

New design idea? HTML. Resume update? HTML. Internal dashboard? HTML. Video editor with subtitles and TTS? HTML.

My latest example: I needed a video narrator tool — upload a video, generate subtitles, preview with overlay, export clips with TTS voiceover. Instead of hunting for some $20/month SaaS, I described what I wanted to Claude Code and had a working local web app the same day.

The thing people underestimate about HTML is how capable it's gotten. Between the browser APIs (media, canvas, drag-and-drop, IndexedDB) and AI writing the glue code, you can build genuinely useful tools without touching a framework, a build step, or a deploy pipeline.

My workflow these days is basically (in a nutshell and very much simplified)

1. Describe what I need

2. Claude writes it

3. Open in browser

4. Done

The barrier between "I wish this existed" and "I'm using it" has basically disappeared. Anyone else finding themselves building throwaway HTML tools for everything?

https://reddit.com/link/1te53rn/video/poc7t162ic1h1/player

Everyone's generating context files right now. Tools like grill-with-docs, repomix, aider, they gather your codebase into a flat summary so the AI has something to work with. That's useful. But it's not a knowledge graph.

Here's the difference that changed how I work with Claude Code.

**A context file is a summary.** it gathers information into one place. Claude reads it, gets the picture, moves on. if you want it to know about auth patterns, you point it at the file. if you want it to connect auth patterns to session tokens to security rules, you point it at all three files. you're the router.

**A knowledge graph is navigable.** each concept is its own node. nodes link to each other with wikilinks. Claude can follow a thread from one concept to a related concept without you telling it where to look.

My setup has ~50 nodes across 7 domains:

>Patterns — things like dirty-checking, cache-integrity, persistence-layers

>Decisions — ADRs (architecture decision records) for choices like "why vite over nextjs" or "why supabase over firebase"

>Runbooks — step-by-step deploy procedures, recovery playbooks

>Workflow — how I actually work: plan mode, self-improvement loops, verification steps

>Projects — per-project nodes with stack, status, open issues

>Checkpoints — snapshots of where a project was at a specific phase

>Business — non-code context that still affects decisions

Each domain has a \_moc-*.md` (map of content) that indexes its nodes. the root `_index.md` links to every MOC. Any node can wikilink to any other node, a pattern can reference a decision, a runbook can reference a project.`

The Test: Can Claude follow a thread from one concept to a related concept without you telling it where to look? If yes, that's a graph. if it needs you to point at the right file every time, that's context.

Context files are a strong foundation. Most people should start there. But if you're working across multiple projects and you keep re-explaining the same patterns, a knowledge graph is the next layer.

https://preview.redd.it/hyd8bbd0l51h1.png?width=954&format=png&auto=webp&s=ad7bffdb75784d131e41033f1b3d580f56b65f02

I've posted about individual pieces of my setup before — the knowledge graph, the memory system, hooks, the 10-layer audit. But I never explained why they only work when they're stacked in a specific order.

Most developers treat CLAUDE.md as a flat file. Write some rules, maybe list your stack, done. That works for a single project. It falls apart at three.

Here's what I learned the hard way: each layer only works if the ones below it exist.

>**Layer 1: CLAUDE.md itself — the instruction set** Without it, Claude has no rules. But instructions alone don't remember anything.

>**Layer 2: Project registry** A table inside CLAUDE.md — every project, its location, stack, port, deploy command. Without this, Claude guesses paths and gets them wrong. But a registry doesn't learn from mistakes.

>**Layer 3: Memory system** MEMORY.md + lessons.md + feedback files. Every correction I make gets saved so Claude never repeats it. Without this, I'm giving the same correction for the fourth time. But memories don't organize themselves.

>**Layer 4: Knowledge graph** Markdown files with wikilinks, typed relationships, importance scoring. The debugging insight from three weeks ago is findable in seconds. Without this, good ideas rot in chat history. But knowledge without enforcement is just suggestions.

>**Layer 5: Skills** Slash commands — /reflect, /primer, /spec. Repeatable workflows I'd otherwise type manually every session. Without these, I'm doing the same 12-step debrief from memory. But skills without guardrails can still do damage.

>**Layer 6: Hooks** Event-driven automation. A deploy warning fires before production pushes. A duplicate check runs after every edit. Without these, guidelines are just hopes. But automation without verification is blind.

My Claude Playbook.md files

>**Layer 7: Gates** Quality checks that verify the session actually followed the rules. Did everything get committed? Did the README get updated? Did corrections get saved? Without these, you're trusting that the system worked — instead of proving it.

Skip layer 3 and layer 5 breaks — your skills reference lessons that don't exist. Skip layer 6 and layer 1 is decorative — nobody enforces the instructions. The stack has to be complete or the gaps compound.

It took me 3 months of daily use across 18 projects to figure out this ordering. Each layer exists because something went wrong without it.

I've been documenting the full architecture — all 7 layers, how they connect, failure modes when you skip one, and templates for each.

Happy to share more if anyone's building something similar.

I've talked before about my knowledge graph and how session corrections compound. But I never explained what actually happens at the end of a session — the thing that decides what's worth keeping and what's just noise.

It's a 10-layer audit that runs as a slash command. Each layer checks something different:

>**1. Git state** — did everything get committed? Any dangling changes?

>**2. Code quality** — did I introduce anything sloppy?

>**3. Documentation freshness** — does the README still match reality?

>**4. Lesson extraction** — did I learn something that should be written down?

>**5. User corrections** — did I correct Claude on something it should never repeat?

>**5.5. Knowledge harvest** — this is the new one

>**6-10.** Quality gates, output verification, progress checks

Layer 5.5 is where it gets interesting. It evaluates whether anything from this session — an architectural tradeoff, a cross-project pattern, a debugging insight that took 45 minutes to figure out — scores high enough on an importance rubric to get promoted into the knowledge graph permanently.

Not everything passes. A typo fix doesn't. A config change doesn't. But "here's why JWT refresh tokens need different handling across Firebase, Supabase, and Auth.js" — that scores high and gets written as a durable node with typed relationships to related patterns.

The difference between this and just taking notes: I don't decide what's important. The rubric does. At 11pm after a long session, my judgment on "is this worth saving" is terrible. The audit layer doesn't get tired.

Before this, my best insights lived in chat history. I'd vaguely remember solving something three weeks ago but couldn't find it. Now the graph has 110+ nodes and growing — every session feeds it automatically.

The whole thing is part of a broader toolkit I've been building — 7 skills that handle session debriefs, project warm-starts, auth scaffolding, health checks, and more.

Happy to go deeper on any of the layers if anyone's curious. I do have a Power Kit for people who are interested to dive deeper into the architectural design of this concept.

https://preview.redd.it/i2ct14sawr0h1.png?width=1200&format=png&auto=webp&s=fde10d226b4aff7f346de8d04a9206cc5406ee4e

Last week i was trying to get Claude to generate a scoring system for campaign priorities at work. i described what i wanted. Didn't like the result. Reworded it. Still off. Added more detail. Closer but wrong. Six attempts in, i stopped and asked myself: do i even know what i want this to look like?

No. I didn't. And that was the problem.

I wasn't using the wrong words. I was using the wrong *mode*.

Turns out there are three distinct ways to work with AI, and most of us only use one.

**Mode 1: Automation.**

You know what you want. You tell the AI. It does it. "Reformat this CSV." "Rename these variables to camelCase." "Write tests for this function." Clear in, clear out. This is where most people live — and it's great, until you're not sure what the output should be.

**Mode 2: Augmentation.**

You don't know the answer yet. Instead of demanding output, you start a conversation. Last month i was building a scoring system for my team's operations dashboard. Instead of saying "write a priority score," i said "here's how we decide what's urgent — volume, timeline, materials status. Help me think about how to weight these." Claude pushed back on my weighting logic. Asked what happens when two campaigns tie. i hadn't considered that. We worked through it together, and the formula i landed on was better than anything i would've asked for.

**Mode 3: Agency.**

You're not involved in every decision anymore. You set the rules, the boundaries, the knowledge — and the AI operates within them. i have a file that tells Claude what my projects are, how i like to work, what mistakes to avoid. Every session, it reads that file and adjusts. i didn't tell it to check for those things today. i told it once, and now it just does.

The part nobody talks about: switching mid-task.

That scoring system? i started in automation mode (just write it), got stuck, switched to augmentation (help me think), figured out the logic, then went back to automation (ok now write it). Three modes in one task.

>The mistake isn't using the wrong mode. It's not realizing you *can* switch.

When you're asking for the same thing over and over in different words — that's a signal. You're in automation mode but the problem needs augmentation. When you're micromanaging every line of output — that's a signal too. The problem might need agency: set the rules and let it run.

I don't always get this right. But now when something feels off, my first question isn't "what should i say differently?" It's "am i in the right mode?"

That question saves me more time than rewording ever has.

Subagents are one of the most powerful features in Claude Code and most people either ignore them or use them like a worse version of asking Claude directly. I use them on probably 60% of my sessions now, and the difference is night and day — but it took me a while to figure out why some attempts flopped and others saved me 20 minutes.

Three mistakes I kept making

>1. Treating subagents like a second Claude chat. I'd spin one up and give it the same vague prompt I'd give my main session — "look at this codebase and tell me what's going on." That's just burning tokens on unfocused exploration. A subagent without a specific mission comes back with a wall of text you still have to synthesize yourself.

>2. Running them sequentially when they could run in parallel. I was launching one agent, waiting for it to finish, reading the result, then launching the next one. That's literally the same as doing it in your main thread — you're just adding overhead. The whole point is parallelism.

>3. Dumping the results into my main context. I'd have an agent explore 40 files and then paste the full output back into my conversation. Now my context window is stuffed with code I only needed once, and Claude starts losing my earlier requirements.

What actually works

1. Brief them like a colleague, not a chatbot. "Search the data layer for how we handle campaign state — specifically look for persistence patterns and any sync logic. Report back the file paths and the pattern, not the full code." Specific mission, specific output format. The agent comes back with 10 useful lines instead of 200 lines of noise.

2. Launch 2-3 agents in parallel for multi-area tasks. Planning a feature that touches the UI, the data layer, and an API? Three explore agents, one per area, all running simultaneously. What takes 15 minutes sequentially finishes in 3. Each one returns a focused summary. My main window gets three clean reports I can actually make decisions from.

3. Use them for independent review. After I finish a feature, I spin up a review agent with a fresh context. It hasn't seen my thought process, my wrong turns, or my justifications. It just sees the diff. That independence catches things I'd never notice reviewing my own work — missing edge cases, inconsistent patterns, subtle bugs that look fine when you've been staring at them for an hour.

The real unlock

Subagents aren't about doing more work — they're about keeping your main conversation coherent. Every file Claude reads, every search result, every code block fills the context window. When it fills up, Claude loses your earlier context. Your requirements from the beginning of the session just quietly disappear.

The pattern that changed everything for me: plan in the main thread, delegate exploration to subagents, synthesize their reports myself, then execute. The main window never sees raw exploration output. It stays clean, focused, and remembers what I told it 45 minutes ago.

I started building hooks early — a duplicate code checker that greps after every edit, a pre-session gate that blocks Claude from writing code until it reads my lessons file. Both run automatically, no prompting needed, zero API cost. They've been in my setup since March.

I thought that was the whole feature. Then I started studying for Anthropic's certification and realized I was barely scratching the surface.

The basics (what most people know)

Hooks are shell scripts that run automatically when Claude does something. They live in `settings.json`, not in your CLAUDE.md. The difference matters: CLAUDE.md is instructions Claude *chooses* to follow. Hooks are guardrails that *execute whether Claude likes it or not.*

The two I was already running:

1. Pre-session gate.

Before Claude can write a single line of code, a hook checks whether it read my lessons file. If it didn't, the edit gets blocked. I built this after Claude skipped mandatory reads and repeated a mistake that cost me an entire day. Now it physically can't skip them.

2. Duplicate code check.

After every file edit, a hook greps the project for functions with the same name. Catches the case where Claude writes a helper that already exists somewhere else in the codebase. Simple grep, runs in milliseconds.

What I was missing

There are 9 hook types. I was only using PreToolUse and PostToolUse — the ones that fire before and after Claude uses a tool. But there's also SessionStart, SessionEnd, SubagentStop, UserPromptSubmit, and more. Each one receives different data as input.

SessionStart and /Primer alone opens up a lot. I now have a hook that auto-loads project context the moment a session begins — no manual prompting, no "hey Claude, read the project files first." It just happens.

The other thing I hadn't considered: lightweight hooks vs AI-powered hooks. My grep-based checker is lightweight — fast, free, runs on every edit. But you can also build hooks that use the Agent SDK to have Claude review Claude's own output before it ships. That's slower and costs tokens, but catches semantic problems a grep never would. Two different weight classes for two different jobs.

The layer most people skip

CLAUDE.md tells Claude what to do. Memory tells Claude what to remember. Hooks tell Claude what it *can't get away with.* They're the enforcement layer — the thing that turns guidelines into guardrails.

I had the first two dialed in for months before I realized the third one had 9 entry points I was mostly ignoring. The conversations got better once I stopped relying on Claude to police itself and let the hooks handle it.

&gt;>>> THIS IS FOR EVERYONE -- NOT JUST 20+ YEARS OF EXPERIENCED GATE KEEPING IT/SOFTWARE ENGINEER VETERANS. <<<<<<<

I used to open Claude Code, describe what I wanted, and let it go. Sometimes it worked. Sometimes I'd look up and realize it had refactored three files I didn't ask it to touch, introduced a new abstraction I didn't need, and broken something that was working fine.

The fix wasn't better prompts. It was plan mode.

What plan mode actually does

You type `/plan` before starting any non-trivial task. Claude switches into research-only mode — it can read files, search the codebase, run grep, trace dependencies. But it can't edit anything. It writes a plan to a markdown file, then waits for your approval before touching a single line of code.

That forced pause is everything. Instead of "here's what I built for you," it's "here's what I'm thinking — does this match what you want?"

https://preview.redd.it/u8ixtbcy89wg1.png?width=1288&format=png&auto=webp&s=74d650fc4c3e48adbaddd463454435b4d61e442a

How I use it daily

Every task with more than 2-3 steps gets plan mode. The workflow:

1. I describe the task
2. Claude explores the codebase — reads relevant files, traces how the feature currently works, checks for existing patterns it should reuse
3. It writes a plan: which files to modify, what approach to take, what to test
4. I read the plan, push back on anything that doesn't make sense, approve or redirect
5. Then it executes against the approved plan

Step 4 is where the real value is. I've caught Claude about to introduce a new utility function when one already existed 3 files away. I've caught it planning to refactor a working system instead of making the minimal change I actually needed. I've redirected it from a 12-file change to a 2-file change because the plan made the scope visible before any code was written.

The mindset shift

Before plan mode, I was reviewing code after it was written — trying to catch problems in a diff. That's expensive. You're already invested in the approach, and "undo all of this" feels wasteful.

With plan mode, I'm reviewing the approach before any code exists. Redirecting a plan costs nothing. Redirecting a completed implementation costs everything.

When I skip it

Single-file changes, typo fixes, "add this CSS class" — anything where the scope is obvious and the blast radius is one file. Plan mode adds overhead that isn't worth it for 30-second tasks.

But anything that touches multiple files, involves architectural decisions, or could break something else? Plan mode, every time. The 2 minutes I spend reading the plan saves me 20 minutes undoing work I didn't ask for.

The pattern I keep coming back to: make Claude think before it builds. The code is almost always better when there's a plan behind it.

We just had our first spam ban — someone dropped a Medium link promoting their MCP product with zero prior engagement in the community. Reddit's spam filter caught it before I did. Figured this is a good time to set expectations early.

**What gets you banned:**

1. **Drive-by product drops** — your first interaction with this sub should not be a link to your product. If the only reason you're here is to advertise, this isn't the sub for you.

2. **Marketing disguised as a story with zero followers** — "here's what nearly broke us building X" sounds like a war story, but when the entire post is a funnel to your product page, it's an ad. We can tell the difference.

Don't post links from Memory with 0 followers - it's not advisable and embarrassing. We do however love newbies on Reddit and love helping you grow your followers. ;)

3. **Throwaway accounts** — if your account has no history and your first post is a promotion, the spam filter will catch you and I'll leave it that way.

https://preview.redd.it/fiu4r209d6vg1.png?width=1548&format=png&auto=webp&s=4826cd40e3752e9bc896570cadbbadf3a5ef4a4c

**What actually works here:**

1. **Show your work** — share what you built, how you built it, what went wrong, what you learned. The build is the content, not the product page.

2. **Engage first** — comment on other people's posts. Answer questions. Be part of the community before you ask it to look at your thing.

3. **Self-posts over link drops** — write it up here. If your project is interesting, people will ask for the link. That's how you earn clicks, not by pasting a Medium URL and disappearing.

This sub is for builders — people shipping real things with Claude and sharing the messy, honest process. That's it. If your thing is genuinely useful, the community will find it. But you have to show up as a person first, not a billboard