agentleFS
Destynova2Destynova2/cli-code-skills/cli-forge-choice-ux/SKILL.md

cli-forge-choice-ux

Skill5 starsChanged 8 months agoMITView on GitHub

Design, audit, and simplify user choice flows: checkout, purchase, ordering, pricing selection, signup, onboarding, settings, configuration wizards, plan pickers, product configurators, forms, and any interface where users must decide, configure, buy, subscribe, or complete a guided task. Use when the user says UX, UI, ergonomics, simplify interface, reduce friction, checkout, purchase flow, fast buying, signup friction, settings UX, configurator, VM order, cloud resource creation, modify resource, delete resource, CRUD UI, resource lifecycle, choice overload, decision fatigue, less is more, more is less, progressive disclosure, Hick's Law, Fitts's Law, or golden ratio in UI.

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 17 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill for both:

    line 35
  2. Distinctive:

    Design: create or redesign a choice flow.

    line 36
  3. Very specific:

    Read references/principles.md when you need the detailed rule table, scorecard, numeric thresholds, and pattern catalog.

    line 49
  4. Distinctive:

    If the flow is unclear, infer from route names, copy, component names, screenshots, or user context.

    line 68
  5. Distinctive:

    Required decisions: must happen now to progress.

    line 73
  6. Distinctive:

    Advanced decisions: should be hidden behind "Advanced", "Customize", or expert mode.

    line 76
  7. Distinctive:

    Do not make users relearn the UI for each operation.

    line 92
  8. Distinctive:

    Ask once: never ask again for values already known.

    line 95
  9. Distinctive:

    Defaults are decisions: every default should produce a useful, safe result.

    line 96
  10. Distinctive:

    Reduce fields: remove, infer, prefill, combine, or ask later.

    line 106
  11. Distinctive:

    Use proven interaction math first:

    line 134
  12. Distinctive:

    Use visual math second:

    line 140
  13. Distinctive:

    Use existing design-system primitives before creating new components.

    line 195
  14. Distinctive:

    Keep changes close to the flow under review.

    line 196
  15. Distinctive:

    Do not add decorative cards, hero sections, or marketing copy unless the flow needs them.

    line 197
  16. Very specific:

    Add visible focus states, semantic controls, proper labels, and usable disabled/loading/error states.

    line 198
  17. Distinctive:

    Verify responsive behavior if the project has a runnable frontend.

    line 199
  18. Distinctive:

    Every required field is justified.

    line 205
  19. Distinctive:

    Every optional/advanced choice is hidden or deferred.

    line 206
  20. Very specific:

    Create/edit/delete/clone flows reuse the same vocabulary, section order, summary, and state model.

    line 208

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Optimization: This skill uses on-demand loading. Detailed laws, numeric heuristics, and pattern libraries live in references/.

Language rule: Skill instructions are written in English. User-facing output should use the user's language.

Choice UX Forge

Simplify interfaces where users must choose, configure, buy, subscribe, or complete setup. The goal is not "prettier UI"; the goal is fewer doubts, fewer fields, fewer dead ends, and faster confident action.

Use this skill for both:

  • Design: create or redesign a choice flow.
  • Audit: inspect an existing UI and produce prioritized fixes.

Source Synthesis

This skill is a clean local synthesis, not an installed third-party skill. It condenses patterns from:

  • Vercel-style web interface checks: accessibility, forms, focus, motion, copy, content resilience.
  • Bencium-style controlled UX: intentional visual decisions, progressive disclosure, immediate feedback, accessibility.
  • CRO/signup/onboarding/pricing playbooks: value clarity, field reduction, CTA hierarchy, trust, activation, pricing anxiety.
  • Established UX laws: Nielsen heuristics, Hick's Law, Fitts's Law, Miller's Law, Jakob's Law, Baymard checkout findings, WCAG target sizing.
  • Local cli-* ergonomics: ask once, derive the rest, use defaults, recap before apply, make re-runs safe and stateful.
  • Material/GOV.UK patterns: one primary action, explicit states, confirmation/acknowledgement, check answers, back/change/resume behavior.

Read references/principles.md when you need the detailed rule table, scorecard, numeric thresholds, and pattern catalog.

Workflow

1. Classify the Flow

Identify the flow type before making changes:

FlowUser intentMain risk
Checkout/orderComplete purchaseAbandonment from friction or mistrust
Pricing/plan pickerChoose the right offerChoice anxiety, hidden constraints
Signup/trialCreate accountToo many fields before value
Onboarding/setupReach first valueTutorial fatigue, blank-slate confusion
Settings/configChange behavior safelyFear of breaking things
Product configuratorBuild a valid option setInvalid combinations, overload
WizardComplete guided setupAsking too much too early
Resource lifecycleCreate, edit, clone, resize, delete a resourceUser loses context between operations

If the flow is unclear, infer from route names, copy, component names, screenshots, or user context. Ask only if ambiguity changes the solution materially.

2. Map the Decision Load

For each step/screen, list:

  • Required decisions: must happen now to progress.
  • Derivable decisions: can be inferred from data, environment, prior answers, defaults, or user profile.
  • Deferrable decisions: can happen after purchase/signup/activation.
  • Advanced decisions: should be hidden behind "Advanced", "Customize", or expert mode.

