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

https://theforgechain.com/forgereflexion

Most people drive AI like a slot machine. Type a vague wish, pull the lever, hope. Wrong output, pull again. Three hours later: forty messages, half right code, no idea which version was good. That is not building. That is gambling with extra steps. The fix is not a cleverer prompt. It is a plan. Here is the exact habit, start to finish. The one idea Stop prompting. Start defining outcomes. A prompt is a wish. An outcome is a result you can check. AI accelerates, it does not generate. Point it at a clear target and it closes the gap fast. Point it at a vague one and it just gets lost faster. ———————————————————————— The chain (this is the whole method) 1. Brainstorm first. Do not open a chat and start barking instructions. Open a conversation whose only job is to decide what you are building. What does done look like. What must be true. What is out of scope. I use `/brainstorm` and answer one question at a time until the fog clears. 2. Freeze it in a spec. A spec is the brainstorm written down and made hard to argue with. Three parts: - Objective, in one sentence you could prove true or false. - Constraints, the rules that bound the solution. - Definition of done, where every item can be checked with a single action. If you cannot write the objective sentence, you are not ready to build. Better to learn that now, for free. 3. Break it into a phased plan. Turn the spec into ordered, bite sized phases. The rule that matters most: each phase must be small enough to finish in one sitting, with room to spare. 4. Hand each phase over as a typed brief. This is the part that does the heavy lifting. Read the next section. ———————————————————————— Think in PRDs A typed brief is a product requirements document, scaled to whatever you are making. It is the difference between "build me a settings page" and a short doc with a goal, constraints, acceptance criteria, and phases. It feels like bureaucracy. It is the opposite. The brief is a forcing function: - You cannot write acceptance criteria for a feature you do not understand.

The context was not in the model. It was not in the tool. It was an asset I owned. Today I ran a test that I consider a real benchmark for the ICM methodology. I built a folder structure for Curiositas: one set of files designed to hold state, routing, identity, organizational knowledge, operating context, and the way we work. First, I asked Claude Code to pick up the work. Correct response. Right context. Correct identity. Current state of the work recognized. Then I opened Codex. I had never used it before. Zero setup. Same exact question. It read the right files by itself, understood the routing, and returned the same context: identity, state, open tasks, and direction of the work. Different words. Same content. Everything is documented in the video. Then I asked Claude to evaluate the result. The screenshot says: “solid result... this is basically a clean pass on the portability test.” And that is the point. This is real portability. This is real persistence. It means building something that does not belong to the platform, the model, or the AI tool I happen to open that day. It belongs to the structure underneath. It belongs to the asset I am building. I had already tried to solve this problem before finding ICM. I saw AI tools as fragmented by nature: a new tool every day, context scattered everywhere, work spread across different places, and nothing that truly remained mine. My answer had been to build my own framework. It taught me a lot. But in the end, it was becoming as fragmented as the problem it was trying to solve. I was working a lot, but the result kept moving further away. ICM is the layer I was missing. You are no longer designing inside the tool or inside the model. You are designing the structure that survives both. Jake Van Clief describes this as the future of how we will build software: a new way of communicating with machines. After this test, I understand why. I worked on this Curiositas lobby for half a day. From now on, I will improve it every day. I will make it more efficient and more tailored to me, to my way of working, to my processes, and to my company.

Focus is becoming one of the rarest assets in business. Everyone is distracted. Notifications. Meetings. Emails. Messages. Constant context switching. The organizations that learn how to protect attention will outperform those that don't. Focus = momentum.