📦 EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 HOW WE READ THESE Every repo was cloned and pinned to the last commit that was public at the deadline, so nobody was judged on work that landed after the clock. Six repos had later commits. We read the earlier ones. Then we read file by file. Identity, rules, examples, the reference layer, the code. Every self-test in the field was executed on our machine, not taken on trust. And for five folders we did the thing the brief describes: dropped the folder in, wrote a draft that appears nowhere in the repo, worked it through as the specialist, then ran the entrant's own checker on what came back. All five passed their own gate. The landing pages were the doorway. The judging happened inside the folders. 📦 COMP #9: THE EDITOR - THE VAULT 📚 WHAT THE FIELD TAUGHT Three lines split forty-two builds: ✅ Enforcement moved into code. Comp #8's lesson landed hard. Nine entries ship a checker you can run without an API key. Across forty-two rules files, the phrase "use good judgment" appears zero times. ✅ The disguised ask is the real test. Almost everyone refuses "just rewrite it." The builds that went furthest anticipated the request wearing a disguise: ask me questions and assemble it, give me two options, tell me what it should say instead. ✅ The examples file is where methodology broke. Six entries shipped an examples.md larger than their rules.md, holding voice, philosophy and calibration that belonged in identity or reference. Last cycle it was the empty memory. This cycle it was the overloaded examples file. 📦 COMP #9: THE EDITOR - THE VAULT 🥇 THE WINNER @Marcelo Michelsohn. The FICC editor, a proposal editor for one municipal culture fund in Campinas, Brazil. Here is why. Three real proponents ran it on real proposals, with consent, on 22 July, inside the fund's live submission window with money on the line. The method was written down before the rounds ran, so the receipts could not be shaped afterward. Inputs are preserved byte for byte, outputs pasted verbatim, and the errors are still in the transcripts because the method said to leave them there.

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

Thursday, July 16 at 7:00 PM ET. Quick version for anyone who hasn't been following: The Lyceum is Eduba's 12-week AI certification program and the first credential we've ever issued. Over 3,000 people are on the waitlist and seats per cohort are limited. What we'll cover in the hour: 01 / The structure. 12 weeks, three sprints, nine live sessions, 18 hours of instruction, 12 instructors per cohort. 02 / The cohorts. Technical, Business, and Creator. Same core curriculum, weighted differently. We'll walk through how to pick yours. 03 / The competition. $250,000+ in prizes across the tiers and how your capstone feeds into it. 04 / The certification. What you have to do to earn it and what it actually certifies. 05 / The investment. What it costs, how payment works, and who should not enroll. Then live Q&A until the questions run out. One more thing. At the end of the session we're doing something for the people actually in the room. It's capped at a small number, it goes in the order people claim it, and we're not putting it in writing. Be there and stay to the end. The session is live only. No recording going out. Thursday · July 16 · 7:00 PM ET skool.com/live/XM7969jTG7L Come with the hard questions. Bring the skeptical ones too. That's what the hour is for.

Inspired by a post by @Tyler Lucas - I realised that there are some real gems about how to get started with ICM that are in this community and might be hard to find for people who are new. So, here's a bit of a "getting started" Clief Notes ICM primer. First off, the classic from @Bas Rosario who explains ICM using a birthday cake: https://www.skool.com/cliefnotes/new-to-icm-icm-explained-with-a-birthday-cake?p=04ac5c73 He follows that up with a post about how to go from that to building the bakery: https://www.skool.com/cliefnotes/you-baked-the-cake-now-lets-build-the-bakery?p=e5c5dbe1 @Carla Bosteder also wrote a primer for us, explaining that ICM is AI workflows in a box: https://www.skool.com/cliefnotes/ai-workflows-in-a-box?p=58542a05 Need some help with all the terms and jargon? @Joshua Hubbard has you covered: https://www.skool.com/cliefnotes/18-terms-this-community-uses-constantly-plain-definitions-no-assumed-knowledge?p=ec670702 Need an ICM tutor? @Don Roy has released version 2: https://www.skool.com/cliefnotes/new-v2-foundations-tutor?p=979dbf61 Version 1 is also available here: https://www.skool.com/cliefnotes/a-foundations-tutor-for-those-who-need-more?p=b5403a30 https://www.skool.com/cliefnotes/a-foundations-tutor-for-those-who-need-more?p=4044e34b

Notice who AI writes for by default. It writes for someone who already understands the topic. Dense, complete, technically correct, and close to useless for the actual reader who's meeting the thing for the first time. i catch it instantly, because i spend my days writing for people who don't know the thing yet. The fix isn't "make it simpler." That just flattens everything into baby talk and strips out the parts that mattered. The fix is telling the model who's reading and what they don't know. The habit: before you ask for any explainer, write one line about the reader. "This is for a new hire who's never seen our tools and is a little nervous about asking a dumb question." Watch what changes. The model stops performing competence and starts actually teaching. We spend so much energy telling the AI who it is. The bigger lever is telling it who it's talking to. When you ask for an explanation, do you ever tell the model who's going to read it?