adaptive-fwm-ux-uiSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: adaptive-fwm-ux-ui
description: "Adaptive, evidence-based UX/UI audit and safe improvement for any website or app. Classifies each surface first (user goal, business goal, audience, environment, risk, device, language), then applies only the matching rule modules: ecommerce, fashion, lead generation, service business, B2B marketing, content sites, SaaS apps, dashboards, monitoring, admin tools, AI products, booking, marketplaces and high-stakes flows, plus forms, navigation, tables, search and filters, charts, loading/empty/error states, mobile, RTL/Arabic, type scale, pricing and selling. Preserves existing functionality and brand identity. Use whenever the user asks to audit, review, critique, check, improve, fix or polish the UX, UI, usability, accessibility (WCAG 2.2 AA), responsiveness, conversion flow, checkout, forms, navigation, tables or dashboards of a page, screen, component, flow or whole product, or to plan UX before a build, even if they only say 'check my website', 'make this easier to use' or 'why does this page feel off'."
metadata:
  version: "1.8.1"
---

# Adaptive UX/UI audit and improvement

The best interface for a fashion store is a bad interface for an incident dashboard. So this skill does not apply one checklist to everything. It first works out what kind of product surface it is looking at, who uses it and what they are trying to get done, then applies only the rules that fit that surface. It does this without changing how the product works or what the brand looks like, unless the user explicitly asks for that.

```
DISCOVER → CLASSIFY → LOAD RULES → AUDIT → PRIORITIZE → REPORT → (IMPLEMENT → VERIFY)
```

## Ground rules

These hold in every mode. Each one exists because breaking it is how a "UX improvement" ends up costing the user more than it gave them.

1. **Classify before judging.** A recommendation is only right relative to a surface's users and task. State the classification before the first finding.
2. **Read-only unless asked to change things.** "Audit", "review", "check" and "what's wrong with" mean report only. Edit files only when the user asks to fix, improve, implement or apply. When it is unclear, audit and offer the fixes.
3. **Protect functionality.** Unless the user explicitly authorizes functional work, UI work must not alter APIs, schemas, data, routes, auth, permissions, pricing, tax, inventory, checkout, payment, booking, monitoring or alert logic, AI prompts or model behavior, analytics contracts, background jobs or integrations. A recommendation that needs any of that is reported under the heading `FUNCTIONAL UX RECOMMENDATIONS — NOT IMPLEMENTED` and left alone. The full boundary is in [references/implementation-safety.md](references/implementation-safety.md).
4. **Protect the brand.** The existing logo, palette, type, spacing, radius, shadows, motion, imagery, components and tokens are the brief, not a draft. Fix how a brand element is *used* before proposing to change the element. Never restyle toward a generic look.
5. **Nothing fake.** Never add a control, metric, chart, search, filter, export, progress value, review, badge or AI feature that is not backed by real functionality or data. Recommend it instead. When the user directly asks for a new feature ("add a search bar"), that is a request for functional work: confirm the scope, then build it for real or not at all.
6. **No deception.** Never recommend or build fake urgency or scarcity, fake reviews, confirmshaming, hidden costs, pre-ticked consent or obstructed cancellation, even where it would lift a metric. Presentation techniques from sales psychology (framing, anchoring, a highlighted middle plan, "free", loss wording) may only arrange what the owner really offers: never invent or alter a price, plan, tier, feature, discount, former price, free item, trial, guarantee, deadline or stock level to make a page sell better. Rules: [references/patterns/pricing-and-persuasion.md](references/patterns/pricing-and-persuasion.md).
7. **Evidence over taste.** A psychology principle quoted in a brief, article or video is a claim to check, not a rule: confirm the study, whether it has held up, and whether the example is honest ([references/patterns/ux-psychology.md](references/patterns/ux-psychology.md)). Tie every finding to a rule and say what kind of rule it is (see [Evidence classes](#evidence-classes)). Do not invent statistics or promise conversion gains. A stylistic preference is not a finding.
8. **Keep secrets out.** Do not print, copy or quote keys, tokens, credentials or personal data found while inspecting a project; redact them. Do not edit environment or secret files. Do not send project content to external services unless the user asks.

## Step 1 — Pick the mode

Infer the mode from the request. Natural language is enough; there is no command syntax.

| Mode | Typical request | Edits files? | What to produce |
|---|---|---|---|
| **Audit only** (default) | "audit", "review", "check my site", "what's wrong with this" | No | Audit report |
| **Audit + safe fix** | "fix", "improve", "implement", "apply the changes" | Yes, UI-safe changes only | Audit report, then implementation report |
| **Scoped review** | Names one screen, component or flow | Only if asked | Short audit of that scope |
| **Design plan** | "plan the UX", "how should we structure this" before a build | No | Classification, workflows, structure and rules to follow |
| **Conversion pass** | "make this page convert", "make it sell", "why does nobody sign up" | Only if asked to fix | Follow [references/conversion-pass.md](references/conversion-pass.md): diagnosis, facts ledger, owner questions, rebuilt page, content brief. Its question limit replaces the usual one |
| **Focus pass** | "accessibility pass", "mobile pass", "check the checkout", "check the Arabic layout" | Only if asked | Audit weighted to that focus |

A request that lists focus areas covering most of a page (sizes, readability, mobile, 

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (2)

- Never display raw server errors, stack traces, tokens or internal identifiers to end users; never copy them into the audit report either.

Gates applied: no_behavioural_pass, no_license.