---
name: product-ui-ux-design
description: "页面怎么设计 / 交互怎么做 / 设计走查 / 设计验收 / 页面别扭 / 空状态 / 错误提示 / UI polish → own product UI/UX decisions: layout, interaction, visual craft, states, accessibility, design-system consistency, and launch acceptance."
---

# Product UI/UX Design Skill

Use this ccl-wide product UI/UX skill when designing, implementing, launching, iterating, or reviewing product surfaces that need a consistent app/web design system, polished interaction, production-ready states, and reusable Figma/code-derived UI patterns. The target product may be community, finance, AI, operational, mobile, web, or another product category; source domains do not define the product model.

The purpose is to provide reusable design intelligence from available Figma files, validated frontend/client implementation, and stable external quality benchmarks: visual system, layout rhythm, component semantics, interaction flows, behavioral logic, aesthetic logic, micro-feedback, empty/error/loading states, accessibility, performance, launch acceptance, iteration signals, AI assistant patterns, trust-sensitive data patterns, and source-selection guardrails. Source file names are provenance labels only, not the product boundary.

This skill can be used without access to the original Figma files or source repositories. The distilled rules in this skill and the reference files are the usable knowledge. Internal Figma URLs, file keys, and local code paths are provenance only; lack of access to them should not block normal design, implementation, review, or launch-check work.

## Source Discipline

Before using a Figma file as design evidence, classify it:

- **Current system sources**: published design system files and current product UI files.
- **Candidate formal sources**: files named with a "supplement" or "exploration" marker in the team's working language; these may be official and must be inspected before using.
- **Historical/reference only**: files marked with a team-specific deprecation prefix, a Figma-generated `(Copy)` suffix, an explicit old/deprecated/archive label, slide/report files, broad team libraries, and files clearly superseded by newer current UI files. The team's active deprecation marker list lives in the private provenance archive, not in this skill.
- **Partial/incomplete inside a current file**: pages or components marked as `todo` in the source; use only as weak guidance and do not make them hard rules.

Never merge historical/reference-only files into executable design rules. Use them only as provenance or weak confirmation of a pattern already present in stronger current sources.

Fully extract all formal Figma sources that are not excluded by source rules. When files, pages, or components conflict or duplicate each other, make an explicit judgment:

- **Keep** the clearer or more current reusable pattern.
- **Merge** compatible variants into a generalized rule.
- **Discard** stale, overly domain-specific, duplicated, or lower-quality details.

The final skill must stay generic. Preserve source names only as provenance in reference files; do not encode a specific business domain as the skill's product model.

## Required Workflow

Before editing design artifacts, UI copy, visual rules, design-system guidance, or code-facing acceptance criteria, complete enough analysis and planning for the design change to be reviewable. Scale the plan to risk: a simple low-risk copy or spacing check can use a short inline plan; new or reshaped screens, multi-platform surfaces, user-visible behavior, accessibility-sensitive flows, high-risk actions, branch/MR work, unclear-risk, or implementation-driving design needs explicit design checkpoint, state matrix, visual/interaction acceptance criteria, screenshot or device evidence plan, and handoff to the owning implementation/test skills before edits or approval.

1. Resolve the target product context first: product category, user type, risk level, platform, surface type, density, and delivery stage. Apply community, finance/data, operational, AI, mobile, or web references only when the target surface matches. Translate away source-domain terms from source artifacts.
2. Read `references/source-map.md` when source provenance, Figma file status, code-evidence boundaries, or exclusion rules affect the task.
3. Use `references/design-execution-checklist.md` as the routing entrypoint. It tells you which focused reference files to load for the current surface or task; do not load the full reference corpus by default.
4. If a new Figma file is provided, classify it first and update source-map notes before extracting rules from it. When extracting from Figma alongside an implementation codebase (web or app), use `../skill-extraction-workflow/references/two-source-extraction-pattern.md` for the joint extraction methodology — figma file classification (A1/A2/B), deprecation-marker detection, design-token cross-validation, and routing splits.
5. When re-extracting or updating this skill, run a coverage checkpoint before editing: sources inspected, source-quality gaps, contradictions, thin evidence, keep/merge/discard decisions, and the target reference that should own each rule.

