I have a client in Australia who's looking for someone who understands ICM and can help him work on his software. Obviously he would prefer someone a bit more technical, but he's happy to have some people who are trying to learn as well. It's a pretty large software, but he's created a pretty good automated system and obviously he's using my methods so it's very well organized. Anyone out here looking for a project to take on the practice or learn more? Or is there anyone in the morning to get a little bit more work done at a higher level? He's looking for multiple skill levels.

TLDR: As is the case for several of us here, we’re only allowed to use Microsoft Copilot at work. I wanted to take an ICM approach to a large scale contract audit and validation assessment using Copilot, so designed the workflow at home with Claude to generate a “work pack” of agents, Notebook instructions, and prompts to install at work. One key learning for me was that even though ICM shaped it well, I hit multiple session limits and an embarrassingly large number of tokens polishing the specification in Claude before implementing anything in Copilot. The problem: Part of my day job includes keeping a large ICT contracts register honest against the actual evidence sitting in SharePoint: renewal dates, pricing, which document supersedes which, etc etc. Often a case of reporting vs reality drift, plus the register has multiple scenarios difficult for a direct approach to analyse e.g. vendors that are intentionally duplicated as separate rows in the register (single reseller, multiple individual/separate software contracts), large single contracts that cover multiple major agreements, and invoices, managed separately, that extend a contract term based on annual payments. I don’t have a team supporting me, I’m ‘it’ and contract management is just one part of my job so I’m having to juggle over a hundred vendors along with managing finances and other commercial requirements for a large IT department. At work the rule is that it's Microsoft Copilot or nothing, so the design has to survive being executed manually inside Copilot Chat, Notebook/Researcher/Analyst, and Agent Builder, with a documented fallback for anything not currently available within our tenant e.g. we don’t have access to Cowork (yet). In my initial attempts with Copilot, using the “WorkIQ” functionality enabling it to reference SharePoint and internal documentation (including emails and Microsoft Teams), it pulled in old workbooks, unrelated vendor documents, and just a whole bunch of wrong data – despite trying to lock it down – and royally messed things up.

34 entries. Jake, Don, David on isolated piles, then a panel. This one was hard. A few of you built things that would have won a different competition, and you should hear which one. Every entry got feedback, link at bottom of post! 📋 What we actually judged The post asked for one folder a stranger can drop into a Claude project. identity.md, rules.md, examples.md, reference/, README.md. It reads something broken and says why. Not how to fix it. Four questions, from the post: 1. Does it diagnose? One cause. Not a list. Not a prescription. 2. Is the domain specific enough to be useful? 3. Does each file do one job? 4. Can a stranger figure it out? That is an outcome. Can a person who is not already in your head use this to see why something in their world broke. A lot of the field went further. Refusal paths. Verifiers. Blind runs. Preserved failures. Those are real, and they are extra. We did not pick a winner on the extra. We picked a winner on the ask. this does not mean extra is not better, in many cases I LOVED the solutions created. If the outcome had been different, the name on this post changes honestly 🥇 Winner: Colm Whelan — Inbox Autopsy https://github.com/RockfieldIT/inbox-autopsy A stranger holding a bounced invoice can drop the folder in and see why it bounced. That was the assignment. 🔄 Where someone else wins 🔧 If the outcome was "the instrument that can prove itself wrong" — Sergey Manevitch, Radix https://github.com/sergeymanevitch/Radix Why a machine failed in a plant that already has notifications, rounds, and historian trends. Fourteen cold runs. He left the breaks in his own claims standing. A plant engineer is holding something serious. 🧪 If the outcome was "every claim reproduced, including the one that failed" — Pemmy Broke, Visual Momentum https://github.com/hoodwanders/visual-momentum-diagnostician Why an AI explainer lost momentum. She published the run that broke her own doctrine, changed the rules, and the re-run abstained. That is the standard the rest of the field should steal from.

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

Codex Micro is a small product with a large design implication. It does not treat AI as another application to open. It gives the agent a physical interface. A dial for reasoning depth. Keys for commands and agent states. A joystick for skills. Lighting for feedback. Layers for different workflows. The invisible parts of working with AI become tactile. That is the interesting bit. The design question is no longer: Where can we add AI? It becomes: - What should be physical? - What should be visible? - What should be adjustable? - What should happen without a screen? - Where should the human intervene? - What does the AI need to communicate back? The product is designed around the behaviour of the AI, not just the existing shape of a keyboard. That is a useful test for any physical product built for this next phase of computing: If you removed the AI, would the object still make sense in exactly the same form? If the answer is yes, perhaps the AI was added to the product. It was not designed around the AI. The future of physical product design will not be about putting an AI button on familiar objects. It will be about designing around delegation, feedback, memory, autonomy, and human intervention. The result might look like a keyboard, a camera, a notebook, or something completely new. But the design logic will begin with a different question: What does the AI do, and what should the human be able to feel, see, or change? That is the shift. Not AI added to objects. Objects designed around AI. https://worklouder.cc/codex-micro //A<3