AgentStack
SKILL verified MIT Self-run

Ux Loaders And Progress

skill-uxcel-lab-product-skills-loaders-and-progress · by Uxcel-Lab

Design or critique loading states and progress indicators — match the feedback type (spinner, text, determinate bar, skeleton, progress tracker) to the wait duration and task structure, and manage perceived performance. Trigger when the user asks to design or review loaders, spinners, loading states, skeleton screens, progress bars, progress trackers, steppers, or multi-step flow progress.

No reviews yet
0 installs
6 views
0.0% view→install

Install

$ agentstack add skill-uxcel-lab-product-skills-loaders-and-progress

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Ux Loaders And Progress? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Loaders & Progress Skill

How this skill behaves (read first)

This is a generative skill. The default failure modes: one spinner for everything (a full-page spinner whether the wait is 1 second or 60), no endpoint when one exists (indeterminate loops for measurable tasks), and progress theater (trackers on 2-step forms, percentages that lie). The feedback type is determined by wait duration and task structure — and a loader's real job is shaping perceived time, not decorating it. This skill gates:

  1. Establish the wait type — how long, is it measurable, what initiated it, is it a multi-step journey?
  2. Apply the always-true core — the duration ladder, placement, state visibility.
  3. Surface the context-dependent decisions (skeletons, custom animation, tracker labeling, save/autosave) with trade-offs.

Then it hands off to ux-heuristics-audit, ux-accessibility-audit, ux-aesthetics-audit, and ux-microcopy-audit for validation.


Step 0 — Establish the wait type

Four questions pick the indicator:

  • How long is the wait? Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.

After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics and microcopy are Tier A (auto-run); accessibility, aesthetics, and mobile-responsiveness are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage; mobile-responsiveness applies only on mobile. If the user invoked this skill for one specific thing, respect that scope.

  • ux-heuristics-audit (Tier A) — visibility of system status is this component's entire reason to exist; also error prevention (disabled buttons during processing).
  • ux-accessibility-audit (Tier B — offer; narrow under a design system) — loading states announced to screen readers, animation respecting reduced-motion preferences, contrast of muted tracker steps.
  • ux-aesthetics-audit (Tier B — offer; suppress under a design system) — skeleton fidelity to real layout, animation restraint, tracker visual hierarchy.
  • ux-microcopy-audit (Tier A) — text-loader wording, step labels, percentage/status phrasing.
  • ux-mobile-responsiveness-audit (Tier B — offer; applies only on mobile) — when the context is mobile: tracker compression, skeleton reflow.

If the audits surface a conflict (e.g., brand animation vs. perceived speed), resolve back toward the primary task: the user is waiting — every design choice either shortens that wait perceptually or lengthens it.


Common do/don't patterns

| ❌ Don't | ✅ Do | |---|---| | Full-page spinner for everything | Inline spinners, skeletons for content, centered only for true page loads | | Looping spinner on a 60-second upload | Determinate bar with endpoint + percentage | | Spinner where the layout is known | Skeleton screens, filled sequentially | | Clickable button while its action processes | In-button spinner, button disabled | | Loader floating far from its cause | Feedback at the action or on the content | | Progress tracker on a 2-step form | Trackers from 3 stages; short forms stay plain | | Unlabeled tracker dots | Step titles + clear completed/current/remaining states | | 11-step tracker as a fix for a bloated form | 5–7 steps max; restructure the flow | | % that jumps 10→80→82→… | Honest progress mapping, or use steps | | Long form with no save | Autosave + return to the last step | | Ship without checking | Hand off to heuristics + accessibility + aesthetics + microcopy |


Source lessons (Uxcel)

Source & license

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

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

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.