I think I cracked the code on why we are all having a hard time with this second brain stuff. The real problem is that we are saving information that we think will be relevant to future endeavors, not just the stuff that is presently needed. Thus, we need rules that work in many (read "all") workspaces to make the information usable/searchable etc. These hypothetical rules would likely be more constraining than the rules that an actual use case would require. The second issue is that ICM is (correctly) very broad. Its principles map extremely well to the constraints of a task at hand, but poorly to undefined future tasks (like the goofballs making ICMs for imaginary problems) Possible solution: We stop saving unnecessary info and let our desired function determine the format (within ICM L3 Principles). That solution sucks, I still want to save info I don't need today!! I found a better solution... (If you just want the solution skip to the last paragraph. If you want some cool info on why your second brain doesn’t work, read on.) In practice, our L3 files are almost all SOPs. But the way an SOP is structured doesn't work for the way externally-authored source material should be kept for citation or lookup (which btw = split into its natural segments and indexed). This is why Tiago Forte’s PARA system doesn’t work, it’s built for helping a human decide what to do next, not have access to the relevant info. Google’s OKF fails because it's a format for shipping knowledge between tools/organizations, not the method for finding that info. Karpathy’s wiki fails because it defines only the loop (ingest / query / lint), so retrieval quality is only as good as the agents improvisation, its unreliable. RAG and vector databases are for bulk data, not a second brain. For instance, a million support tickets is a pile to query, not a knowledge base. Like our boy Jake likes to say (shout out Jake!), the principles for darn near everything have been around for decades. We're just applying timeless principles to an unrefined tool. The principle needed here is called faceted classification, developed by a librarian named S.R. Ranganathan in 1933, decades before we had a database to apply it to.

I explain the details about it on today's high tea . I built a Claude skill that turns a process, an idea, or a messy folder into an ICM workspace. The folder structure does the orchestration. Numbered folders carry the order, the hierarchy scopes context, and plain markdown files hold state. One agent walks the right files at the right time and does the work a multi-agent setup would. Repo: github.com/RinDig/icm-architect 📦 What it does Two modes. 🔨 Build. You describe your work and it pulls out the structure already sitting in how you talk about it. The stages, the points where you stop and check, what stays the same every run versus what is new. Then it picks one of five proven forms and scaffolds the smallest workspace that carries the job. ♻️ Restructure. Point it at a folder, repo, or vault you already have. It reads every file, sorts each one by role, shows you a migration map, waits for your yes, then moves and checks the result. 🧩 The five forms Pipeline, umbrella, record library, knowledge bundle, context map. They mix and nest, so most real workspaces use more than one. ✅ The walk test Every result gets checked cold. An agent with no memory has to open the root, find its way, act, and report status from the files alone. If it can't, the structure gets fixed until it can. ⚙️ How to use it You can honestly just tell claude to download it from the link, but if you're using codex or something else it will just have to restructure the claude.md to agents.md Or if you want to do more Hands-On install Claude Code: drop the folder in ~/.claude/skills/icm-architect/, then say "ICM this" or "build me a workspace for X." Claude apps: zip the folder and upload it under Settings, then Capabilities. Fork it, break it, tell me what you built. 👇

