I played around with team voice assistant over the weekend. It's not perfect but the idea is that any time i'm not around, people can pop in a voice chat with agent and ask any questions regarding to our projects, community, onboarding, assist with meeting like one of our member. I'm also equipping him with the ability to draw visual with remotion/hyperframe, take message when im not around, take meeting notes/feedbacks and a management page to control what context + skill + asset he has permission to use. Just curious, if anyone has also been working on something like this ?

Hello everyone, I just recently came across Jake's videos and I learned a lot from them. I just installed this or the ICM skill and let it rework my whole Claude code folder. After seeing how effective it is and making it more my style, i came up with two questions: 1. My first question is: does it matter how big the main folder gets? So can I have one main folder with every app, personal workflow, or project in there? With the whole ICM process? Or is it better to split that up and make seperate folders for different uses cases? 2. My second question: how can I use ICM with Obsidian efficiently? ICM already creates a bit of a memory/context for every part of the folder, but how can I make Obsidian a strong extra pillar of memory in there. So i can have a shared vault with my business partner and our projects are in line with the company's state. Please help me out with this. I'm open to learning and thank you for reading.

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.

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.

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.