As IOU Financial’s sole product designer, I built the customer-facing system behind our loan application. I created the screens and states in Figma, then built the coded components in Lookbook, our component preview library. Some product decisions still depended on what I knew from designing the product. To make those decisions usable beyond me, I brought the tokens, components, and screen recipes into a markdown pack. A companion skill told the agent to read it first, build from the system, and ask when a request was not covered.

I was testing whether the system was legible or just documented. Documented means it exists on paper. Legible means someone, or something, else can build from it correctly and knows to stop when they can't. The test was how I found the difference.

I asked for an income-verification step, which did not exist in the pack. The agent generated fields, dollar amounts, and the line “By continuing you agree to IOU Direct's Terms of Service and Privacy Policy.” It disclosed its assumptions only after building. This was an internal test, not an applicant-facing screen, but the risk was concrete: the output looked plausible while making product and authorization decisions nobody had approved.

I locked the scoring assertions before reviewing output and ran eight tasks, each in a fresh session. I scored the rendered screens and generated code rather than the agent’s account of its work. Seven tasks tested documented screens and rules; the eighth tested whether it would stop at a missing product step.

All 12 original design-decision rules held on their scored exposures. The review also found four documentation gaps: desktop layout dimensions, a radio indicator color, an error-helper token, and rejection-screen positioning. The failed assertion was different. The agent had followed the visual system while inventing what the product should contain.

I first strengthened the skill’s instruction to ask before inventing. Then I ran the income-verification request again. The three outputs below show why that wording change failed and what finally closed the gap.

An invalid business tax ID still needs to look invalid when someone reaches the field with a keyboard. I defined the red error border and separate blue focus ring in Figma, implemented the state in Lookbook, and documented a rule with a clear fail condition. The generated screen preserved both signals. The test also revealed that the error-helper-text color had no named token; I added one to the pack and verified its use in the rerun.