I’m philosophically in love with ICM. It hits all my principles. I love GSD because it guardrails AI with planned phases. Should I try to blend them together and risk isolating myself with a Frankenstein platform or should I just start from scratch and begin building using icm only? Anyone have experience or nightmares trying to integrate ICM with GSD or other structured approaches

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 🎯 PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 💻 Code review editor for a specific language and level (junior TypeScript, senior Python) - 📊 Pitch deck editor for pre-seed founders - 🎨 Grant application editor for arts nonprofits - 📄 Resume editor for career switchers into tech - 📰 Op-ed editor for policy publications - 🎙️ Podcast script editor for interview shows - ⚖️ Legal brief editor for civil litigation - 📋 Product spec editor for early-stage PMs - 🎓 Academic paper editor for one specific field The more specific, the better. "Writing editor" is too broad. "Op-ed editor for tech policy publications targeting a policy audience" is right. 🗂️ THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your editor is a folder with five things: - 📄 identity.md (who the editor is, what work they review) - 📐 rules.md (how they critique) - 💬 examples.md (what good critique looks like) - 📚 reference/ (style guides, checklists, frameworks the editor uses) - 📖 README.md (how to use it) Drop the folder into a Claude project. Claude becomes the editor. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK An editor is NOT a rewriter. An editor doesn't do the work for you. An editor surfaces what's weak and pushes you to fix it. That distinction is the whole assignment this week. When someone hands the editor a draft, the editor shouldn't produce a "fixed" version. The editor should point at the three lines that don't work, explain why, and hand it back to the writer to solve. ✍️ Generic feedback like "consider strengthening your intro" is a fail. Specific feedback like "your intro assumes the reader already knows what a Series A is, but this pub is read by generalists, so lead with the stakes instead of the jargon" is what a real editor does.

OK so, for MONTHS, I've been watching Jake's videos thinking to myself "someday, I'll get myself out of this cluster*uck of a Frankenstein stack I've built because I've forgotten all the things I've done to create it" fantasizing about a structured, standardized, and scalable world where I can actually trust my AI... and that's exactly what it was... a thought, knowledge about. I understood what Jake was SAYING, I could SEE and UNDERSTAND how it worked, but it was always a 'thought about' and I never really jumped in (ready, aim, aim, aim, aim, aim...). Yesterday, I saw this competition posted and thought to myself, "f*ck it... just do it... whatever that means, just do it, the competition is just an excuse.. LEARN HOW TO DO THIS" and am I EVER HAPPY I DID! I started out my journey 6 months ago using Claude with VS Code to create data engineering scripts to automate the transformation of data that I'm so obsessed with to build insightful dashboards (I'm a management consultant). THEN, I discovered GSD and spent the next two months obsessing 18 hour days, thriving in its structure. THEN every instagram influencer and their dog showed me bright shiny objects every day that I immediately jumped on and experimented with, slowly walking into a maze I'd never left breadcrumbs behind me to get back out of... and I got lost. Some good days with wins, other days screaming at my AI in caps as though it were human... and I forgot... AI can't EVER be trusted UNDER ANY CIRCUMSTANCE, unless it is STRUCTURED. Plain and simple. If I can't SEE 'the thing', if I don't know how the thing changed, or got made, then the AI is not to be trusted. But all the while I knew, because I'm a data guy, that the key to getting out of the desert I had wandered into was independent, agnostic, physical structure. Enter Jake... this crazy enthusiastic dude who also lives offgrid, and who is ADAMANT about STRUCTURE, in fact somewhat obsessive. So I obsessed over ICM, except all I did was everything BUT USE IT. I built my own knowledge vault about ICM, interactive wiki, a maturity assessment tool to assess my stack against ICM capabilities etc etc... but I never really used ICM other than to validate hunches about how to creatively engineer/integrate disparate datasets for dashboards. Yesterday changed all of that. I FELT the structure, the certainty, the freedom of my cleared cognitive cache with of all the mental energy otherwise spent being paranoid, now redirected back into the thing I love to do... create! Thank you Jake. I went to sleep fantasizing about how I am going to rebuild my stack, how I'm going to restart my projects from the ground up, and slowly, steadily, rebuild a foundation I can trust and thrive in. That said, I know my creativity will tempt me to experiment with integrating ICM with some other 'stable/structured capabilities like OpenBrain, GSD, Matt Pocock's Software Engineering Skills, and so on... but this time, I will be able to fall back on ICM as my mainstay because I am fundamentally aligned with the principles of ICM... sovereignty, structure, authoritative, agnostic... THANK YOU @Jake Van Clief !! Can I have a witness??? LOL!!! 🤩