For implementation work, apply this skill to any visible UI change: layout, copy, state, interaction, navigation, user-facing error/empty/loading feedback, and any user-facing operation entry. Applying this skill means producing and checking a concrete design checkpoint, not merely opening the skill. The checkpoint should name the surface type, density mode, primary workflow, human intent/friction, layout structure, required states, trust/safety boundaries, component semantics, behavioral/aesthetic acceptance, and visual acceptance criteria. If the implementation uses a component library such as Ant Design, the library is only the rendering vocabulary; this skill still owns information architecture, hierarchy, state completeness, interaction quality, behavioral logic, aesthetic logic, and visual polish.

Before the first implementation edit for a runtime visible UI/UX slice, record an **implementation-owner checkpoint**. A runtime visible UI/UX slice is any change from the visible-UI-change list above that ships in a runtime surface, including shared theme/token edits, client-rendered user-facing strings changed in or alongside the client surface that renders them, layout, copy, state, interaction, navigation, or user-facing error/empty/loading feedback. Shared i18n/localization/content/config packages whose values a client surface renders are in scope even when no client-surface file is edited. Only strings or config values that no client surface renders to users route to the owning backend/product/test skill with API/log/output evidence, and that backend-only classification must record the consumer check that established it (client-repo/locale search or contract doc) — if the client repos/contracts cannot be searched, classify as `unknown-consumers` instead of backend-only; backend-delivered copy that a client surface renders user-facing keeps this checkpoint, using the copy-only path where it qualifies. This is required even when the request is narrow enough to route directly to this skill and does not enter `product-rd-workflow`, and even when the ask is framed as pure code mechanics on a decided design.

