randroid-clean-slop ยท diff
git:20260830.a009b78 to git:20260912.65128a6
12 added, 6 removed. Audit A to A.
---
name: randroid-clean-slop
- description: Diagnose and remove generic AI-generated visual and copy patterns from an existing interface through screenshot-led iteration. Use when the user asks to de-slop, make a UI feel less AI-generated, clean up generic vibe-coded design, or perform a final visual-polish pass. Do not use as a substitute for implementing missing product functionality.
+ description: Diagnose generic visual and copy patterns in existing interfaces, games, and 3D assets through actual screenshots or renders. Use when asked to de-slop, avoid cookie-cutter design, or refine an existing game's visual identity. Does not implement missing gameplay or replace a modeling workflow.
---
# Clean Slop
- Improve an existing interface by finding concrete generic-design tells, fixing the affected elements, and visually checking the result.
+ Improve an existing design by finding concrete generic-design tells, fixing their causes, and visually checking the result. Preserve the intended genre, style, brand, and useful conventions.
+ ## Select the review surface
+
+ - For interfaces and copy, read [references/rules.md](references/rules.md). Treat its examples as diagnostic prompts, not automatic bans on colors, fonts, or components.
+ - For games, worlds, and 3D assets, read [references/game-assets.md](references/game-assets.md). Use actual game captures or model renders; website styling rules do not judge a car or a landscape. Use the relevant engine or modeling skill for implementation.
+ - If the missing piece is player agency or a playable loop, use `randroid-game-feel` when available. Decorative polish cannot supply that functionality.
+
## Workflow
- 1. Read [references/rules.md](references/rules.md) before making design changes.
- 2. Inspect the running interface or supplied screenshot first. If neither exists, inspect the relevant frontend code and state that visual confirmation remains pending.
+ 1. Read the reference for the selected review surface before making design changes.
+ 2. Inspect the running product, supplied screenshot, or actual render first. If none exists, inspect the relevant source and state that visual confirmation remains pending.
3. Identify specific visible problems rather than applying a wholesale style preset.
4. Fix one coherent group of issues at a time while preserving the product's established brand, information hierarchy, and functional behavior.
- 5. Re-run the interface at relevant desktop and narrow widths, capture a fresh screenshot, and repeat until the identified tells are gone or a product decision is required.
- 6. Check interaction states, text wrapping, contrast, layout shift, reduced motion where relevant, and browser-console errors.
+ 5. Capture the affected views at matched settings after the change. For interfaces include relevant desktop and narrow widths; for assets include whole-object and gameplay views. If a major defect survives two comparable attempts, reassess the underlying structure before a third local polish pass.
+ 6. Verify the affected behavior as well as appearance. Interface checks include interaction states, wrapping, contrast, layout shift and relevant accessibility; game-asset checks include movement, contact, readability and LOD transitions where affected.
7. Do not replace real content, photography, icons, fonts, or brand assets without user authorization when that choice materially changes the product.
8. Offer to encode durable, project-specific prevention rules only after the visual result is accepted.
Finish with the exact elements changed, visual verification performed, and any remaining design decisions.