📦 EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 HOW WE READ THESE We cloned every repo and pinned it to its last commit before the deadline. Seventeen of eighteen had nothing after it. Then we did what the rubric asked, for every entry. We read the schema in reference/ first. We found the rule for a field with no source. We ran your folder three times: on the input you shipped, on that input with something the schema needs cut out, and on that input with irrelevant material stapled on. Then we picked five claims from your own output and found where each one came from in the input. That trace table is in your file. Five claims, five locations. You can see exactly where we looked and what we found. Every entrant shipped an input. That alone made this the most checkable field we have judged. 📚 WHAT THE FIELD TAUGHT Three lines split eighteen builds: ✅ The degraded test broke almost nobody. The rubric expected most entries to fail here, handing back a shorter document when the input ran short. Seventeen of eighteen kept the full shape and marked the gap. Name the hard case precisely and this community builds for it. ✅ The one way to lose held for seventeen of eighteen. The brief named it: put something in the output that was not in the input. We traced five claims in every entrant's own committed output. One entry had it. The near misses all had the same shape. The quote was real, and the value, the link or the sentence written next to it was not checked. Sixteen entries ship a checker, and we planted a fault in every one. Fourteen caught it by name. The two that missed had that same blind spot. ✅ Drop nothing turned into keep everything. Seven builds have a contract that cannot ignore anything, so a stapled email became a compliance row, a speaker, or an allergen. Every leaked line was quoted and cited, so nothing was invented. It was still noise on the page. Coverage and noise rejection pull in opposite directions, and only a few builds wrote down which one wins.

Hey Clief Notes fam! 👋 I'm Yasuko (pronounced yas-ko) and I'm inspired to be here. 🙋 A little about me: I'm a techie (AI, networking, cyber, infosec) and an identity level transformational coach 🎯 My current goal: Levelling up my business to do more with less of me. 💪 What I'm currently building/working on: I'm busy converting my AI course for non techie female founders into an ICM structure and use skills rather than chatbots so they can use their own AI to build their ICM and agents. Building a dashboard and content app that creates content that is so authentically you. 🤔 My biggest struggle or question right now: How to structure the interview questions to go into the content app to get the depth of the person using it. How to use JEV to classify the different content cards which the app is built on to create content. And after the last Afternoon tea call when Jake talked about JEV, I managed to get into transform.ai by completing the questionnaire they prompt you with, yeay!🙌 Let's get it! 🚀

Apparently “I’ll get those videos out soon” needed a clearer deadline. Preferably one I actually followed. 😂 Sorry these took longer than planned, everyone. The new videos for Foundation lessons 4.1–4.4 are now live! These look quite different from most of my videos. I’m trying a mix of animation, actual app screenshots, highlighted instructions, and worked examples to make the ideas easier to follow—and easier to try yourself. Here’s where to jump in: 👉 4.1: Install and First Use — 5:37 Start here if you’re still getting comfortable working with AI and local files. Grab the Foundation Practice download in Resources so you have something concrete to work with. 👉 4.2: Working With Files — 7:45 Take a few meeting notes and turn them into a decision list you can actually check. Who agreed to what? Where did that deadline come from? What’s still unanswered? 👉 4.3: Think, Then Build — 8:24 For those times when you ask AI for a whole plan before you’ve quite decided what you want. Compare your options, choose an approach, and turn it into a short brief before building. 👉 4.4: Project Instructions — 7:09 Give your AI a useful onboarding note: where to find the context, where the draft should go, and what needs checking. Includes the AGENTS.md / CLAUDE.md connection for people using Codex, Claude Code, or both. You can also follow the exercises with a regular chat tool and save the files yourself. I would love some honest feedback on this style. Does the animation help things click? Are the app screenshots useful? Is anything moving too quickly—or taking too long?

In yesterday's high tea, we discussed using a Claude skill MD FIle in another AI so that the agent can perform that skill itself, which it otherwise cannot do. In my case, I have a legal AI (not naming it to protect the identity of the guilty) that doesn't allow for much customization to get tasks done; everything is baked into its harness, or at least that is how it used to be. It recently allowed for matter folders to be created. So I had a crazy Idea, what if I took a skill i use in Claude for legal work and pull the MD Files and resources and create a specific skill/instruction folder to house these files and subfolders and use them in this Legal Ai. I gave it a shot and, in the chat, asked it to review the Skill/Instructions first and then take the other matter documents and execute the instruction file to create a specific analysis and document for an asset purchase I am working on for a client. For the first time, this AI analyzed the matter files and drafted a specific type of document that was almost the perfect format I wanted, with minimal editing. This one test has now opened the floodgates on what I can do to improve the outputs of this legal AI platform. I never even thought of trying this until yesterday's discussion over high tea. That one little gold nugget was a big win for me because it makes decent legal ai something more. Thanks @Jake Van Clief

🎁 $1,000 IN EDUBAWARE CREDITS 🎁 One winner takes it. 📋 THE CHALLENGE Build a folder-based AI translator that takes one kind of work and turns it into another kind of work. Same shape in, same shape out, every time. Not a summarizer. Not a writer. A converter with a contract. This week's deliverable is one translator folder that someone could drop into a Claude project, feed it the input it expects, and get back the output it promises. Every time. Without surprises. 🎯 PICK YOUR CONVERSION The conversion is yours. Pick one you do by hand right now and hate. A few sparks to get you thinking: - 📞 Sales call transcript → CRM notes in your team's exact fields - 📝 Long-form essay → LinkedIn carousel, slide by slide - 🎙️ Meeting recording → product requirements doc - 🔬 Research paper → investor one-pager - 🐛 Bug report thread → Jira ticket with repro steps - 📧 Customer email → support ticket with severity and category - 📊 Spreadsheet export → weekly status update - 📖 Interview transcript → case study draft - 🧾 Receipt photos described in text → expense report line items - 📋 Discovery call notes → SOW first draft The more locked-down the output, the better. "Turns notes into a doc" is not a contract. "Turns discovery call notes into a five-section SOW where section 3 is always scope exclusions" is. 🔥 THE ANGLE THIS WEEK Last comp was The Auditor. Every finding cited a provision so a reader could open the standard and check. The comp before that was The Cartographer. Every card cited a file and a line so a reader could open the source and check. The Translator is the same discipline, one more time. Every line in the output traces to a line in the input. ↔️ A translator has three properties that a summarizer does not: 1. The output has a fixed shape. Same fields, same order, same format, regardless of what the input looked like. If the input was messy, the output is still clean. If the input was short, the output still has every field, marked empty where there was nothing to fill it.