Builder Methods library
Friction-driven iterations
We run the modular skill on two new prospects and let it hit the limits of the library on camera, patching each run by hand and noticing what keeps coming up.
New client types, real friction. We drop in a first new prospect and run the modular skill. It assembles what it can, then stops and reports the sections it doesn't have modules for, exactly as instructed. We patch by hand. Then a second prospect, and the same thing happens again with a different set of gaps. This lesson is about letting the annoyance show. The day-one library was a guess, and two runs of real work have already found the places it was wrong. Nothing gets fixed yet; that's the next lesson.
What's covered:
- Running the modular skill against a client the library wasn't designed for
- What the closed-library rule looks like in practice: gaps named, nothing invented
- Patching a run ad hoc, and why that's fine the first time
- Recognizing the pattern when the same patches show up twice
- Reading friction as the spec for the next improvement