Activity
Mon
Wed
Fri
Sun
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
What is this?
Less
More

Memberships

154 contributions to Clief Notes
VS code VS. chatting with Claude through my terminal.
Can anybody help me? So I followed a lot of the steps and I got all the way to visual studio code and I’ve started creating agents. However, I’m not sure that I’m doing it correctly because I am hitting my limits with visual studio code maxing out at 99%. However, by following your instructions and chatting with Claude through my terminal. I don’t blow through my Claude limits. Claude within my terminal builds, markdown files and folders underneath my company that I’m building, but I seem to be confused on how they connect and I need guidance if anybody wants to chime in.
2 likes • 15h
@Sarita Elliott have you gone through all of the classroom lessons and built your first workspace(s) then? Agents are much farther down the line after you have repeatable systems and processes. Starting with the foundation will definitely help you get more usage while burning less tokens.
"Prompt Modifier" - Orchestrator
Before ICM I called it a "Prompt Modifier". At it's core, a markdown file, instructions to tell AI how to operate with the task at hand. This isn't building agents, it's the how, with a handful of instructions. At a high level, the Orchestrator manages handing off work to subagents. Built to be LLM agnostic, drop in to any chat, point to the file, or wire it into ICM with a trigger when needed. The main chat stops doing all the work and instead organizes, delegates, and manages communication. I've seen this catch a lot of errors, assumptions and hallucinations. Plans are better. Execution is improved. This also allows higher level model usage, without all the token costs. I'm usually using Opus, on high effort. --- An analogy I used when sharing with my brother-in-law, military vet. Think of Claude like a Team Leader. - Claude manages the agents instead of doing the work himself - A "research agent" is sent out to get the information and bring it back - Claude writes up the assignment, then sends a "worker agent" to do it and report when it's done - Then a "verification agent" checks that the worker actually did the job right - If it didn't, Claude keeps working the agents until it passes So if you're not getting what you want, talk to the Team Leader and tell him to fix his sh*t. --- I've used a version of this over the last 3+ months, it has helped cut down on token usage, while getting what I need done quicker. Building this into my ICM system has been a force multiplier. If you use this I would love some feedback to add to my backlog, still iterating on it. *Attached slide with some additional detail.
"Prompt Modifier" - Orchestrator
3 likes • 17h
@Tim Svensen This is pretty solid! The fresh verifier and “verify the real artifact, not a staged copy” rule are key. That is where a lot of false usually gets blended in. I’d watch authority as a potential blind spot. The orchestrator improves how work gets done, but it stll needs a clear answer for: - what scope is approved - which files are protected - which source wins in a conflict - what requires human approval - where state gets updated - where the final results return Overall, this feels like a strong start to a runtime layer. You could pair it with a source-of-truth and approval model so the sub-agents are working inside the right boundaries. Or do you have that already?
1 like • 15h
@Tim Svensen yes, some of it falls more in my governance layer, read on load for any work in the OS as needed. It becomes more crucial in design and development usually. There was another good community discussion here a while back on terminology/glossary and that will help whatever AI stay on track so it stops reinventing conventions or wording in new sessions.
The five shapes of an ICM workspace (this is the part that finally clicked for me)
This comes straight from the ICM method (I asked Claude to explain to me), so none of it is my invention. But seeing the five forms written out as plain shapes made the whole system land for me, and I'm actively building with it right now, so I wanted to share it the way it clicked. Every ICM workspace is one of five shapes, or a mix of them: 1. Pipeline. Same steps, run over and over, new deliverable each time. Think of a recurring 30-page client document: data in, checks run, sections drafted, reviewed, published. One folder per step, numbered in order. 2. Umbrella. Several different workflows that share one brand, voice, and reference layer. One shared folder holds the facts (brand guide, company snapshot, templates) and every workflow points at it instead of keeping its own copy. One home per fact. 3. Record library. The unit is not a run, it is a thing that accumulates: a client, a lead, a property, a patient. One folder per record, growing over time. The trap here is tracking status by moving files between folders. A status log inside the record is cleaner. 4. Knowledge bundle. The product IS the organized knowledge. A wiki, a second brain, course notes. The value is that a person or an agent can walk it and find things. 5. Context map. The subject is a whole organization. Teams, processes, where everything lives, and a small routing file at the top that answers "where does X go" in one read. The part that surprised me: they compose. My real setup is a context map at the top, holding an umbrella of shared facts, containing pipelines, publishing into record libraries. That's not breaking the rules. That's the normal case. One warning from experience: don't build folders for work you might do someday. I once built a beautifully organized workspace for future tasks, and it sat empty forever because nothing real ever flowed through it. Start with what "done" looks like (a phrase I picked up from @Ari Evergreen. If you can name the deliverable that comes out the other end, and you're already producing it the painful way, build the structure around that. That workspace gets used on day one, because the work is already there waiting for it.
3 likes • 15h
@Jeff Van Leenen I went through this too, but mine is a little bit more opinionated so I broke it down into components and layers. The umbrella shape seemed to be to be more of a rehash so I swapped that one out. Now I have a workspace architect that interviews naturally anytime I need to build a client workspace and it’s working pretty well! Scales with complexity and works off of templates so I don’t have to decipher each new build, same terminology and format for each new iteration. Solid post, thank for sharing! Jake’s repo is awesome for anybody looking to understand the architecture better, and makes it super simple to build anything you want: https://github.com/RinDig/icm-architect
Epiphany!
I just realized that the way I’ve been organizing files my entire life whether it’s on a thumb drive in my phone or on a computer was always a ICM methodology. I know this sounds crazy because obviously ICM and Jake are new to me. As I looked stress stressed out on how my harness and AI model where organizing all the information I gave them about ICM. I took a break and watched a couple movies and as I was looking through my picture folder and looking at my computer, I had this epiphany. The next step was to re-organize my folders with the terminology of an ICM folder for AI to read and me understand before completely screwing up something and getting lost in the sauce. Next- Add the .md addition to the sub folder system, same concept different media.
Epiphany!
1 like • 17h
@Snake Pliskan
Folder Structure for Business Template
I am running a business B2B but curious about adding more brains for each skill. Most of you already good at folder structures and using it, what if you had to build a new business what folder structure you will made? Such as Branding.md, Email Writing, Objections handling etc etc. Would love to see your examples!
2 likes • 22h
@Muhammad Naveed Haider The list you gave is actually not folders, they would typically be reference/ files. This needs to be defined up front because it changes the whole structure you'd build. In the actual ICM setup, the split is: reference material (stable items that do not change per client or per run - brand voice, objection scripts, ICP definition) versus stages (the repeatable pipeline your business actually runs). Branding and objections handling belong in the reference layer, sitting in one shared folder that every stage pulls from. The folders you're asking about should be your business's actual repeatable processes. It's ultimately up to you, but I would separate outbound client acquisition vs internal client service. Example internal structure / references / stages attached. Each stage only loads the reference files it actually needs, not the whole pile. If your objection-handling copy changes, you edit it once in references/ and every stage downstream picks up the new version next run. What's the actual sequence your business runs client to client? That's the real folder list - the reusable reference files just get pulled in as needed.
2 likes • 17h
@Muhammad Naveed Haider let me know if you need anything along the way
1-10 of 154
Aaron Kruger
6
1,378 points to level up
@aaron-kruger-1837
tokenmaxxing

Online now
Joined Jul 5, 2026
Powered by