Someone shared that a person a reaction video was made about my method and at first I was nervous but immediately it was amazing praise. I have never met with this person one-on-one and I haven't paid them or done anything other than post my own videos ! I think they do a great job at breaking some of the concepts down. It does an amazing job of breaking down some of the logic especially some parts where I go ranting in my video he slows it down a bunch ! Much needed

We talk about folders all day, but the folders are FOR something. I want to know what... 🎖️Bonus points: comment with the single most painful manual process in your industry. The best comp entries come from exactly those answers.

I'm assuming I'm not the only who's done this and please tell me if it's a bad idea, but I'm assuming we've all turned ICM structure into a Claude skill? If I've got a new project I run /init-max that I've built, and Claude generates folders and MD files based off questions it asks me. It's not allowed to assume answers unless I blatantly say I'm not sure. To build it I've just pointed Claude at module 3 in the foundations classroom and said "make this a skill". Has anyone done the same or is this a terrible idea?

Most ICM setups I see here are single-operator: one person, one agent, one context tree that's basically externalized working memory. We're running it differently — as the shared know-how of a small engineering firm (~15 people: industrial automation, control-panel building, light EPC). That one shift, from personal to organizational, changes the whole problem. In a company, the context isn't just my memory — it's the procedures everyone has to follow, and procedures have to be governed, auditable, and improvable by people who will never open a terminal. Here's the core of what we've landed on. One markdown source, three readers. The ICM KB — plain markdown in GitHub — is at the same time: - the agent's operating context (what it reads to act: load costs into the ERP, build quotes, enforce the process); - the company's procedure manual, rendered into a navigable wiki — search, cross-links, the graph of how procedures interconnect — which is what employees actually read; - the ISO 9001 controlled-document system, because Git already is change control: versioned, attributed, diffed, immutable — stronger than the Word-on-a-shared-drive most small firms limp along with. No parallel copies, so nothing drifts. Git is the evidence vault; the wiki is the auditor's reading room. (Worth stating for this crowd: ISO 9001 mandates control — identification, approval, versioning, availability of the current version — it mandates no specific format. A git-backed static site clears that bar cleanly.) The agent is the abstraction layer — this is what makes it survive in a company of non-technical people. Nobody learns markdown, Git, or pull requests. They talk. The agent enforces the current procedure while they work; and when someone says "step 3 is wrong, we do Z now," it turns that into a proposed change to the controlled document. The quality lead gets a plain-language summary and approves or rejects. Proposing is frictionless and open to everyone; approving is a controlled human gate. The Git/PR machinery stays invisible underneath.

Officially kicked off my one man show business, where i will be running my business using this folder structure I have learnt here. I was initailly struggling with what to "do"/ the idea. One of the things I have that always have to be in my memory thou is this ICM works well for sequential reviewable and repeatable.