A few days in. Starting to see where the Clief Notes AI is actually becoming useful. Some of you are using it to figure out where to start. Others are asking specific questions and getting pointed back to lessons or drops they didn’t even know existed. And some are basically using it as search: “Have we covered this before?” That last one alone saves a lot of scrolling. @Anthony Brady shared a really good example of how he’s been using it. He said the agent has been helping him find the right lessons, figure out where to go next, and actually apply the material to what he’s building. He’s even been pushing it with harder questions, and when it doesn’t know something, it tells him instead of just making something up. What I really liked was how he described using the tools together: The agent helps him navigate. NotebookLM helps him go deeper. And Decster keeps him moving through the course, completing assignments, and staying active in the community. That’s exactly what we want this to become. Not another AI tool you open once and forget about. Something that actually helps you use everything already inside Clief Notes and keep moving forward. We’ve also caught a few questions where the agent could’ve pointed somewhere better. Keep sending those. The more you use it, the better we can make the experience. This thing should get more useful as we see how you actually use it. If you haven’t tried it yet, start simple. Ask it the next question you would normally post in the community. Have you tried it already? If not, comment “Navigator” and I’ll send you access to it.

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.

Everyone is building at AI speed right now. That is fine for most of the app. It is a terrible place to freestyle authentication. A half-baked login looks "done" in a demo and fails under real users: broken sessions, weak password flows, MFA bolted on late, multi-tenant gaps, cookies that only work on localhost. The model will happily invent a sign-in form. It will not invent a security posture. This is where a tool like https://clerk.com earns its seat. Not because it is magic. Because it stops you inventing the one surface that should never be improvised. Clerk is an excellent Auth skill and for new SaaS, prototypes, and startups where speed-to-market is the metric and the stack is modern frontend. It is a poor tool when at consumer-scale unit economics are the product constraints. This is not "never build auth." It is "do not invent the front door while the rest of the app is still a sketch." The principle: Velocity is only a win if the you don try and speed run the boring bits. //A<3

Planes keep a black box so that when something goes wrong there is a full recording of what happened and when. Build the same thing into your ICM system: a logbook it writes itself, every job and every journal, that you can hand back to Claude at any point. The setup is simple. Every Claude Code job writes a short record when it finishes - what it did, how it went, a grade, and any errors. Every design chat writes a journal when it is done drafting your ideas out. Every handover is stored in a set space. All of the above - ORGANISED Nothing is thrown away. The record just builds on its own in the background. Then, any time you have spare usage, point Claude at the whole logbook: pull the bits that ran slow, the bits that failed, and the improvements worth making. Once the logbook exists, here is what it gives you: - Query anything - ask in plain language what happened, when, and why. - Find the mistakes - surface exactly where and when something went wrong. - Improve the whole system - point at the record and tell it to fix the system as a whole - Security audits - every change that was made, timestamped and ready to review. - Client work - hard evidence and the answer already sitting there if a client complains. - Investor conversations - the same record holds up when you are showing what you have built. - Older systems - go back and read what a system used to do long after you have moved on from it. - Across projects - copy edits and systems from one project directly into another with ease And this is where it goes next. Fairly soon you will be able to hand a model every logbook across every project you run and let it treat the whole thing as training data - not to answer questions about the past, but to learn how you actually operate and carry that forward on its own. The record stops being something you query and becomes the material a system clones itself from: your decisions, your patterns, the way you work, all already written down. That is the real reason to start now. Every entry you log today is training data for the autonomy you hand off tomorrow.

📦 AND SOMETHING NEW: EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 WHAT WE DID DIFFERENTLY THIS TIME Every submission was cloned at the exact commit that was public when we read it, and read file by file. The brief. The identity. The rules. The reference layer. The code. Where a repo made a claim we could check, we checked it. Arithmetic recomputed by hand. Sample photos opened and compared against the outputs that cited them. Files diffed. Self-tests traced. Thirty-two repos, read at the code/word level. And one lens over everything, because it's the lens this whole community is built on: does the build keep the human's judgment where it pays and put the deterministic work in code, where it can't hallucinate? 📦 THE FEEDBACK PACKAGE This is the new thing, and it's for everyone not just the podium. 📦 COMP #8: THE WILDCARD - The Vault Every entrant gets a markdown file. Three parts: 1️⃣ The read. What your build actually is, and the strongest thing in it cited to your own files. Rule numbers. Function names. Your own examples. 2️⃣ One push. The single change that most improves your build. Not a list. One. 3️⃣ An idea worth naming something original in YOUR build, credited to you, that the rest of the community is told to take from. Plus links to the builds your feedback points at. Nobody walks out of this comp empty-handed. Thirty-two builds, thirty-two named ideas. The roster alone is worth the download. 📍 The package + the full write-up (what held up, what was missed) live in the new Feedback module: 📦 COMP #8: THE WILDCARD - The Vault 📚 WHAT THE FIELD TAUGHT Three lines split thirty-two repos: ✅ Enforcement. A must in a markdown file is a request. A must in code is a constraint. (That line is from one of your repos. It's in the package. Go find whose.) ✅ Evidence. The builds that shipped receipts of a REAL run transcripts, dated logs, before-and-after fixes read differently every single time.