I've been meditating on this for the last few months and I's still not sure how I feel about this change.

On one hand, my nearly 30 years of experience in design and development is serving me well, in that I am capable of making sound decisions about virtually any aspect of significant and complex digital products. Which means my day-to-day is no longer spent banging out code, building wireframes, or fiddling with Photoshop. It's literally reading and writing specs all day about which feature to add, how it should function, etc.

So, that feels ...smarter, somehow.

But, on the other hand my identity, and consequently where I had previously found joy, is somehow still tied to what in my head I had always thought of as the "craft" of execution.

I wonder how people who were in "Product Manager" roles are adapting to this change? Are they also moving up the thought-ladder into a different role? Or are we, as an army of displaced designers and developers, suddenly encroaching on an immovable barrier between product design and where the money starts?

Can we all build something together a huge project and worlds largest company with 10000+ founders???

Get Claude to blueprint the idea and let’s go if you think it’s worth it???

A couple of days ago I posted about my 3 layer system I built to address Claude memory issues and how I set it up.

https://www.reddit.com/r/claude/s/jloGQbiMZO

I got quite a few DMs asking for a simpler breakdown. Here is a one pager that breaks everything down.

For the people who called me a bot, you're wrong.

My system isn't a single prompt and it's not static. It's 20+ files that reference each other. There's a live database that changes every day from real meetings as well as slash commands that run multi-step workflows against actual API endpoints. It took me about two weeks to build.

A bot would've gotten it right the first time.

One pager includes:

- Every file in the project and what it does

- How the database and dashboard fit in

- The slash command pattern (/morning, /debrief, /close, /weekly)

- Data flow from meeting transcript to database

- The mistakes I made so you don't have to

- Daily routine

- Total cost ($100/mo Claude Max, everything else is free tier)

- Step-by-step if you want to build your own

TL;DR: Claude forgets between chats. I gave it permanent context with markdown files, a database for live data, and slash commands that run like scripts. Nothing writes without my approval.

One pager: https://ballyhofam-bot.github.io/claude-project-os/blueprint.html

GitHub repo with templates: https://github.com/ballyhofam-bot/claude-project-os

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'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

Credit to u/Available-Spend2443 for his Claude Code OS post — same problem, similar thinking, different platform. I built mine on Claude Projects instead of Claude Code, and added a real database layer.

I'm an EHS manager at a manufacturing plant. ~1,200 employees, think fabrication shop, I'm taking over for someone who's transitioning out. That means every conversation we have contains institutional knowledge that doesn't exist anywhere in writing. If I don't capture it, it's gone.

Claude's great at processing all of this. The problem is it forgets. Conversations compact, sessions start cold, and you're back to re-explaining your entire situation. I got tired of that after about three days and built a system around it.

Layer 1 — .md files in the project

These are project files Claude reads at session start. My role, key people, relationship dynamics, institutional knowledge captures, a running decision log, session history. Project files don't get compacted — they're always there. I have about a dozen covering context, tribal knowledge, people intel, and logs.

The decision log alone has saved me hours. When something comes up that was already discussed and decided, Claude has the date, the reasoning, and the outcome. No re-litigating.

Layer 2 — Cloudflare D1 + Worker API + artifacts

This is where structured data lives. Task tracking with ownership, priority, due dates, who's blocking what tasks. People directory (Golden information). Leadership moves log. All accessible through a Cloudflare Worker API, with a Netlify dashboard on top.

I also built interactive artifacts — a mobile inspection form I use on the manufacturing floor, a meeting prep tool. These are React components that run inside Claude's artifact system.

Layer 1 tells Claude why something matters.

Layer 2 tells Claude what the current state is. Different jobs.

Layer 3 — Skill files

Markdown files in the project that act as executable commands. I type /morning and Claude reads the skill file, pulls live data from D1, checks Otter.ai for unprocessed meeting transcripts, and builds a brief. /debrief after a meeting extracts tasks, captures people intel, and runs a strategic analysis. /close at end of day reconciles everything and updates the .md files.

The cadence is what holds it together. Without Layer 3, Layers 1 and 2 drift apart. The skills force synchronization — debriefs push structured data into D1 and narrative context back to the .md files. Morning briefs read both. Close-of-day reconciles both.

What it looks like in practice

I walk in at 7:30, type /morning, and get a brief that already knows what's overdue, what meetings I haven't processed, and what I should focus on. After a meeting with my boss, or any meeting that I've used otter.ai with, I type /debrief and it pulls the transcript, extracts my action items, flags political dynamics I should pay attention to, and tells me what to go check on the floor. At the end of the day I type /close and everything gets logged.

Two weeks in, Claude knew my facility better than my own notes did. I've hit the ground running, people are already impressed with how much I am aware of historical and tribal knowledge and the best thing is I'm actually performing more efficiently. This isnt perfect and as I fine tune it for efficiency and to my job, I'll post a v2 in a few months.

GitHub repo with genericized templates so you can build your own: https://github.com/ballyhofam-bot/claude-project-os

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 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

&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.