We officially launched the new Clief Notes Agent, and I wanted to check in with you. Have you had a chance to talk to it yet? If you have, I’d love to hear how it went. And if you’ve run into any questions, confusion, or issues getting started, drop them in the comments below. The goal is to make it easier to find what you need, know what to focus on next, and get more out of everything already inside Clief Notes. So, How’s your experience been so far?

It’s live. Starting today, everyone in Clief Notes has access to the new Clief Notes AI. The easiest way to use it? Don’t overthink it. Ask it the question you would normally ask me. “Where should I start?” “What should I focus on next?” “Where did you talk about [topic]?” It’ll use what’s already inside Clief Notes to help answer you and point you toward the right lesson or resource when there’s something worth going deeper on. The goal isn’t to give you another AI tool to play with. It’s to make everything already inside this community easier to actually use. If you want Access to it Comment "READY" and we'll send you access to it!

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 📋 THE CHALLENGE Build a folder-based AI diagnostician that reads something broken and tells you WHY it's broken. Not how to fix it. Why it failed. This week's deliverable is one diagnostician folder that someone could drop into a Claude project and use to figure out why something in their world isn't working. 🎯PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick a failure you've actually seen happen. A few sparks to get you thinking: - 📉 Why a landing page isn't converting - 📧 Why cold emails to a specific buyer aren't getting replies - 📋 Why a product spec keeps getting pushed back by engineering - 📄 Why a resume isn't getting callbacks in a specific industry - 🚪 Why users drop off at one step of an onboarding flow - 💸 Why a pricing page isn't converting trials - 🎥 Why a YouTube video underperformed the channel average - 🤝 Why a sales deal stalled after the demo - 📱 Why an app's retention craters in week two The more specific, the better. "Diagnoses marketing problems" is too broad. "Diagnoses why cold emails to enterprise IT buyers get opened but never answered" 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 diagnostician is a folder with five things: - 📄 identity.md (who the diagnostician is, what they diagnose) - 📐 rules.md (how they diagnose: what they look at, how they separate cause from symptom) - 💬 examples.md (2-3 example diagnoses showing the reasoning) - 📚 reference/ (common failure modes, diagnostic frameworks, benchmarks) - 📖 README.md (how to use it, what to feed it) Drop the folder into a Claude project. Claude becomes the diagnostician. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK A diagnostician is NOT an editor. Last comp was The Editor. That one critiques craft. It looks at a draft and says "this part is weak, go fix it."

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