This is the website I created for them — pikolhaus.com. Small start, but officially my first real client project. More to come.

📦 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.

Built GovConnect using @Jake Van Clief ICM methodology. A digital platform for local government services — currently awaiting approval for actual implementation. Stack: Laravel · PostgreSQL · AWS · Nginx · Git/GitHub · ICM https://govconnect.junmarvi.com/ Feedback is welcome.

Apparently “I’ll clean up a few lessons” turned into rebuilding a whole module 😂 The classroom is now called AI Animations & Workflows, and Module 1 has seven new videos, eight connected lessons, and a clearer route from your first idea to a finished animation. I made this because I want you to be able to build a workflow you can keep using. Take an idea, give it a home in a folder, and have your AI help write the script, make the voice, plan the visuals, build the scene and export the video. The AI can do a lot of that work. Understanding what each stage produces helps you ask for useful changes and check whether the result actually explains your idea, right? We follow one small example through the lessons, then you use the same process for something of your own. The videos also use a new style: more visual explanations, app views, moving diagrams and examples that connect directly to what’s being said. Start with 1.1: Welcome and Your Route Through This Module, then work through: - 1.2 How This Video Was Made — see the whole process before setting things up. - 1.3 Get the Workspace Ready with Your AI — choose your starting route and prepare your project. - 1.4 Ask for a Script, Then Make the Voice — turn the idea into a spoken explanation. - 1.5 Turn the Voice into a Visual Plan — decide what someone should see as they listen. - 1.6 Let AI Build the Scene — build the pictures and review whether they help. - 1.7 Fix What You See, Then Export — make a specific correction and check the finished video. - 1.8 Make the Next Video with Your Own Idea — carry the useful tools and instructions into your own project. -

Everything in this course has been really good, and @Bas Rosario context engineering series is right up there with it! The quick card is practical. It gives you seven lines to write before you ask an AI for anything, a way to check what you're feeding it, and a way to test it. One line from it has stuck with me: lucky is context you never wrote down. So I went back through a weekend of my own prompts to see which lines I actually use. What I was doing before. I always said what I wanted. Most of the time I said why, and where the files were. Sometimes I said what was off limits. What good looks like, I gave as adjectives. I told it to make things "awesome" or "bulletproof," and the AI can't see an adjective. What bad looks like, I never gave up front. I gave it three times in one weekend, but only as corrections after a draft came back wrong: don't name where I work, don't introduce me to people who already know me, and don't make it sound like I walk into a client with a solution already picked. Bas bet that line seven is the one most people skip. He was right about me. What I did about it. I wrote one room for the prompt I use most. Those repeat corrections are now line seven, each with one line on why. Then I tested it the way the card says, in fresh windows. Without the room, the answer sounded good but filled the gaps with things that weren't true. With the room, it left blanks where only I knew the answer. The test also showed the room wasn't perfect. One of my rules was too strict and blocked a check I needed, so I fixed it and saved a second version. What I'm going to do next. Write line seven before the first draft, not after. Replace my adjectives with a real example or a check you can pass or fail. Build a room for the next prompt I use a lot, and keep adding the corrections to it so I stop repeating them. This is the kind of stuff I can really dig into. Thanks, @Bas Rosario