Finally giving my view on JEV in my classic history and fundamentals fashion but... This one is a little different. It's my first time making a fully animated, pixel art video, and I'd honestly love to know what you think of the style. Should I make more like this? I made an ICM that fully automates most of the process i was able to get this video built in about three or four hours. Talk about a fun animation style right? Might redo a bunch of the videos in the classroom with this.

Hi All! Looking for people with experience using ICM and Claude CoWork. CoWork does not load folder-level context files. I tested it: pointed CoWork at my ICM folder, asked it about a rule that lives in CLAUDE.md, and it had no idea. It sees the files, but not the map. No routing rules, no conventions, no "where things go". The only fix I've found is putting those instructions in the global/project instructions field so they're always in context. That works, but it's a workaround, and it doesn't scale to per-folder context, which is the whole point of an ICM in the first place. So the question: has anyone gotten CoWork to actually read folder-level context files, any way other than pasting the instructions into the global instructions? Why this matters to me instead of just using Code: - Yes, the Code tab in the desktop app loads everything correctly. - But I have been working as an "AI mentor", helping people use AI in their jobs, and most of my customers are non-technical. They are visibly more comfortable in CoWork. That is the interface they will actually keep using. - @Jake Van Clief I have seen you say in some of your videos "if you use CoWork you just point it to the folder", but I have never found the in-depth version. And pointing at a folder whose map never gets read kind of defeats the purpose of having a map. If anyone has a pattern here (a filename CoWork does auto-read, a project-level setting, a different folder structure that works) I would love to hear it. Happy to test whatever and report back. @Ry Mac I have been recently following you, and just saw your SMB video... I also saw you stating you were the messenger between CoWork and Code (lol) ... do you have a workaround to make sure CoWork "sees" the right file? @Christian Trujillo you brought me here ... any insight from your customer work?

This community is large and it moves fast. That's the good part and it's also the problem: valuable posts get buried, the same questions get re-asked instead of found, and spammers show up wherever there's an audience. These guidelines are what keeps the room worth showing up to. Read them once. You won't need them again, because most of this is what you'd do anyway. New here? Start with Jake's welcome post and the Foundation course. This post is about how we behave, not where to begin. 1. Build in public. Post the thing while it's half working. A half-finished build is more useful to everyone else than the polished writeup you'll never get around to, and you'll get corrected before you've spent a week going the wrong way. 2. Teach what you learn. The day you figure something out is the day you're best at explaining it, because you still remember exactly what confused you. A month later you've forgotten the hard part and your explanation gets worse. If you cracked something this week, that's a post. Nobody has to earn the right to ask a question here, but this place only works because people come back and answer them once they can. 3. Ask good questions. Specific beats polite. "How should I structure this?" gets three vague answers. "I have a 40 file client folder, the model keeps loading the wrong context file, here's my CLAUDE.md" gets a real one. Say what you tried, what happened, and what you expected instead. A more in depth guide: https://dontasktoask.com The flip side of this: "Anyone here?", "Help please", and one line questions with no context may get removed. Not to be harsh, but because nobody can answer them. 4. Give credit. If you built on someone's skill, template, folder structure or comment, tag them. It costs you nothing and it's the reason people keep publishing their work here instead of keeping it. A lot of the best material in this community started as somebody's reply on somebody else's post.

You just unlocked one more roadmap. This week, it’s David’s Corner. We’re going to be releasing a new roadmap every single week, but there’s a reason we’re doing them one at a time. I want to make sure you actually have time to go through each one, digest what you’re learning, and complete the work before moving on to the next. Each roadmap is designed to walk you through the material step by step. You’ll go through the lessons, answer questions, take short quizzes, and complete accountability posts along the way. The goal isn’t to give you more content to consume. It’s to help you actually complete what’s already here and put it into practice. So this week, your next step is simple: Go to the Roadmap tab, jump into David’s Corner, and start working your way through it. Next week, we’ll unlock another one. We also have some pretty exciting updates coming to Decster over the next month that will make this experience even better. More on that soon.

Hi All! I was going to combine this post with a CoWork question I have, but they're different enough that I'm splitting them into two posts. First (hopefully) helping, then asking for help: If you keep your ICM in Google Drive, don't use symlinks. I learned this the hard way: the Drive process ballooned to ~30GB of RAM trying to resolve them and my machine was crawling for a couple of hours before I connected the two. The setup that caused it: CLAUDE.md was my folder map, and AGENTS.md was a symlink pointing at it so Codex/Cursor (or any other AI agent) could read the same context. Worked fine until Drive got involved in some folders. Flipped it. Now: - AGENTS.md is the real file in every folder. All the actual context lives there. - CLAUDE.md is a one-line stub containing exactly @AGENTS.md. Claude Code inlines that import at load time, so Claude always sees the full context. Codex, Cursor, Windsurf and Aider read AGENTS.md natively. One source of truth, zero duplication, and critically, zero symlinks, so Drive and OneDrive stay happy. Creating a new folder is two steps, and I have both written into my root AGENTS.md so Claude does it automatically: write the context into AGENTS.md, then create the stub. The stub is literally one line, @AGENTS.md, nothing else. I have a PostToolUse hook that enforces it inside Claude Code: write a new AGENTS.md and it auto-creates the stub; write a CLAUDE.md with real content and it moves the content into AGENTS.md and leaves the stub behind. But the convention works fine without the hook. One caveat worth knowing: the @import is a Claude Code feature. Other agents read AGENTS.md directly, so they never need it. If anyone has a cleaner way to keep folder context tool-agnostic, I'm interested. This is just what survived contact with Drive.