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

The week's editor competition has been been, i wanted to go through the comments to learn from other peoples work but 174 comments read was much for my attention span 😀. So i decided to build a compilation of the submissions and share here. Hope you find it as helpful as me. 1. @Ron Rath - GitHub Link: https://github.com/ronrath/engt581-artifact-editor - Link: https://www.skool.com/cliefnotes/weekly-comp-9-the-editor?p=3548224b - What it does: The Review Gate is an artifact editor designed for ENGT 58100, a graduate AI-in-manufacturing course at Purdue. Built using the ICM methodology, it acts as a human review gate for the course's own student submissions. It evaluates weekly artifacts such as cited workplace briefs, annotated bibliographies, AI workflows, and capstone projects to ensure they meet course standards. 2. @Toby Iverson - GitHub Link: https://github.com/BytesFromToby/for-the-record - Link: https://www.skool.com/cliefnotes/weekly-comp-9-the-editor?p=3548224b - What it does: "For the Record" is an objective editing tool designed to help individuals prepare oral testimony for city councils, school boards, or zoning hearings. It helps users stay on time and focused when delivering emotionally charged or frustrating public speeches. The editor reviews draft testimony to ensure the message remains clear, concise, and impactful within strict time limits. 3. @Natalee Champlin - GitHub Link: https://github.com/nataleechamplin/the-constraint-editor - Link: https://www.skool.com/cliefnotes/weekly-comp-9-the-editor?p=f5ad4805

I've been hearing and seeing a lot lately about some big-name companies pushing to ban open-source AI models. I'm curious what everyone here thinks about it. Personally, I'm in favor of open models because I believe they encourage innovation and accessibility, but I know not everyone feels the same way. What's your take on it?

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

In the actual ICM documentation provided here, it references a CONTEXT.md file being used in the directories to describe what happens in the directory, process, what files and what good looks like. I've also seen some videos where folks are using AGENTS.md in their subfolders performing the same functions. Does the name matter for any reason or is it the contents and the fact that it's referenced in the map that matters? Just making sure I'm not missing something here.