agentleFS
Sign inStart free
alexderzalexderz/agentic-toolbox/skills/ux-design/SKILL.md

ux-design

Skill5 starsChanged 47 days agoMITView on GitHub

use this when writing user stories, high-level UX, or UI mockups — designer persona; variants in any attached tool or markdown/HTML/canvas; agent review vs requirements then operator. do not use to implement, apply reviewer taste, or skip the operator gate.

23 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use app-brief, design-from-app and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • StijnusSkill

    app-brief

    One-page brief (docs/BRIEF.md) for a new macOS app, written before any code. Use when the user has an app idea, wants to replace an app they pay for, or the research and clone skills are done.

    Also in 3 projects that use this

  • StijnusSkill

    design-from-app

    Rebuild the look of an app the user likes as a native SwiftUI design kit, by measuring its screenshots (sizes, spacing, type, colors, icons), building its parts, and comparing pixel by pixel until they match. Use when the user names an app whose look they want, shares screenshots of one, or says "make it look like X".

    Also in 3 projects that use this

  • launchapp-devSkill

    layout-grid

    Define responsive layout grid systems with columns, gutters, margins, and breakpoint behavior.

    Also in 3 projects that use this

  • hongyuancSkill

    vertical-slice

    Build and evaluate a production-quality vertical slice before advancing from Pre-Production to Production.

    Also in 5 projects that use this

  • MohamedAbdallah-14Skill

    app-icon

    Generate an app icon from a single 1024² master and fan out to iOS (AppIcon.appiconset with squircle-ready 1024 opaque), Android (adaptive foreground + background + Android 13 monochrome), PWA (192/512 + 512 maskable with 80% safe zone), and visionOS (3-layer parallax).

    Also in 3 projects that use this

  • timeplus-ioSkill

    build-and-verify

    Build, compile, run server/client/cluster, execute unit/stateless/SQL tests, verify results, and troubleshoot build/test failures. Make sure to use this skill whenever the user mentions building, compiling, ninja, cmake, running tests, test failures, starting the server, or pre-commit checks, even if they just say 'it doesn't build' or 'the test broke'.

    Also in 3 projects that use this

  • +1 more from Stijnus

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 23 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If HTML lives in an existing app, variants on one route (?variant=) are fine.

    line 37
  2. Very specific:

    If two look the same, redo one.

    line 45
  3. Distinctive:

    Avoid AI-default look unless the brief asked for it: purple/indigo everything, heavy gradients, max rounding, generic hero, cookie …

    line 56
  4. Distinctive:

    If they disagree on the requirements, ask the operator (Asking the operator).

    line 79
  5. Distinctive:

    When the agents agree, ask the operator the same way: show the variants and say which the agents recommend and why (requirements, not …

    line 81
  6. Distinctive:

    If UI changes in Build, update stories/mockups in the same land.

    line 90

“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

UX design

designer skill. Stories and how it feels, not the Spec (LLD). Templates (sdlc-artifacts): user-story.md, ux.md, mockup.md, comparables.md. No scripts/. No language skill on a UX-only turn.

Inspired by Pocock UI variants (structurally different options), Addy anti-“AI default” UI, hueyexe composition (hierarchy, states, explain as function not taste). Not those packs.

Iron law

Agents agree the design meets the written requirements. Then the operator accepts — unless they waive in writing. Designer, architect, and builder do not self-approve. Agent reviewers do not apply their own taste.

Medium (mockups)

The job is a deliverable in git the operator can look at. Pick one medium this agent can actually produce. Do not stall for a plugin.

MediumWhen
Markdown wireframeAlways works. Default if nothing else is attached
HTML/CSS in docs/mockups/Best “click around” without a design tool
Canvas / JSON canvasSpatial flows
ImageMood/layout when HTML is overkill
Attached design tool (Figma, Stitch, Penpot, …)Only if that tool is on this agent. Store the link and a git snapshot (PNG or HTML)

If HTML lives in an existing app, variants on one route (?variant=) are fine. Prototype code is not production — fold the winner later via tdd.

Variants

For a screen, default 3 structurally different options (cap 5). Different layout, hierarchy, or primary action — not three color tweaks. If two look the same, redo one. Label A/B/C. After a winner, keep the set in git until the operator has picked; then keep the winner, drop the rest from the live path.

Produce (designer)

  1. Comparables — 2–4 real products/screens (comparables.md): steal / won’t copy. Same page as the architect, plus look-and-flow.
  2. Feature and stories first, chrome last.
  3. Hierarchy in structure (and grayscale if visual) before color.
  4. Empty / error / loading named or pictured.
  5. Avoid AI-default look unless the brief asked for it: purple/indigo everything, heavy gradients, max rounding, generic hero, cookie Inter-on-white. Use the product palette if one exists.
  6. Color is not the only signal. Familiar controls unless the brief wants novelty.
  7. Explain choices as task fit, not “I like it.”

Designer and UX reviewer ids, and resume across rounds: Step agents.

Review loop (agents, then operator)

Loop and operator acceptance: UX.

  1. UX reviewer reads the brief, the stories, and written taste/shape if those are requirements. Checks:
    • Can the user finish the job in the stories?
    • Empty/error/loading covered?
    • Matches stated constraints (brand, density, platform)?
    • Variants are actually different? Does not add “I would use more whitespace” unless the write-up asked for that shape.
  2. Designer fixes; the UX reviewer re-checks until those agents agree. If they disagree on the requirements, ask the operator (Asking the operator).
  3. When the agents agree, ask the operator the same way: show the variants and say which the agents recommend and why (requirements, not taste).

Always

  • Copy templates. Link brief, HLD, stories, mockups.
  • One job per story. Checkable “done when.”
  • Agent review before the operator, except a written waiver.
  • If UI changes in Build, update stories/mockups in the same land.

Ask first

  • Skipping mockups or comparables when there is a screen, without a written waiver.
  • Fighting an existing product UI with a new visual system.

Never

  • Implement the product as the mockup.
  • Reviewer taste, or “the architect liked it.”
  • Fake screenshots. One medium with nothing in git.
  • Load a language skill “so we can code the screen next.”
  • Show the operator before agents agree, unless they asked to see drafts.

Red flags

  • “We’ll show the operator after it works”
  • Three variants that are the same card grid
  • Reviewer rewriting the palette with no requirement

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free