# Messages UI avoidance profile

---
name: messages-ui-unslop
description: Avoid generic AI presentation when maintaining this English/Arabic messaging interface.
---

# Messages UI avoidance profile

Manual profile grounded in the supplied messenger reference and the existing app. The automated unslop sampling run could not proceed because Claude Code is signed out.

- Do not turn a chat into a landing page. Avoid centered capability headlines, gradient orbs, sparkle marks, starter-card grids, and appended “next steps” cards.
- Do not create a separate assistant contact section or repeat AI/demo badges throughout the chat. The automated contact has an ordinary name and avatar treatment. Disclose its automated identity and actual provider/demo state in Settings and conversation information.
- Do not pretend the automated contact is human or that scripted replies are provider-generated. Do not silently replace provider errors with demo output.
- Do not use decorative blue highlights throughout an interface whose reference is monochrome. Read/unread, selection, focus, and voting must remain distinguishable through shape, text, contrast, and accessible state.
- Do not fill conversations with implementation notes or long identical placeholder paragraphs. Use varied, short, everyday exchanges.
- Do not invent voice or video calling functionality just to reproduce a reference icon. Add only controls with meaningful implemented behavior.
- Do not crowd the composer with explanatory slogans. Keep attachment, emoji, poll, send, and stop actions accessible; keep the offline queue status when needed.
- Do not bury polls behind a separate assistant workflow. They belong in the same composer menu as images, with actual option selection, change, and removal behavior.
- Product carousels and selection/review cards are allowed when they serve an explicit customer choice; do not confuse them with decorative capability cards. Keep size/color, delivery radios, extras checkboxes and polls independent.
- Do not prescribe a generic response when a letter needs context. Ask a relevant question about the recipient, purpose, or tone; avoid forced capability lists.
- Do not sacrifice Arabic RTL or native mobile input for visual similarity. Keep 16px composer text, logical layout properties, visible-viewport height/offset, safe-area padding, composition-safe Enter handling, and reduced-motion support.

Check the real app after a change. Review the contact list and a populated conversation at mobile and desktop sizes. Verify Arabic, polling, attachments, offline queues, stream cancellation, and error retry. Record any demo-only or untested behavior clearly in documentation.

Situational choices: keep recommendation and selection surfaces outside speech bubbles. Make product cards tappable and include a compact, labeled action inside each card. Hide comparison checkboxes until comparison is requested. Use a color ball and round swatches; tapping a swatch commits the color directly, while the card action applies the displayed color and variant and disables once applied. Show only the next delivery/extras/save action. Keep navigation compact.

Split product details, storage/size, and color into small independently addressable messages. Keep their option group shared; the agent can send multiple short text messages in the same turn.

Current option style: no panel backgrounds around product details, numbers, colors, or filters; regular weight labels. Remove the large orb. Use small swatches with check overlays and neutral text actions. Split price, color, size, type, and collections into independent messages. Multi-product selection uses checks over images and its own selected list.