Hi! I made it to the end of section 2 in the free material and then got a bit carried away. Returned and finished the courses after building my workspace and paid for Premium. I've a couple questions id appreciate some thoughts/guidance/insight on. 1. Cloud based workspace 2. Applying the vault 3. Creating workspaces as a service 1. Cloud based workspace I've seen (yet to read) the remote access lesson but im pretty sure this will just be operating your desktop Claude and not what im thinking. Im thinking of moving the desktop folder to the cloud using proton drive and Termux on my phone, to make it accessible anywhere. Does anyone have any better suggestions? Reasons why this might be a bad idea? The implications of doing this when there is more than just your own data in the workspace (confidential, others personal etc.) 2. Applying the vault I shouldn't have got carried away and just followed the lessons step by step. But I didnt. I've got quite meta with my workspace capabilities operating behind the actual outputs and implemented a lot of things ive yet to see covered in the lessons (basic learning loops at every HITL step, audit processes to address drift (skill level and workspace level), session continuity protocols, context mining the session at hand off for processing later into optimally formatted source material for things like content, reporting, achievements etc. There's more but i share to make the point, im a little apprehensive at running the vault. I dont know what I dont know and id hate to accidentally wipe what ive built already. Im thinking about pointing my workspace at the vault and asking it to see what we can learn and implement. Does anyone have any suggestions or insight into this that may help guide me? 3. Workspace creation as a service One of the projects ive set up in my workspace is one to create workspaces for other people without them needing to fully understand whats happening under the hood. Since signing up for Premium, I see Jake is basically doing this for us. I've got a lot to dig in to and learn but ahead of that, I wonder if anyone might be able to help prime me on this topic in particular? Any suggestions on how to approach learning this or implementing it?

Hi everyone. Is there any rule of thumb on how many words in every layer of an ICM workflow? Im trying to narrow it down in a large repo with many canonical things that apply for every workflow and I have 1263 words in layer 0 and a context routing of 871 words.

How my workspace audit works (and what's deliberately left out here) I run an ICM-structured workspace for my own work, and built a structural audit for it that came up in a conversation elsewhere. Starting this as its own thread so it stands on its own for anyone interested, not just the people already in that one. One thing worth saying up front: what follows is a stripped-down version of the real thing. My actual setup has a fair bit more wired into it (a decision log that learns from repeated corrections, a long list of specific maintenance triggers, and more). I've left all of that out here on purpose, so this stays focused on the part that's genuinely reusable and widely applicable, rather than tied to my own specific workspace. The core idea: an audit only ever diagnoses and proposes. It never changes anything on its own. Even if the session is set up to act autonomously, the audit overrides that and waits for my sign-off on every finding. That one rule is what makes it safe to run regularly without worrying it'll go off and "fix" something I never asked it to touch. Three principles sit underneath it: 1. Diagnostic, not corrective. It finds drift and proposes fixes. I decide, one finding at a time. Nothing gets edited during the scan itself. 2. Mechanical checks before judgement. A small set of deterministic checks runs first (broken links, orphaned index entries, count drift) so I'm not relying on the model's judgement for anything a script can verify outright. 3. One shared quality bar. The same rubric governs creating, editing, and auditing. Not three different standards for three different moments. It runs in four phases: a full read-only scan of everything, findings presented in priority order, collaborative decisions with nothing implemented yet, then implementation only once I trigger it. Anything deferred or declined gets logged so it isn't lost. The rubric scores against ten dimensions: things like right altitude (specific enough to guide, not so rigid it breaks), token discipline, separation of concerns, currency, proportionality, and evidence over invention, each scored against a clear pass mark.

One thing I’m learning in AI is that you can create something genuinely useful even if it isn't polished or fully vetted. Honestly, I'm creating things I don't even fully understand. ha ha We see other folks showing off their latest success and eyes-wide-open stare at the screen thinking "Sheesh. They are so impossibly smart." Maybe I'm the only one doing that. But there are a few things to understand. First, not everything we think is “perfect” is actually perfect. Sometimes it is just the best version we can see from where we are standing. Second, we don't all have the same background, so what I think is a "Win" is a win for me. It might not be a win for you. What I struggle with sometimes is wanting my work to be as perfect as I can make it BEFORE I share it with anyone. That's why I didn't enter any competitions until Comp 7. I really didn't want to be embarrassed. But, I entered anyway thinking I'll just do my best and learn from the process of building. I'm SO GLAD I DID. A few things I learned: -Your first version can be messy. -Your folder structure can change. -Your workflow can have gaps. -Your system can grow. That does not mean it failed. It means it is becoming something. I think sometimes we wait to build until we can make the “perfect” version, but the perfect version usually comes after the rough one teaches us what we actually need. AI gives us so many new ways to create, test, and improve. I don’t want to miss that because I’m overthinking every piece before I begin. So here’s my little reminder, mostly to myself, but perhaps also to you: Make the thing. Let it be imperfect. Pay attention to what it teaches you. Then make it better. I appreciate each one of you and the way you encourage me and one another.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. ---- 📋 THE CHALLENGE You are the client this week. No fictional Marcus. No fictional Sarah. No fictional Devon. Pick a real problem in your own life or work. Build the folder-based specialist you wish you had. This is the capstone of Month 2. The challenge flips. Instead of building for someone else, you write your own brief and solve it for yourself. ---- 🎯 THE TWIST The hard part isn't building. The hard part is scoping. Picking the right problem is harder than solving the wrong one. Most people pick problems that are too small or too vague. The skill this week is treating yourself like a real client. Be specific about what's broken. Be specific about what you need. Don't pick "I want to be more productive." Pick "I waste two hours every Sunday night writing the same kind of LinkedIn carousel posts and I need a folder that handles 80% of the draft work so I can focus on the hook and the visuals." That's a real brief. Specific problem. Specific scope. Specific desired output. ---- 🗂️ TWO DELIVERABLES THIS WEEK This is the only week with two pieces: 1️⃣ Your own client brief. 250 words or less. Describe the problem you're solving for yourself. Treat yourself like a real client. What's broken? What have you already tried? What do you need? 2️⃣ The folder system that solves it. Same structure as every week: - 📄 identity.md - 📐 rules.md - 💬 examples.md - 📚 reference/ - 📖 README.md Your brief lives at the top of the repo as brief.md so judges can read it before they look at the folder. ---- 🔥 THE ANGLE THIS WEEK Anyone can follow a brief. Writing your own, then solving it, then shipping it as a usable folder is a portfolio piece that demonstrates judgment, not just execution. This is the skill that separates "AI hobbyist" from "AI builder." Anyone can prompt their way through a problem someone else handed them. Scoping a problem, designing the solution, and shipping it as a system is what real work looks like. 💪