A User Message Is Not Always a String

Text-file attachments worked. Image attachments crashed before the model ran.

The browser rendered an image preview and OIP delivered one image to the Host. Then the skills plugin called .startswith('/') on the newest user message and raised AttributeError: 'list' object has no attribute 'startswith'.

The assumption was easy to miss because ordinary user content is a string. A multimodal user message is an ordered list of content parts: one text part plus one or more image parts. The Agent already supported that representation, but an after_user_input plugin at the edge of the execution loop still assumed the old shape.

Returning early for every list would have stopped the crash. It would also have made /skill commands silently stop working whenever the user attached an image. Replacing the entire list with skill instructions would be worse: the command would run, but the attachment it was meant to inspect would disappear.

The skills plugin now locates the text part without flattening the message. A normal image prompt passes through untouched. A multimodal slash command replaces only its text part with the loaded instructions and arguments, preserving the remaining image parts and their order. Plain string behavior is unchanged.

The regression covers both sides of that boundary: a non-command image prompt must not load a skill or raise, and a slash command with an image must load the skill while keeping the exact image part. The real browser retest then confirmed the stronger result: OIP reported one image, the LLM completed, and the chat remained live.

The lesson applies to every message event handler. Plugins should reason about message semantics — text, images, files, tool calls — rather than treating the wire representation as permanently scalar.