Human touch ui

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:

• Diagnostic rubric
• Contextual pattern catalog

Before implementing or approving changes, also read:

• Verification matrix

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:

1. Product specificity: can a user tell who the product is for and what it helps them do?
2. Content truth: are copy, data, screenshots, testimonials, and states real or honestly marked?
3. Hierarchy: is one primary task visually dominant, with supporting content subordinate?
4. Component purpose: does every card, tag, icon, divider, and control solve a real grouping or action problem?
5. Visual system: do type, color, spacing, radius, iconography, and imagery follow a product-specific system?
6. Interaction and states: are motion and feedback tied to actions, state changes, or narrative?
7. 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 trust
• P1: unclear primary task, weak hierarchy, missing states, or product mismatch
• P2: unsupported default-stack clusters that make the product interchangeable
• P3: 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:

1. Preserve and test the current behavior baseline.
2. Replace fabricated or generic content with supplied truth; otherwise use an explicit placeholder.
3. Clarify reading order, primary action, labels, and information grouping.
4. Remove containers and decoration that do not aid grouping, state, or comprehension.
5. Derive tokens from existing brand/context and reuse the existing component system where possible.
6. Correct icons, tags, cards, imagery, and motion using the pattern catalog.
7. Implement empty, loading, error, success, disabled, and long-content states that matter to the task.
8. 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.