- Record location: plan/checklist, MR notes, or evidence file; branch/MR-bound work records the pre-edit checkpoint in one of those persistent artifacts, and only a single-turn local edit may use the visible progress update. The record must cite `checkpoint rules read: product-ui-ux-design/SKILL.md#implementation-owner checkpoint`; a checkpoint record without that citation is not valid. If code changes remain at final response, push, or MR time, repeat the full checkpoint fields in that final/MR/evidence record; any change that is pushed or remains in the repo needs its final checkpoint record in a persistent artifact (plan, evidence file, or MR notes), and a chat-only final record is acceptable only for a throwaway local edit — one reverted or discarded before the final response; if the diff remains anywhere, the persistent-artifact rule applies.
- Design owner: `product-ui-ux-design`.
- Stack implementation owner: `app-cross-platform-dev` for Flutter, React Native, native Android, or native iOS app surfaces; `web-react-dev` for React web; `miniapp-product-dev` for mini-programs; `terminal-cli-dev` for terminal/TUI; `project client-code conventions` for desktop/native or any other runtime surface with no installed owner skill, with the surface type named; or `no-installed-owner` with surface type when no project convention exists. The installed owner's technology wins inside containers — React in Electron or a WebView/H5 shell is `web-react-dev`, a React Native shell is `app-cross-platform-dev`, an embedded terminal UI is `terminal-cli-dev` — so before recording `project client-code conventions` or `no-installed-owner`, name the runtime/framework, record why no installed stack owner applies, and record where project conventions were looked for — at minimum the repo's README/CONTRIBUTING, docs/ style or client-code guides, and agent-contract files (AGENTS.md/CLAUDE.md); if that lookup cannot be completed, record the evidence status as unavailable rather than `no-installed-owner`. A `no-installed-owner` entry without that lookup record is invalid. For shared theme/token edits or any other slice that can affect more than one stack, first inventory the consuming stacks/build targets from the repo's own build, package, and locale/config sources (a bounded repo search, not guesswork), then record one entry per discovered stack — affected, `unchanged`, or `out-of-scope` — with the basis; consumers that cannot be enumerated from the repo are recorded as `unknown-consumers`, which blocks complete claims; in-thread scope acceptance closes the unknown surface only as a scoped handoff/gap, never as complete. An `out-of-scope` entry requires evidence the stack cannot ship the value, or the same in-thread scope acceptance recorded as a handoff/gap. An entry list limited to the stacks the author happened to name is not an inventory.
- Test owner: `testing-strategy` for assertion/rendered-evidence selection. Load it and record the assertion layer and rendered-evidence choice it produced, not only its name — the same bar as stack-owner entry rules.
- Entry-rule evidence: a short quote, or the exact section/rule identifier plus the decision it produced — never only a file path, runtime name, or a vague anchor like "the visible UI rule"; the acceptable anchors are the stack owner's visible-UI, page-slice, design-checkpoint, or rendered-evidence rules, not arbitrary text from the skill. For project-convention owners, quote the specific convention line/rule applied; for `no-installed-owner`, record `no owner rule available`.
- Rendered/device evidence status: `captured/verified` with the inspected artifact pointer — an artifact path, screenshot name, recording, or the output of a rendered-surface capture/inspection command recorded together with the actual command and target surface, where the output is itself inspectable surface evidence (screenshot, recording, trace, DOM or cell-grid dump) and not a pass/fail summary line; build, lint, type-check, or unit-test output is not rendered evidence, and a hand-authored or echoed transcript is fabricated evidence, the same defect class as fabricated verification output. The pointer must resolve at review time in a review-accessible location per the page-slice gate's evidence-persistence rule — repo-relative paths, MR attachments, or named artifact IDs, never local absolute private paths, with command output persisted in the evidence/MR record, not only in chat — and must be captured from the change as it will land; re-capture after further material UI edits. `planned` with the capture command or step and a requirement to resolve before final/MR checkpoint; `unavailable-with-owner` or `unavailable-no-owner` only with the attempted capture command(s), the observed failure, the residual risk, and the next unblock action recorded — an unavailable status without an attempt record is invalid. A bare `captured/verified` without an artifact/output pointer is treated as `planned`. Evidence artifacts follow the page-slice gate's sanitization rule: sanitized/test accounts, with tokens, PII, credentials, and private paths redacted. Any status other than `captured/verified` blocks completion claims: report `pre-runtime-test ready`, `blocked`, or an explicit evidence gap with owner and next command/unblock action, not done. `unavailable-with-owner` or `unavailable-no-owner` closes only as a handoff/gap when the user is told the risk and explicitly accepts proceeding without rendered evidence for this specific change in the current thread. Blanket autonomy or prior "continue" authorization is not acceptance.
- Remediation: if a missing checkpoint is discovered after the first edit by anyone, including self-review, record the defect, redo the checkpoint, and audit the already-made diff against the redone checkpoint's design/stack/test rules before any further edits, final response, commit, push, or MR-ready claim — a retrofitted checkpoint that blesses the existing diff without that audit is itself a process defect. For installed stack owners, load the stack owner and re-run its entry rules; for project-convention or `no-installed-owner` surfaces, record the convention or `no owner rule available`. Merely naming a stack owner without applying its entry rules, except for the copy-only `not-triggered` path below, is a process defect.

For runtime copy-only edits that do not alter layout, state, interaction, navigation, visual hierarchy, component choice, or behavior, use a lightweight checkpoint: design owner, stack owner, test owner, `entry-rule evidence: not-triggered (copy-only, existing component/viewport unchanged)`, copy-only classification evidence (`same component`, no conditional logic touched, and a measured basis: new text no longer than the old in every shipped locale — by rendered extent, not byte/character count, for width-constrained components — or a named length/viewport check; an unmeasured "no overflow risk" assertion does not qualify), and rendered/device evidence status. Copy whose meaning carries trust, safety, or risk weight — error, auth, payment/money, destructive-action, permission, legal/compliance, or AI-disclosure copy — does not qualify for the lightweight path: run the full checkpoint and route risk grading to `feature-risk-router`. User-visible string changes still need evidence status; the lightweight path only removes the stack-owner entry-rule quote. If a copy-only classification is later found wrong, treat it as the same process defect as a missed checkpoint and rerun the full owner checkpoint. If rendered evidence is not captured for a copy-only edit, it may close as `pre-runtime-test ready` with the gap stated, or as a user-accepted handoff/gap under the same specific in-thread acceptance rule above; it is not complete/done unless captured/verified.

