You just learned the book, movie, video game framework. Vote below, then tell us in the comments: name one thing in your work that you now realize is on the wrong layer.

You just saw how context changes per task. Vote below, then tell us in the comments: what two areas of your work did you set up, and did Claude behave differently in each one?

You learned the framework. Now try it on something you're actually working on. Vote below, then drop your prompt structure in the comments. Not the output. The structure. Show us how you set it up.

Hey folks 👋 Packaged an icm-builder skill — helps scaffold projects, generate routing tables, and track what needs updating when you change a contract or reference file across stages. GitHub: https://github.com/carloswecare/icm-builder WARNING: Not a substitute for the courses and fundamentals — just a helper for when you're already building. First attempt, open-sourced on GitHub. Would love PRs, issues, or a "you're solving the wrong problem" if that's the case 😄 — Carlos

Hey everyone! 👋 I’ve been spending a lot of time thinking about how we build, and Loop Engineering have been popping up lately... I’m really curious to see how you all view the relationship between Loop Engineering and ICM. I’d love to get your quick thoughts on a few fundamental questions: 🤝 Do they naturally intertwine? To me, Loop Engineering is all about how the agent acts—creating autonomous cycles of execution, verification, and self-correction. On the other hand, ICM is about where the agent lives—using transparent folder structures and markdown files to manage context. Do you see them as a natural duo? Does a great autonomous loop need a clean file structure like ICM to keep from losing its mind? 🏗️ Can Loop Engineering be the framework FOR ICM? Instead of looking at them as separate tools, can we use the concept of Loop Engineering as the actual structural framework to drive an ICM workspace? For example, using the agent's looping logic to systematically move files from a 01_inbox to a 02_processing folder? Or do you think keeping the looping logic and the context methodology strictly separate is a better approach? 🤷‍♂️ Or are they just for completely different use cases? Are we trying to force a connection that shouldn't be there? Do you use Loop Engineering for heavy task automation, but prefer to leave ICM strictly for human-in-the-loop, highly readable research workspaces? 💬 What’s your take? - How do you define the connection between Loop Engineering and ICM? - Are you combining them in your current builds, or keeping them completely separate?