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

Anyone in here also in the hospitality/bar-restaurant industry? I have a hard cider brand with two taprooms and we're building a few AI systems for onboarding and training and marketing/promos. I'd love to hear from others about what you're building as well :)!

Have you tried any tools or skills for turning a book into .md files or skills? I found this https://www.claudecodehq.com/playbooks/book-to-skill Any advice?

TL;DR How can I build my folder/file system so that it can be accessed and used across devices? I am always on the go, sometimes working from my phone, sometimes my laptop, sometimes my husbands laptop, sometimes my desktop. I'm looking for a central hub to store my files on that will sync across devices. Is anyone already doing this? I've been using Obsidian Sync with a backup to GitHub but since I want to be able to use Jake's ICM system with the third layer of files and artifacts, Obsidian doesn't seem to be working great for that. Is anyone building their whole knowledge base right on GitHub or using a different cloud solution?

ICM's premise is that structure replaces orchestration: folders and markdown carry each stage's context, and one agent reads the right files at the right moment. The paper assumes that agent is capable. I wanted to see if ICM holds when the agent is a small local model you run yourself. It does, by leaning on two things ICM already gives you. Stage-scoped context becomes injection. In ICM the agent roams the workspace and opens what it needs. A model served through Ollama is not that agent. It is an inference endpoint that takes a prompt and returns text, with no file access and no navigation loop, so it cannot roam the folders at all. The engine reads the files and injects each stage's context into the prompt instead. Same principle, each stage sees only what it needs, delivered by code rather than fetched by the model. "Scripts handle what doesn't need AI" becomes an oracle per stage. ICM keeps the mechanical work out of the model. I extend that one step: every generative stage is checked by a deterministic oracle (for code, the compiler and its tests), because a small model proposes well but can't verify itself. Reliability stays in the structure, not the model. That is the whole port. One stage one job, plain-text artifacts, factory vs product, human-reviewable files: all carry over unchanged. ICM and MCP stay complementary, as the paper notes, with the folder structure deciding context and the stage's tools exposed over MCP. The result is a frontier-free assistant: the same methodology, running on hardware you own, for tasks that are narrow and checkable. Two repos, MIT, pure stdlib (you bring Ollama): - Rust coding assistant: https://github.com/CurtisSlone/ICM-Local-Model-Rust-Coding-Assistant - Reusable base to make your own: https://github.com/CurtisSlone/ICM-Local-Model-Base I also have a coffee test example that is way more simple than the coding assistant.