During a systemic redesign or multi-screen restyle continuation, each next screen is a full design slice, not a cosmetic re-skin: re-derive that screen's information architecture by grouping content and actions by user intent and consequence (e.g. separating routine context/data areas from security, recovery, and destructive/danger areas) instead of repainting the existing layout, and run the same checkpoint depth as the first screen. Preserve the screen's behavior contracts — navigation targets, API calls, auth/session cleanup, destructive-action semantics, route return values, and existing write flows — unless the slice records the behavior change with its owning product/implementation/test/risk route and acceptance evidence; a bare "this slice owns it" declaration, or an IA regrouping that silently alters behavior, is an implementation defect, not a design refinement. (Shared-token or shared-component re-theming is the exception that cuts across screens as one sweep; IA and behavior still follow per-screen slices.)

**Rejected-surface rule:** When a user or named independent design-owner verdict (per the page-slice gate's design-verdict item) on a page-slice-gate-triggered screen, surface, or slice's rendered evidence is `rejected` — any slice the trigger list below catches, not only a full-screen redesign — for example blank-feeling first viewport, stitched-together cards, weak hierarchy, generic form-fill layout, or "usable but not actually redesigned" output — treat the current implementation as rejected evidence, not as a shippable baseline to polish. Only copy, spacing, or token-only fixes that change neither layout structure, content grouping, visual system, component semantics, navigation, data semantics, nor behavior count as in-target polish, and once a surface is `design-rejected` even those proceed only as part of the revised-target re-render/re-verdict loop — they never clear `design-rejected` on their own; anything beyond that re-enters the difference-class rule and page-slice gate. A rejected surface stops incremental patching: record the rejection reason in the page-slice gate's working artifact, preserve behavior contracts, preserve the rejected render as immutable negative evidence (do not overwrite it or retrofit the RED baseline to match a patched build), classify difference-points through the redesign difference rule below, and re-run the page-slice gate from a revised design target — not by patching the rejected build — producing a fresh RED baseline and rendered evidence. The slice stays `design-rejected` — blocking complete, MR-ready, and any normal or draft MR the same as a blocking runtime gate, and barring its screenshot from use as acceptance evidence — until the verdict on the re-rendered surface against the revised target is `accepted`. If the same surface receives a second `rejected` verdict (two redesign cycles), stop and escalate to the user or design owner for direction before another implementation attempt, rather than thrashing.

In a redesign the existing implementation is the **current state, not the spec**: a difference from the source is not by itself a defect, and reflexively reverting a design change to match the source is a recurring failure that degrades the redesign (it also misclassifies a deliberate improvement as a bug). Before acting on any source-vs-design difference, classify each independent difference-point into one of three classes, then handle per class:
- **Real defect** (always fix): a designer/review note rendered inside the product surface itself, an encoding/render artifact (garbled text, overflow), a mock that contradicts its own caption/label, a control whose drawn semantics are reversed, fabricated "existing" functionality, or copy that misstates real system behavior.
- **Design freedom** (the purpose of a redesign; no source backing required): visual language, layout/IA regrouping, component-signature upgrades, avatar/empty-state/placeholder styling. Improve freely; never revert merely because "the source lacks it."
- **Behavior/feature change** (allowed, but must be declared): new controls/features, changed navigation targets, rewritten flows, removed redundant entries. Record it as a behavior-contract diff entry (the page-slice ledger) with owner/approval per the page-slice behavior-contract rule — do not introduce a second parallel ledger. Drawing it silently is the defect; wanting it is not.

Cross-class tie-break: split a change into independent difference-points; when one point spans classes, take the strictest (**behavior-change > defect-fix > design-freedom**) — any visual change that also alters behavior, navigation target, or data semantics goes through declaration, not a "mostly visual" exemption. Source fidelity (verbatim state names, formats, labels) is required only to avoid *misstating current behavior*, and is waived for a change once it is recorded as a behavior-contract diff (then shown per the new design, with source as reference only).

Verification corollary: source-reading review (grep, an LLM reading the markup/source, a code reviewer) is structurally blind to render-layer defects (encoding, overflow, visual) and to the "is this even real UI" judgment, so it cannot substitute for rendered evidence; and a per-screen capture taken earlier can be silently masked by non-deterministic rendering (e.g. browser charset auto-detection rendering clean on one pass and garbled on another). An aggregate or final design review must therefore re-render the actual artifact set at review time, not trust earlier per-screen captures or a source-level pass.

Conformance, not confirmation, for *specified* states: where the authoritative design source **specifies** a state's treatment (the signed-off draft, or the design system's matrix entry for failure / empty / loading / disabled / long-content / etc.), a rendered capture is conformance evidence only when checked *against that spec* — not waved through because "it looks like the new visual language". A confirmation-grade self-inspection shares the author's blind spot and passes states the source draws differently: a failure state in the wrong color family or treatment, an empty/error state off its specified position, a missing specified affordance. For each spec'd state record `matches spec` or the named divergence. When a capture diverges from a treatment the source **specified**: if the code drifted, correct the code to the spec; if you intend to change that specified treatment, change it in the **design source first** (a design-system / draft edit, reviewed there) and let code follow — silently re-specifying a designed treatment in code is the defect, the same way silently drawing a behavior change is. (A treatment the source leaves *unspecified* is Design freedom per the classes above — invent it in code freely; this rule governs divergence from what the source did specify, and does not gate evidence for source-light work where no such spec exists.)

