Product Ui Ux Design

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-surfac

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ccoalm
• Source: ccoalm/ccl-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.