I have a client in Australia who's looking for someone who understands ICM and can help him work on his software. Obviously he would prefer someone a bit more technical, but he's happy to have some people who are trying to learn as well. It's a pretty large software, but he's created a pretty good automated system and obviously he's using my methods so it's very well organized. Anyone out here looking for a project to take on the practice or learn more? Or is there anyone in the morning to get a little bit more work done at a higher level? He's looking for multiple skill levels.

I use Claude Code across all my projects, and the workflow I actually run isn't a one-off task, it's a handoff pattern between Desktop and Code that's become the default way I start almost anything. What I built: I spitball and pressure-test an idea in Claude Desktop first, working through the thinking before any files are touched. Once the idea is solid, I ask Desktop to produce an actual prompt, a real brief, not a vague summary, that I then hand directly to Claude Code to kick off the project. Biggest insight: the two interfaces aren't competing tools, they're sequential stages of the same workflow. Desktop is where the thinking happens and the direction gets set. Code is where that direction actually gets executed against real files. Trying to do both in one interface either wastes Code's file-access power on pure brainstorming, or forces Desktop to fake file work it was never built to do. Why it mattered: this closes the exact gap the lesson describes, the Read → Think → Write → Check → Adjust loop running once and stopping in Desktop versus running continuously in Code. By doing the "think" part fully in Desktop first, the prompt I hand to Code is already specific and well-formed, so the loop in Code moves straight into productive iteration instead of burning early cycles figuring out what I actually meant. One thing I'll do differently going forward: formalize this as an actual step in my process rather than something I do informally. A real handoff brief, written in Desktop, handed off as a distinct artifact, before Code ever opens a file. That's the missing Phase 3 I've been meaning to build into my own Pre-Build Framework for a while now, and this lesson made the case for it.

I'd be interested in hearing from experienced software engineers using ICM for serious, ongoing development, especially those who were building software before AI coding tools became part of the workflow. I'm not looking for a vibe coding setup where an agent gets a feature request and runs with it. I'm interested in using ICM to support disciplined software engineering while preserving architecture, testing, standards, and continuity over time. I already have a system, but it evolved organically and is more ICM-inspired than a coherent ICM implementation. I'm now trying to rethink it more systematically. A few things I'd love to hear about: - How do you structure ICM for a greenfield software project? - How do you introduce it into an existing codebase? - How do you organize architecture, rules, strategy, milestones, decisions, and source code? - What does your feature lifecycle look like from scoping through implementation, testing, and review? - How do you scope context so the agent gets what it needs without loading the whole project? - What rules stay in context versus being enforced by tests, scripts, linters, or other gates? - How do you keep project state and decision history useful without creating stale or bloated context? - How does the ICM evolve after months of development? I'm not necessarily looking for a complete workspace or one correct answer. Directory structures, examples, lessons learned, things that failed, or practical tips would all be useful. I'm especially interested in setups where AI becomes part of a disciplined engineering process rather than replacing the engineering process with prompting.

It’s live. Starting today, everyone in Clief Notes has access to the new Clief Notes AI. The easiest way to use it? Don’t overthink it. Ask it the question you would normally ask me. “Where should I start?” “What should I focus on next?” “Where did you talk about [topic]?” It’ll use what’s already inside Clief Notes to help answer you and point you toward the right lesson or resource when there’s something worth going deeper on. The goal isn’t to give you another AI tool to play with. It’s to make everything already inside this community easier to actually use. If you want Access to it Comment "READY" and we'll send you access to it!

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 📋 THE CHALLENGE Build a folder-based AI diagnostician that reads something broken and tells you WHY it's broken. Not how to fix it. Why it failed. This week's deliverable is one diagnostician folder that someone could drop into a Claude project and use to figure out why something in their world isn't working. 🎯PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick a failure you've actually seen happen. A few sparks to get you thinking: - 📉 Why a landing page isn't converting - 📧 Why cold emails to a specific buyer aren't getting replies - 📋 Why a product spec keeps getting pushed back by engineering - 📄 Why a resume isn't getting callbacks in a specific industry - 🚪 Why users drop off at one step of an onboarding flow - 💸 Why a pricing page isn't converting trials - 🎥 Why a YouTube video underperformed the channel average - 🤝 Why a sales deal stalled after the demo - 📱 Why an app's retention craters in week two The more specific, the better. "Diagnoses marketing problems" is too broad. "Diagnoses why cold emails to enterprise IT buyers get opened but never answered" is right. 🗂️THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your diagnostician is a folder with five things: - 📄 identity.md (who the diagnostician is, what they diagnose) - 📐 rules.md (how they diagnose: what they look at, how they separate cause from symptom) - 💬 examples.md (2-3 example diagnoses showing the reasoning) - 📚 reference/ (common failure modes, diagnostic frameworks, benchmarks) - 📖 README.md (how to use it, what to feed it) Drop the folder into a Claude project. Claude becomes the diagnostician. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A diagnostician is NOT an editor. Last comp was The Editor. That one critiques craft. It looks at a draft and says "this part is weak, go fix it."