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

I have a hypothetical workflow with 3 stages. The first stage plans, the second writes, and the third reviews. It works great if it there's no issues found in the review. But what if it finds problems? Should it undo all the content it wrote and start over, or should it keep what it wrote and make a revision?

I spent yesterday building out four old Weekly Comps. #4 through #7. I didn't submit any of them, and every one of them closed months ago. It was probably the most useful day I've had in here. What I didn't appreciate until I tried it: the winners and honorable mentions are still sitting in the stacks. That's an answer key. When you enter a comp live, you build blind and find out afterward how you did. When you build an old one, you read the brief, build your version, and then go compare it against work that already cleared the bar. And you can borrow, out loud, with credit. That changed what I built. On #5 the winner used a schedule-lock, so I adapted it into a number gate: no scripts, no frameworks, nothing until the user says one number, unhedged. On #7 I took the ordered short-circuit gate flow from the winner's two entries. On #6 I took "announce your interpretation before you act" from Mayston. Each one still needed something of its own, and having the winner in front of me made that easier to find rather than harder. I could see what was already covered and go somewhere else. The one I'd point at is #4, The Agency. The brief asks for a real-estate agency OS, and the winner built exactly that, publicly. I almost rebuilt it. Then it occurred to me that a five-folder Austin real-estate system on my GitHub, sitting right next to an existing public winner, reads as derivative. And I don't know real estate, so every handoff between specialists would have been invented. So I built the same architecture on my own back office instead. Same five folders, different vertical. The handoffs were real because I actually run them. Then I added a validator that exits non-zero on a malformed handoff card, and it caught two genuine defects in my own examples while I was writing them. None of this gets submitted anywhere. It's four repos I didn't have on Friday. If you joined late, or you looked at a comp and thought you didn't have time that week: the brief is still there. So are the winners. Go build the old one.

Failed to Load Page ERR_CONNECTION_REFUSED (-102) URL: http://localhost:3000/ I am getting this error again and again. Actually I was building a next js website and I am adding one section at a time using opencode. I need help to solve this issue.

This is part 2. Part 1 is the month that broke me, and this one hits different if you've read it: https://www.skool.com/cliefnotes/why-its-been-so-quiet-from-my-crazy-loud-corner-of-the-world Go ahead. I'll wait. ------------------------------------ Okay, on with the story (And a warning, this one is a little longer than my usual, which already tend to be a little long. It's because I'm getting into the real details of the business system I run on, and I want to provide value, not just fluff) My team benched me. Last week of June, a few days after we got home from the NICU, they told me to take three days off. Not suggested. Told. I was a royal mess at home, my family needed me all the way there instead of half there, and everybody could see it except me. Then they went ahead and had the meetings without me. Last post ended on a claim and I promised I would deliver receipts. I said if I didn't have a system, a team trained to run inside it, and accountability to keep us honest, I'd be updating my resume right now instead of chasing more clients. Okay, so this post is the receipt. It's what that actually looked like, for a month straight. ------------------------------------ First, what the thing even is ------------------------------------ We run on EOS. Entrepreneurial Operating System. It's a way of running a company that a lot of small and mid-size businesses use, and it is way less exciting than it sounds, which is exactly why it works. There are six pieces to it. The official names are Vision, People, Data, Issues, Process, and Traction. In regular human: 1. Vision. Everybody knows where the company is going and how it gets there. 2. People. Right people, right seats, and everybody knows exactly what they own. 3. Data. A handful of numbers you look at every week so you see trouble before it's trouble (in a perfect world). 4. Issues. A running list of what's broken, opportunities, questions, etc, all worked in order, with things actually coming off it.