I pretty much use claude for everything at the moment. I'm a software developer, and to be honest I really enjoy the way sonnet (at the moment 4.6, 5 uses my tokens too quickly :) writes code. All of my routing and context files seem to work great with claude so no issue there. My issue is the more and more productive I am getting with the system the quicker I am ripping through tokens, so I have started to palm off different tasks to different models to see how successful I can be at still maintaining a smaller cost footprint with the two subscriptions I have at the moment (claude and chatgpt). I have just asked codex to update some of my context files and the edits have specifically called out codex by name... i.e.... ```Codex should not perform this process. Codex should tell the developer which step is needed and stop for the developer's result.``` (I like to be in control of when the database migrations happen for example). However these instructions are not for Codex alone, they are for, quite frankly, any AI or Human that reading my codebase. Okay, mostly AI, but the main reason for documenting all of this specifically is it forces me to document my process to allow anyone (AI or human) to pick up the project in the shortest amount of time. This is the reason I love ICM. I'm getting off topic, but how do I re-write this in a way that makes sense not only for codex, but for claude, gemini, kimi, human, whoever is reading this? Do I call out AI specifically? "AI should not perform this process"? Do I use inclusive language like "We should not perform this process"? (indicating it might be a BA doing this, as the next line will be "We should tell the developer...."? Quite curious to hear peoples opinions on this, trying to keep the documentation as documentation instead of specific to a model.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 🎯 PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 💻 Code review editor for a specific language and level (junior TypeScript, senior Python) - 📊 Pitch deck editor for pre-seed founders - 🎨 Grant application editor for arts nonprofits - 📄 Resume editor for career switchers into tech - 📰 Op-ed editor for policy publications - 🎙️ Podcast script editor for interview shows - ⚖️ Legal brief editor for civil litigation - 📋 Product spec editor for early-stage PMs - 🎓 Academic paper editor for one specific field The more specific, the better. "Writing editor" is too broad. "Op-ed editor for tech policy publications targeting a policy audience" 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 editor is a folder with five things: - 📄 identity.md (who the editor is, what work they review) - 📐 rules.md (how they critique) - 💬 examples.md (what good critique looks like) - 📚 reference/ (style guides, checklists, frameworks the editor uses) - 📖 README.md (how to use it) Drop the folder into a Claude project. Claude becomes the editor. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK An editor is NOT a rewriter. An editor doesn't do the work for you. An editor surfaces what's weak and pushes you to fix it. That distinction is the whole assignment this week. When someone hands the editor a draft, the editor shouldn't produce a "fixed" version. The editor should point at the three lines that don't work, explain why, and hand it back to the writer to solve. ✍️ Generic feedback like "consider strengthening your intro" is a fail. Specific feedback like "your intro assumes the reader already knows what a Series A is, but this pub is read by generalists, so lead with the stakes instead of the jargon" is what a real editor does.

📦 AND SOMETHING NEW: EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 WHAT WE DID DIFFERENTLY THIS TIME Every submission was cloned at the exact commit that was public when we read it, and read file by file. The brief. The identity. The rules. The reference layer. The code. Where a repo made a claim we could check, we checked it. Arithmetic recomputed by hand. Sample photos opened and compared against the outputs that cited them. Files diffed. Self-tests traced. Thirty-two repos, read at the code/word level. And one lens over everything, because it's the lens this whole community is built on: does the build keep the human's judgment where it pays and put the deterministic work in code, where it can't hallucinate? 📦 THE FEEDBACK PACKAGE This is the new thing, and it's for everyone not just the podium. 📦 COMP #8: THE WILDCARD - The Vault Every entrant gets a markdown file. Three parts: 1️⃣ The read. What your build actually is, and the strongest thing in it cited to your own files. Rule numbers. Function names. Your own examples. 2️⃣ One push. The single change that most improves your build. Not a list. One. 3️⃣ An idea worth naming something original in YOUR build, credited to you, that the rest of the community is told to take from. Plus links to the builds your feedback points at. Nobody walks out of this comp empty-handed. Thirty-two builds, thirty-two named ideas. The roster alone is worth the download. 📍 The package + the full write-up (what held up, what was missed) live in the new Feedback module: 📦 COMP #8: THE WILDCARD - The Vault 📚 WHAT THE FIELD TAUGHT Three lines split thirty-two repos: ✅ Enforcement. A must in a markdown file is a request. A must in code is a constraint. (That line is from one of your repos. It's in the package. Go find whose.) ✅ Evidence. The builds that shipped receipts of a REAL run transcripts, dated logs, before-and-after fixes read differently every single time.

🎟️ 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. 💪

When deploying an ICM folder structure to an actual client, asking them to drop it into their claude seems reasonable for us techy people, but some of my clients are not technical enough to even do that. What other options are people using? I'm a traditional web app guy, so deploying a cloudflare worker with some backend code and a database etc is what I would traditionally try and do. That model is not as clear cut as a winner as it used to be! Is it time to look at agentic systems to be able to deploy ICM so my clients can actually use it in their day to day? Or do we simply train them up to use claude? Or is there something else that people are doing?