Rule: if a decision is not required now, do not put it in the main path.

3. Preserve the User's Mental Model

For lifecycle resources (VMs, projects, clusters, plans, subscriptions, accounts), design one reusable grammar across operations:

OperationSame UI grammarDifferent safety layer
CreateSame sections, labels, defaults, summaryExplain new resource impact
Edit/resizeSame sections pre-filled from current stateShow diff: before -> after
CloneSame create flow pre-filled from sourceHighlight inherited values
Delete/cancelSame resource summary and namingRequire explicit destructive confirmation or undo
Restore/rollbackSame summary and status languageShow target restore point and data loss risk

Do not make users relearn the UI for each operation. The screen may differ, but the vocabulary, section order, summary panel, validation, state labels, and primary/secondary action hierarchy should stay consistent.

Borrow the local CLI ergonomics laws for UI:

  • Ask once: never ask again for values already known; prefill and carry forward.
  • Defaults are decisions: every default should produce a useful, safe result.
  • Recap before apply: show a review/diff before creating, resizing, deleting, or billing.
  • Re-run safe: returning to the flow restores prior state, not a blank form.

4. Apply the 7 Friction Cuts

Work in this order:

  1. Clarify value: user can say what they get and what happens next.
  2. Reduce choices: group, recommend, default, or defer options.
  3. Reduce fields: remove, infer, prefill, combine, or ask later.
  4. Strengthen CTA hierarchy: one primary action per decision region.
  5. Prevent errors: constraints, inline validation, valid defaults, reversible actions.
  6. Add feedback: loading, saving, selected, invalid, success, progress.
  7. Build trust: price clarity, security/privacy cues, no surprise fees, confirmation recap.

5. Design the Main Path First

The main path should feel like:

Recognize goal -> choose recommended path -> verify recap -> commit -> recover if needed

Prefer these moves:

  • Recommended option with explicit reason.
  • Smart defaults from context.
  • Guest checkout where possible.
  • "Full name" instead of first/last unless legally required.
  • Single email field; no confirmation duplicate.
  • Visible labels, not placeholder-only labels.
  • Optional account creation after purchase, not before checkout.
  • Basic settings visible, advanced collapsed.
  • Inline edit for simple settings; full form only for complex edits.
  • Recap before destructive or costly apply.

6. Use Math as Constraint, Not Decoration

Use proven interaction math first:

  • Hick: fewer competing choices reduce decision time.
  • Fitts: larger/closer targets are faster and safer.
  • Miller/chunking: group fields and options into small meaningful sets.
  • Tesler: complexity cannot disappear; move it from user decision time into system defaults, validation, and progressive disclosure.

Use visual math second:

  • 4/8 px spacing scale for rhythm.
  • Type scale around 1.2-1.333 for hierarchy.
  • 45-75 characters per text line.
  • Touch targets: 44 px preferred; 24 px absolute WCAG 2.2 minimum where space constrained.
  • Golden ratio may inspire composition, but never outranks usability, accessibility, responsiveness, or clarity.

7. Audit Output

When auditing, produce:

## Choice UX Report

**Flow:** [checkout / pricing / signup / settings / configurator / wizard]
**Primary action:** [what user must complete]
**Main blocker:** [top friction source]

### Score

| Dimension | Score /10 | Notes |
|-----------|-----------|-------|
| Decision Load |  |  |
| Field Friction |  |  |
| CTA Clarity |  |  |
| Error Prevention |  |  |
| Feedback & State |  |  |
| Trust & Reassurance |  |  |
| Accessibility |  |  |
| Lifecycle Consistency |  |  |

### Must Fix
- [impact] [fix] [location if available]

### Should Fix
- [impact] [fix] [location if available]

### Nice To Test
- [hypothesis] [metric]

### Proposed Flow
1. [step]
2. [step]
3. [step]

### Copy / UI Rewrites
- CTA: "[old]" -> "[new]"
- Label: "[old]" -> "[new]"
- Error: "[old]" -> "[new]"

8. Implementation Rules

When editing code:

  • Preserve existing framework, component library, tokens, and routing.
  • Use existing design-system primitives before creating new components.
  • Keep changes close to the flow under review.
  • Do not add decorative cards, hero sections, or marketing copy unless the flow needs them.
  • Add visible focus states, semantic controls, proper labels, and usable disabled/loading/error states.
  • Verify responsive behavior if the project has a runnable frontend.

Decision Gate

Before finalizing, confirm:

  • Main path has only one primary CTA per step.
  • Every required field is justified.
  • Every optional/advanced choice is hidden or deferred.
  • User always knows current state, next step, and how to recover.
  • Create/edit/delete/clone flows reuse the same vocabulary, section order, summary, and state model.
  • Checkout/signup/settings can be completed by keyboard.
  • Mobile targets and text fit without overlap.
  • Visual hierarchy guides the eye without relying on decoration.

Handoffs

NeedRecommend
General frontend polishfrontend-design or a project design system
Technical UI best-practice auditVercel-style web interface checklist
Marketing page copy/CRO beyond the flowCRO/copywriting skill
Config wizard lifecycle/cli-audit-wizard
Performance bottleneck/cli-forge-perf

Recommend handoffs; do not auto-run them unless the user asks.

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.