Shift-left the judgment lenses — aesthetics (decides hierarchy / rhythm / mood), interaction logic (decides flow / progressive disclosure), behavioral logic (decides feedback / recovery / friction), and psychology (decides anxiety / confidence / perceived control / motivation / trust); depth in `references/behavioral-aesthetic-logic.md` and `references/interaction-design-patterns.md` — are **first-draft generation criteria, not only review-time detectors** — generating each slice against them up front lowers later defect density and lets review converge as confirmation rather than discovery. This complements but does not replace rendered + independent/adversarial review: an author applying the lenses to their own draft shares that author’s blind spots, and render-layer, state-sync (e.g. a stale status badge after its approval), and source-classification defects are invisible to design-thinking lenses, so they surface only in rendered or independent review. Treat "I applied the judgment lenses to my own draft" as hypothesis-grade, the same as any self-PASS — it reduces, never removes, the need for the gate. When a defect class is found in one slice, sweep the same class across all sibling slices in one pass, not only where flagged: grep the pattern for text-detectable classes, but **re-render the sibling set** for render-class defects (overflow, mis-drawn or reversed control, encoding artifact) that grep cannot see — a grep-only sweep does not close a render-class defect. Same-class recurrence across review rounds is the signal it was under-swept. Sweep scope is gated by migration state, though: when the fix stamps a *migrated* value (a new token, the post-restyle treatment) and the sibling surfaces sit at mixed migration states, apply it only where the sibling is already migrated — putting a migrated value onto a not-yet-migrated sibling (an ink-toned shadow under a still-old-palette element, a new-token color beside old-token siblings) manufactures a half-migrated inconsistency worse than the untouched original. Sweep the *detection* across all siblings; apply the *fix* only to the in-scope ones and record the rest as pending their own slice.

For systemic UI/UX redesigns spanning web, mobile app, mini-program, terminal/TUI, desktop/native, or mixed client stacks, keep one product-quality bar across stacks. This is the **cross-stack page-slice gate** that the stack implementation skills (`web-react-dev`, `app-cross-platform-dev`, `miniapp-product-dev`, `terminal-cli-dev`) reference by name. The stack changes the implementation owner and rendered-evidence tool, not the design gate. Apply this gate as discrete checks:

