User
Write something
Comp #10 Results Announced is happening in 6 hours
Pinned
Welcome to Clief Notes. Here's where to start.
1. Go check out 📚Navigating The Course to see how to get around and what's here. 2. Start with The Foundation. Concepts, folder architecture, prompting framework. Everything else builds on this. 3. Check in at the bottom of each lesson. Polls, discussion posts, other members working through the same stuff. Use them. 4. When you're ready to build real things join in on our Biweekly competitions and win some real cash. ⭐ Competitions Mega Thread 5. If you are wanting to dive into the masterminds, grab all the past templates, artifacts and resources. Upgrade and head into the The Vault for Premium and The Drawing Room (VIP) for VIP 6. Post your work. Ask questions. Help others when you can. What are you here to build?
Pinned
🏆 COMP #10 RESULTS — THE DIAGNOSTICIAN 🏆
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. If the outcome had been different, the name on this post changes. 🥇 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.
Community Guidelines
This community is large and it moves fast. That's the good part and it's also the problem: valuable posts get buried, the same questions get re-asked instead of found, and spammers show up wherever there's an audience. These guidelines are what keeps the room worth showing up to. Read them once. You won't need them again, because most of this is what you'd do anyway. New here? Start with Jake's welcome post and the Foundation course. This post is about how we behave, not where to begin. 1. Build in public. Post the thing while it's half working. A half-finished build is more useful to everyone else than the polished writeup you'll never get around to, and you'll get corrected before you've spent a week going the wrong way. 2. Teach what you learn. The day you figure something out is the day you're best at explaining it, because you still remember exactly what confused you. A month later you've forgotten the hard part and your explanation gets worse. If you cracked something this week, that's a post. Nobody has to earn the right to ask a question here, but this place only works because people come back and answer them once they can. 3. Ask good questions. Specific beats polite. "How should I structure this?" gets three vague answers. "I have a 40 file client folder, the model keeps loading the wrong context file, here's my CLAUDE.md" gets a real one. Say what you tried, what happened, and what you expected instead. A more in depth guide: https://dontasktoask.com The flip side of this: "Anyone here?", "Help please", and one line questions with no context may get removed. Not to be harsh, but because nobody can answer them. 4. Give credit. If you built on someone's skill, template, folder structure or comment, tag them. It costs you nothing and it's the reason people keep publishing their work here instead of keeping it. A lot of the best material in this community started as somebody's reply on somebody else's post.
My First Claude Code Project: Idea-to-Execution Handoff
I use Claude Code across all my projects, and the workflow I actually run isn't a one-off task, it's a handoff pattern between Desktop and Code that's become the default way I start almost anything. What I built: I spitball and pressure-test an idea in Claude Desktop first, working through the thinking before any files are touched. Once the idea is solid, I ask Desktop to produce an actual prompt, a real brief, not a vague summary, that I then hand directly to Claude Code to kick off the project. Biggest insight: the two interfaces aren't competing tools, they're sequential stages of the same workflow. Desktop is where the thinking happens and the direction gets set. Code is where that direction actually gets executed against real files. Trying to do both in one interface either wastes Code's file-access power on pure brainstorming, or forces Desktop to fake file work it was never built to do. Why it mattered: this closes the exact gap the lesson describes, the Read → Think → Write → Check → Adjust loop running once and stopping in Desktop versus running continuously in Code. By doing the "think" part fully in Desktop first, the prompt I hand to Code is already specific and well-formed, so the loop in Code moves straight into productive iteration instead of burning early cycles figuring out what I actually meant. One thing I'll do differently going forward: formalize this as an actual step in my process rather than something I do informally. A real handoff brief, written in Desktop, handed off as a distinct artifact, before Code ever opens a file. That's the missing Phase 3 I've been meaning to build into my own Pre-Build Framework for a while now, and this lesson made the case for it.
The Clief Notes AI is live 📣
It’s live. Starting today, everyone in Clief Notes has access to the new Clief Notes AI. The easiest way to use it? Don’t overthink it. Ask it the question you would normally ask me. “Where should I start?” “What should I focus on next?” “Where did you talk about [topic]?” It’ll use what’s already inside Clief Notes to help answer you and point you toward the right lesson or resource when there’s something worth going deeper on. The goal isn’t to give you another AI tool to play with. It’s to make everything already inside this community easier to actually use. If you want Access to it Comment "READY" and we'll send you access to it!
1-30 of 3,108
Clief Notes
skool.com/cliefnotes
What we give away free beats most paid courses. Build durable AI systems with a Marine vet and Edinburgh researcher. 40+ lessons, growing.
Leaderboard (30-day)
Powered by