📦 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.

Some lessons I've learned from weekly comp #9 - The Editor: - It's impossible to know the real impact of our systems, but they can be way bigger than what we thought. Four real people used my editor to help with their grant proposals. One of them posted the reply of my editor into the oficial whatsapp help desk of the Call for Proposals. It flagged a mistake in their own documentation: The call contradicts itself about its own deadline: one annex says December 2026, the body says 31 June 2027 — a day that doesn't even exist. There are 200+ people in this whatsapp group and they were all benefited from this one little flag. - There's no way to build a great system if you don't ship it and make first contact with the users. I've shipped my Editor and every real grant proposal it analyzed became an improvement opportunity. Ship fast, learn and iterate. The learning layer needs to be baked into every system from the get go. Ask for feedback as soon as possible. One of them, recording his band's second album, sent back thirteen minutes of voice notes to me. He'd gone through the critique one finding at a time, and told me, kindly, that two things in my summary were broken. Both are fixed now. - Showing the system's shortcomings is not detrimental. It is an asset. Capturing the improvement history allows you and others to see patterns and use them to avoid the same mistakes on your next build. Fixing the mistakes and just deleting the old version so people think you got it right the first time is not useful to anyone. One of those mistakes I made was that my system classified if the flag was confirmed by the official documentation or it was based on past learning on how to write a good grant proposal. The problem was that I didn't explain to the user how to read and understand the classification. After the feedback all new critiques start with an explanation on how to read this document. These competitions are a real way of improving your own systems of building and shipping. It forces you to face real challenges. Make sure you test them in real life!

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

Despite all the ai hubbub and second brains someone asked what I read and IF I read at all anymore. The answer is most certainly YES. You can make connections that might be missed by a million questions with AI by diving into books and reading your self. Some books may not even have most of their pages on the web especially older ones and those are often my favorite. Here are 4 of my current favorite readings to prepare me for the future (by looking at the past) 1. Mythical Man Month (1972 by Fred Brooks) 2. Psychology of Computer Programing (1971 by Gerald M Weinberg) 3. Augmenting Human Intellect (1962 Douglas Engelbart) 4. The Creative Act: A Way of Being (2023 by Rick Ruben) Rick Rubens book is just great in general for business and creative acts.

Intros for The Connection Hub - The Vault 👤 Who I am: (name + where you're based) 🛠️ What I actually do: (the specific work — not "I'm in real estate" but "I run a 3-agent team doing residential resale in Austin") 🤖 What I'm building with AI right now: (your current project, workflow, or the thing you're stuck on) 🎯 What I'm looking for connection-wise: (pick one or two) 💡 Someone who's solved [X] 🤝 A collaborator / accountability partner 👀 Just here to learn from people in my field 🧰 Trading workflows & systems 📬 Best way to reach me: (DM here / comment / link)