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

Hey everyone, I’m building an ICM workspace for my recruitment work and I’ve been thinking about how to keep it structured without making it too rigid. I like the idea of numbered stages because they create a clear order and help Codex find the right instructions. But in practice, my work doesn’t always start at the beginning or follow the same path. For example, I might add a new company and vacancy, work through the vacancy preparation, and then assess a candidate’s CV. That feels like a nice, ordered process. But the next day I might get another CV for that same vacancy. Ideally, I’d want Codex to pick up the existing vacancy information and go straight to the new candidate’s assessment, without repeating all the earlier steps. Other times, I might get a CV before I have a vacancy, or I might just want to format a CV without going through the full recruitment process at all. I’d like the workspace to flag anything useful that’s missing, but also let me decide whether to do it or skip it and move on when it isn’t essential. I’m trying to understand how best to make those entry points and optional steps clear in the folder structure and instructions. Am I overthinking this? Has anyone else run into this when their work doesn’t always follow a clear, step-by-step process? How have you structured your ICM so it stays organised while still letting you jump in at different points and reuse work you’ve already done? Would love to hear how others have approached it!

I’m a Material Controller with an EPC company in the UAE, supporting projects across multiple countries. I’m responsible for the warehouse at our project site and our company’s fabrication yard. Alongside my daily work, I’m building a dashboard on top of our company’s legacy ERP system to make operational data easier to access and manage. In parallel, I’m developing an ERP V2 concept to modernize the system. I’m grateful to @Jake Van Clief for sharing the ICM methodology. It has helped shape how I think about structuring and building systems. I’m learning by solving real problems—combining my operations experience with my IT background to build practical tools. It’s still a work in progress, and I’m excited to keep moving forward.

Title: One Thing That Stood Out From Session 1 In Session 1, the moment that stuck with me was the plumber example on value-based pricing, around the 22-minute mark. The plumber shows up late at night, fixes the pipe in five minutes, and charges $500. You're not paying for the five minutes. You're paying for someone who can fix it in five. What caught my attention is that I'm working through this exact problem right now. I'm setting up AI folder systems for small trades businesses, and my instinct is to price by the hours the build takes me. That's backwards. The point in the session was that the savings compound. A system that keeps saving a client money every year is worth more than a one-off build they have to pay to redo after every update. This is how I will be pricing my next build. Instead of estimating hours, I'm starting with what the system saves the client each year and working back from there.

There's nothing quite like comp week. A brief drops, you've got seven days, and suddenly you're building something real with Claude instead of just reading about it. The deadline makes you finish. And when you post your repo, you're standing next to other people who just did the same thing, which is so much fun! Every entrant in the weekly comps gets a feedback file from @Jake Van Clief , @David Vogel, @Bas Rosario, @Don Roy and @Matthew Creamer: what worked, two fixes, and the one thing that would have moved you up. I've learned more from those files than from anything else I've done with AI. People who build this stuff for a living, reading your work line by line, every week... Amazing! Comp #15 had 7 entries. There are 54,000 of us... so most people are watching, not playing. If that's you, here's how I'd start. You won't be doing it alone: Claude is your partner the whole way through. This is a framework for how I approach these competitions... 1. Read the brief twice, then copy out the judging lines. Those checkmarks are the whole test. Everything you build should answer one of them. 2. Brainstorm with Claude, starting from what you know. Paste in the brief, tell it about your own work, and ask for ideas. A workflow from your own job beats a clever idea you'd have to learn first. Don't worry if none of Claude's ideas are right. Once you start talking ideas through, your own start showing up... 3. Keep going until you land on the idea, then turn it into a PRD. A PRD (product requirements document) is a short plan of what you're building and why. The lessons from @Bas Rosario and @Don Roy give a great shape for it. Say what it's FOR, show what good looks like (an example or two), show what bad looks like, list what it can and can't use, and say how it checks its own work: done, try again, or stop and ask a person. Claude can write it with you. 4. Write one sentence that says what done looks like before you build anything. Claude can help you sharpen it. 5. Build it as an ICM folder, then trace the path. ICM is Jake's method: the folder structure is the plan, with one file per job, so the AI reads only what it needs at each step. The ICM architect skill helps Claude lay out the folders. Then ask Claude to trace a task through it: which files it would read, in what order, and why. If the route looks wrong, the structure is wrong, and it's much cheaper to fix now than after you build. 6. Test it the way the judges will. They clone your repo fresh and try to break it. So clone it into an empty folder, follow your own README like a stranger, and run every claim you make. Ask Claude to try to break it too. 7. Say where it falls short. The judges reward that. 8. Post it with the repo link on the first line, then read your feedback file. That's where the learning happens.