1. Trigger it for any single-screen change declared as redesign/restyle, modernize, align-with-new-style, or equivalent; any whole-screen/surface change that alters layout structure, content grouping, or visual system regardless of wording; any partial-surface change that alters content grouping or visual system beyond a shared-token/component sweep; any redesign continuation; any two-or-more screen/surface change with redesign or restyle intent; or any slice that uses a previous redesigned surface as its quality reference. Any slice evaluated against these trigger conditions must record the trigger/no-trigger classification with the structural-change basis in a persistent reviewable artifact such as the MR description, plan file, or evidence file; copy or spacing tweaks keep the lighter visible-UI path only when they are neither declared as redesign/restyle/modernize-equivalent nor change structure or visual system, and that no-trigger classification is recorded; a declared redesign/restyle is always triggered, even when the author believes the change is cosmetic. When in doubt, treat the gate as triggered. Shared-token or shared-component sweeps without IA/behavior change keep the lighter sweep path above.
2. Record the page-slice checklist before completion. Every item below needs a recorded entry:
   - RED-first focused assertion. A triggered slice must record a falsifiable baseline: a failing focused test where one fits, or, for visual/layout slices, a recorded before-state versus target assertion or screenshot-diff baseline. A verifiable-reason `N/A` excuses only the failing-unit-test form, never the recorded baseline itself, and a fabricated failing unit test is never acceptable. The RED baseline must name its provenance type: a recorded incident or existing screen capture needs a checkable pointer such as an artifact path, issue link, or commit that resolves at review time; a constructed scenario needs reproducible construction steps or a script path.
   - IA regrouping by user intent/consequence.
   - Chosen reference surface and why, or fallback to a design reference/spec when no redesigned surface exists.
   - Behavior-contract diff for routes, APIs, auth/session cleanup, destructive actions, write flows, and return values.
   - State matrix for empty/loading/success/failure/retry/disabled/permission/long content/stress viewport or target-size states.
   - Rendered evidence artifact path that resolves at review time, or an explicit unavailable-with-owner record that appears in the MR/completion report and leaves the slice `pre-runtime-test ready` / `blocked` and handoff-only, not complete.
   - Design verdict: record `accepted` / `rejected` / `pending` for the rendered evidence against the slice's visual/behavioral acceptance criteria. A missing or absent verdict counts as `pending` and blocks complete/MR-ready exactly like a missing rendered-evidence record — silence is not acceptance. The slice author may record only a `candidate` self-assessment, never `accepted`: self-PASS is hypothesis-grade (see the judgment-lenses rule above), so `accepted` requires a user review or a named independent design-owner pass, and after any `rejected` verdict that user/independent acceptance is mandatory. A `rejected` verdict triggers the **Rejected-surface rule** above.
   - Persistent plan/evidence/MR update.
3. Route rendered proof by stack: local server plus browser/Playwright evidence, console/network inspection, responsive widths, text-overflow, and accessibility-relevant checks for web; emulator/simulator/real-device evidence plus safe-area, keyboard, orientation, and text-scale checks for app; host developer tool, preview build, or real-device evidence plus platform API/capability checks for mini-programs; real terminal/PTY evidence for terminal/TUI size, color-depth, keyboard-only, scrollback, selection/copy, and resize behavior; platform runner/window/input-model screenshots for desktop/native, applied inline here until a project-specific client owner skill exists.
4. Persist evidence artifacts in an MR attachment, project evidence directory, or other review-accessible path using sanitized/test accounts and redacting tokens, PII, credentials, private paths, and raw personal data. Move screenshots, transcripts, and captured artifacts there before cleanup; if cleanup breaks the recorded evidence path, the slice is incomplete. Remove temporary helper scripts/pages before commit unless the repo intentionally owns them.
5. Page-slice evidence collection must not become approval-prompt churn. For mobile/app slices, route the rendered-evidence mechanics to `app-cross-platform-dev` and prefer existing routes, reusable smoke harnesses, debug entries, fixtures, or integration tests over creating a fresh temporary helper per page or screenshot. If a temporary helper is unavoidable, create or edit it once for the batch, reuse it, and remove it before commit unless the repo deliberately owns that harness. The design gate requires rendered evidence, but it does not justify noisy throwaway-file workflows that block the operator.

