| name | human-touch-ui |
| description | Evidence-driven UI audit and repair skill that removes generic AI-like defaults without turning design into another blacklist. Use only when the user explicitly invokes human-touch-ui or asks to remove the AI-generated, vibe-coded, generic, cookie-cutter, or template look from a visible web/product UI. Supports audit-only, behavior-preserving repair, and new UI builds. Do not use to determine whether an artifact was actually AI-generated, to humanize prose, or for backend-only work.
|
| license | MIT |
| compatibility | Agent Skills compatible. Intended for Codex and Claude Code with file inspection; browser or screenshot tooling is recommended for visual verification. |
| metadata | {"author":"LWH-9393","version":"1.0.0","research-date":"2026-07-20"} |
Human Touch UI
Activation boundary
Use this skill only when the user names it or clearly asks to remove a generic, AI-generated, vibe-coded, cookie-cutter, or template look from a visible UI.
Do not activate it for ordinary frontend implementation, general code cleanup, prose humanization, or AI-image/provenance detection. Never claim that a page was generated by AI from visual cues. This skill diagnoses design decisions, not authorship.
Outcome
Make the UI feel specific to its product, audience, content, and brand while preserving verified behavior. Distinctiveness comes from traceable decisions, not mandatory novelty.
Before judging a UI, read:
Before implementing or approving changes, also read:
Read Research basis only when the user asks for rationale, sources, or methodology.
Choose the mode
| User intent | Mode | Write permission |
|---|
| Review, critique, diagnose, score, or report | audit | Do not edit files |
| Fix, redesign, humanize, remove AI look | repair | Edit only the agreed visible surface |
| Create or build while avoiding generic output | build | Implement the requested surface |
If intent is mixed, default to audit unless the user clearly asks for changes. A request to diagnose is not permission to implement.
Procedure
1. Inspect the acceptance surface
Inspect the actual files, rendered UI, screenshots, design system, and available test commands before making findings. Treat supplied material as primary evidence.
For an existing product, record:
- target pages or components
- framework and styling approach
- existing tokens, component library, and brand assets
- routes, forms, analytics hooks, IDs, and behaviors that must remain stable
- current responsive and accessibility behavior
- current git status so unrelated user changes stay out of scope
If the target cannot be opened or only part of it is visible, say exactly what was inspected. Do not infer the rest from filenames or descriptions.
2. State the design read
Write one compact line before coding:
Design read: <surface> for <primary user>, optimized for <primary task>,
trusting <evidence>, with <brand/platform constraints>.
Infer non-critical gaps and state the assumption. Ask one question only when different answers would materially change the product direction.
3. Ground decisions in references
When web or design-reference tools are available, collect 3 to 5 references that match the same surface, platform, audience, or trust requirement. For every reference, record:
- source and exact URL or artifact
- the specific pattern being borrowed
- why it fits this product
- what must not be copied
Prefer the user's design system and authentic brand assets over trend galleries. Do not copy another product's identity or reproduce a layout pixel for pixel. If current references cannot be accessed, disclose that limitation and work from inspected local evidence.
4. Audit decisions, not vibes
Run the rubric across these lenses:
- Product specificity: can a user tell who the product is for and what it helps them do?
- Content truth: are copy, data, screenshots, testimonials, and states real or honestly marked?
- Hierarchy: is one primary task visually dominant, with supporting content subordinate?
- Component purpose: does every card, tag, icon, divider, and control solve a real grouping or action problem?
- Visual system: do type, color, spacing, radius, iconography, and imagery follow a product-specific system?
- Interaction and states: are motion and feedback tied to actions, state changes, or narrative?
- Implementation quality: do responsiveness, semantics, keyboard behavior, contrast, and edge cases hold?
A familiar pattern is not a finding by itself. Record a finding only when there is an observed cue plus a context or purpose mismatch and a concrete user or product consequence. Direct functional, accessibility, or truth failures are findings without needing a visual cluster.
5. Make a prioritized change map
Use the rubric priorities, not an overall “AI score”:
P0: broken behavior, accessibility, data truth, security, or user trustP1: unclear primary task, weak hierarchy, missing states, or product mismatchP2: unsupported default-stack clusters that make the product interchangeableP3: polish that improves coherence without changing the product
For each proposed change, state:
Observed evidence -> why it fails here -> smallest correction -> verification
Do not propose wholesale visual replacement when a smaller change resolves the evidence.
6. Repair in risk order
For repair and build, work in this order:
- Preserve and test the current behavior baseline.
- Replace fabricated or generic content with supplied truth; otherwise use an explicit placeholder.
- Clarify reading order, primary action, labels, and information grouping.
- Remove containers and decoration that do not aid grouping, state, or comprehension.
- Derive tokens from existing brand/context and reuse the existing component system where possible.
- Correct icons, tags, cards, imagery, and motion using the pattern catalog.
- Implement empty, loading, error, success, disabled, and long-content states that matter to the task.
- Verify after each coherent patch; keep unrelated code untouched.
Prefer removing an unsupported element over replacing it with a more fashionable one. Do not add a dependency when the current stack can solve the problem safely.
7. Verify at the judged surface
Run the repository's relevant build, type, lint, and test commands. Render the changed UI at representative viewports and inspect the state matrix in the verification reference.
Separate evidence levels in the final report:
- source/code inspection
- automated checks
- rendered screenshot inspection
- interactive runtime observation
Do not call a change visually verified if no rendered UI was observed. Do not call it runtime-verified if controls were not exercised.
Output contract
Audit
## Design read
## Inspected surface and evidence limits
## Findings
### P0/P1/P2/P3 - finding title
- Observed
- Why it fails here
- Smallest correction
- Verification
## Patterns intentionally kept
## Recommended change order
Repair or build
## Design read
## Changed
## Preserved
## Verification
## Remaining evidence gaps or trade-offs
Use only sections supported by evidence. If the inspected UI does not have a meaningful generic-default problem, say so and avoid cosmetic churn.
Gotchas
- Do not replace every emoji blindly. Preserve expressive content emoji; replace emoji used as controls or arbitrary feature icons with a coherent accessible icon, or remove it.
- Do not ban purple, Inter, cards, pills, gradients, or symmetry. Keep them when brand, platform, content, or semantics justify them.
- Do not “humanize” by adding random asymmetry, custom cursors, parallax, grain, gradients, or mandatory animation.
- Do not make every page bold, experimental, premium, or award-seeking. A public service and a music portfolio need different restraint.
- Do not trade familiar navigation or control semantics for novelty.
- Do not invent customer logos, testimonials, metrics, charts, screenshots, or precision.
- Do not silently rewrite business copy, routes, form fields, analytics events, legal text, or product logic.
- Do not hide uncertainty behind a numeric AI-likeness score.
