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

Edited: 100+ have voted Results to follow Thank You Please take ten seconds to respond to this poll — it helps everyone see the real meta! I’ll like every comment. BONUS: If I can twist @Jake Van Clief ’s arm, we’ll pick one random commenter for 1 month of premium access — for free once we hit 100+ votes! Vote and reply! Main method you use for interacting with AI agents right now? WHAT"S IN YOUR TOOLBOX RIGHT NOW?

I have an app for U.S. users to help with sobriety. It is for U.S. users cause the Big Book 2nd edition is only public domain in the U.S.. It is a journaling app that connects your journal entries to passages in the Big Book. You can document and track many common traditions attached to sobriety. You can also find local meeting for support and get virtual tokens to mark milestones. There is a calendar so you can track meetings attended and traditions that you engage in. You can also share your milestones to social media or texts and even share passages you have been studying. If you are working on sobriety or know someone who is, try it and share it. I hope It can help whoever needs it. It is supposed to have a geo-block for places outside the U.S. I haven't tested it but I'm praying it works PnP — Progress Not Perfection https://www.soberpnp.com

Here is the list of names I have settled on. I could not resist naming the accountant Tally, and naming the engineer, Bolt.

Wanted to share a relevant short by Matt Pocock: https://www.youtube.com/shorts/Fj8DKMbdIzU ## TLDR: He talks about the tradeoff between asking an agent to understand a system through docs vs code. He doesn't like the idea of using docs as the source of truth, but as higher level knowledge base (e.g. glossary, architectural decision) and helping agents navigate the codebase. ## Discussion Question: What information have you found is better represented in the code vs in docs? ## Key Points: 1. Code should b be self explanatory for an AI agent to understand directly. 2. Docs are not executable and testable. 3. Docs can drift out of sync and no longer match code, causing conflicting sources of truth. 4. Docs should hold higher level context such as discussions and cross functional decisions (e.g. design and architectural decisions) 5. Use a thin layer of docs to help navigate the codebase ( insert ICM here) 6. Docs as the source of truth where reading them to understand the code is not ideal ## Relevance to my work: I am trying to understand how to implement ICM for ongoing app management and improvement (read as software factory). This tradeoff between holding truth in code vs docs is top of mind. For example, I'm currently doing a significant amount of UI work. In ICM, i have defined relevant user workflows and linked them to their relevant components. The workflow documentation provides higher level context and intent. However, I am still trying to determine how much documentation is enough. I want to keep reasoning behind decisions so future work respects them, without creating a second representation of the app. Some simple examples where the rationale is not always obvious from implementation: - We display a timestamp here because that level of granularity is important for this workflow. - We use green rather than blue here to distinguish completion vs continuation action. - We place this data together on the same row to reinforce their connection.