When changing design guidance that downstream teams must execute, name the downstream owners before landing: `web-react-dev`, `app-cross-platform-dev`, `miniapp-product-dev`, or `terminal-cli-dev` for implementation mechanics, `testing-strategy` for scenario and rendered-evidence layer selection, this skill as the default shared design-system/token owner when tokens or component semantics affect multiple stacks, and `product-rd-workflow` for cross-stage gates. Desktop/native surfaces that have no installed owner skill keep their design acceptance and rendered-evidence rule inline in this skill until a project-specific owner exists; their implementation mechanics follow project client-code conventions, not this skill. If a separate design-system skill is installed or project-owned, route token ownership there; otherwise apply the rule inline here. If the same design rule affects multiple client stacks, route through `skill-extraction-workflow` and mirror the executable rule or record why a stack is unchanged.

For visible UI changes that introduce or substantially reshape a screen, run a visual direction pass before coding or before final acceptance. Name the typography source, primary color source, neutral surface/background scale, radius/shadow role, and whether existing theme tokens are sufficient. If no strong design reference or product token exists, produce two or three compact visual direction options, or explicitly state why the existing product visual language is being reused unchanged.

The design checkpoint must include an adaptation matrix before coding or approval: primary viewport, stress viewport(s), collapse rule, density/spacing mode, long-text handling, empty/loading/error geometry, and screenshot or device checks. For web workbenches, secondary panels must collapse before primary content becomes unreadable. For mobile/app/H5, safe-area, keyboard, touch target, orientation, and OS text-scaling (large-font) behavior must be covered when relevant. For mini-program targets, name the host platform and route platform-specific implementation and release evidence to `miniapp-product-dev`. For terminal or CLI/TUI targets, name the terminal size, color-depth/fallback assumption, keyboard-only path, scrollback behavior, selection/copy boundary, and route ANSI/PTY/rendering mechanics to `terminal-cli-dev`.

For admin, operations, moderation, analytics, creator-tool, or AI-review workspaces, default to a productive compact design unless the target user workflow is consumer-facing. Prefer a clear workbench structure: persistent context/status strip, focused input/control region, prominent output/review region, visible empty/loading/error/success states, and explicit trust boundaries for generated or high-impact content. Avoid dumping forms and response fields into generic adjacent cards without a visible workflow. Do not use marketing-style hero banners, decorative gradients, oversized empty states, or heavy visual drama to make an operational screen feel designed; the screen should feel calm, dense, and action-oriented.

For high-risk flows, design must cover resilience, not only visual polish. If the surface touches money, quota, permissions, tenant/user data, privacy, high-impact AI output, repeated submission, async finality, or support-traceable incidents, the design checkpoint must include pending, success, failure, retry, blocked, degraded/refused, partial, and support-contact states as applicable. Users should know whether an action happened, whether it is safe to retry, and what identifier or next step support can use.

When an interaction is **optimistic** — the UI applies a local change before the server confirms it (instant like/favorite, delete, reorder, toggle, inline edit) — displaying a failure state is not sufficient: on server rejection or error the optimistically-applied change must be **reverted or reconciled to authoritative server state**, not left showing the stale optimistic value (the failure banner renders correctly while the displayed data is wrong). Match the displayed state to the actual reconciliation **outcome**, not to a generic "error": an **authoritative reject** reverts to the prior value; a **confirmed-applied** result stays only when the server's returned representation matches the optimistic value, else it reconciles to the server's canonical truth (trimmed text, server-adjusted count, canonical reorder, moderation-adjusted status); an **indeterminate** result (timeout / transport error where the server may have applied it) shows pending/unknown with a safe-retry affordance rather than falsely claiming it did not happen; an **offline** action shows queued/unsynced; a **conflicting or superseded** result reconciles or merges with server truth; a **partial** success shows partial. What is forbidden is leaving the stale optimistic value on screen as if it succeeded when it did not — that is the silent data-integrity lie. (This complements, and must not contradict, the resilience-state rule above: the user still learns whether the action happened and whether retry is safe.)

For AI-generated, automation-generated, or dangerous-operation surfaces, show review state and accountability. Generated content should expose candidate/draft/review status and provenance metadata where useful; dangerous operations need reason, operator, confirmation, and audit/support context in the interaction, not only in backend logs.

For configurable shortcuts, command palettes, or keyboard-first tools, design the shortcut system as a user-facing interaction contract, not invisible implementation glue. The design checkpoint must cover discoverability, reserved or non-rebindable key combinations and actions, conflict and invalid-binding messages, mode/context priority, text-input and composition safety, keyboard-only access to the same primary actions, and a visible recovery path to defaults. Route parser, dispatch, cleanup, and browser/runtime mechanics to the owning client skill; route assertion coverage to `testing-strategy`.

For terminal, command-line, or full-screen text UI surfaces, design for a constrained text grid rather than a browser canvas. The checkpoint must cover readable hierarchy without relying on color alone, narrow and short terminal behavior, long output, streaming and background progress, empty/error/retry/final states, keyboard-only navigation, focus or modal state, scrollback and "new output" affordances, selection/copy cleanliness, and color-disabled or reduced-color fallback. Route cell-width, ANSI style, PTY, input parsing, resize, scrollback, and real-terminal verification mechanics to `terminal-cli-dev`; route test-layer coverage to `testing-strategy`.

For users without internal Figma or code access, skip provenance verification and apply the distilled references directly. Ask for source access only when the task requires auditing, updating, or re-extracting from the original artifacts.

## Current Extraction Baseline

The baseline extraction already covers reusable web shell, mobile app, token/component, complex creation/import interaction, analytics visualization interaction, operational processing workspaces, resource management, dense workflow, implementation-state, trust-sensitive AI/data, external quality, and launch/iteration patterns. Detailed source names, file keys, and extraction history live only in `references/source-map.md`.

Treat additional formal Figma files as required extraction sources. Integrate them into the baseline through keep/merge/discard decisions rather than appending raw business-specific requirements.

Do not invent source coverage, Figma findings, code evidence, screenshots, or review results. If source access is missing or evidence is thin, record the gap and apply only the already distilled rules.

## Product Defaults

- Optimize for the target product's user workflow first: discovery, decision, creation, review, transaction, operation, monitoring, recovery, or return loop depending on the product category.
- Use scenario references as optional lenses: community for feed/creator/social loops, finance/data for trust-sensitive decisions and dense analysis, operational workbench for repeated expert workflows, AI workspace for generated-content review and accountability.
- Use source-design assets as design evidence only when they improve consistency, speed, polish, or interaction completeness; adapt or discard workflow details that do not fit the target product.
- Prefer the product-appropriate feel: approachable for consumer surfaces, quiet and dense for operational tools, trust-centered for finance/data products, and reviewable/accountable for AI-generated or automated surfaces.
- Build a coherent and recognizable visual language for the product; avoid generic AI-template aesthetics while keeping design-system consistency.
- Reuse available token and component systems before inventing custom UI.
- Keep web, mobile app, mini-program, and terminal interaction patterns separate, but share brand color, typography, spacing, and component semantics where the design system supports it and the target surface can express them.
- Prefer published design-system files for tokens/components. Use product screens as pattern evidence, not as mandatory product requirements.

## Domain Guardrails

- Do not infer that the target product is about education, finance, community, operations, or any other source domain just because some source files came from that domain.
- If the user or active product context explicitly says the product is education, finance/data, community, operations, AI, or another domain, use domain-appropriate terminology, role model, information architecture, and risk states deliberately.
- If the target domain is not explicit, keep source-domain terms as provenance only and translate reusable mechanisms into neutral product language.
- Code-evidence sources are behavior, instrumentation, recovery, permission, and launch-quality evidence only; never use them as visual, information-architecture, or interaction-taste benchmarks.
- Translate reusable source patterns into target-product equivalents. For community products this may be feed cards, profile/user identity, topic spaces, comments/replies, reactions, follow/subscribe, creation flows, notifications, moderation/trust states, AI interaction, onboarding, and retention loops. For finance/data products this may be research workflows, evidence panels, risk/status states, portfolio/watchlist surfaces, data provenance, permissions, and review-before-action patterns.
- Keep old source terminology in reference notes only; do not surface it in new product UI copy or product structure.