---
name: frontend-ui-ux
description: Frontend and user-facing UX review discipline adapted for LazyClaude for Claude Code apps, docs, CLI surfaces, and plugin install flows.
---

# Frontend UI UX

Use this skill for browser UI, CLI UX, documentation UX, screenshots, and any
user-facing workflow. For LazyClaude, the main UX surface is install, command
activation, docs, and clear terminal output.

## Product Posture

LazyClaude is a developer/operator tool. Prefer quiet, direct, scan-friendly
interfaces over marketing-heavy copy. A good UX lets the user install, launch,
verify, update, and uninstall without remembering long paths.

## CLI UX Rules

- Show the command the user should run next.
- Prefer `Launch with: claude` after global plugin install.
- Keep errors actionable and short.
- Do not expose implementation paths unless they help diagnosis.
- Include `--dry-run` for safe inspection.
- Do not require repeated long `claude --plugin-dir ...` commands after install.

## Documentation UX

- First screen should answer what it is, how to install, and how to run.
- English and Korean READMEs should agree on commands and version.
- Put caveats near the command they affect.
- Avoid claiming unsupported automation such as silent `/goal` injection.
- Keep private-use posture clear: public npm convenience, no advertisement.

## Visual Assets

If changing `cover.png` or visual docs, verify dimensions and rendering. In this
repo, tests expect a PNG with social dimensions. Do not replace it with a broken
or purely decorative asset that hides the product signal.

## Manual QA

For browser UI, drive the browser. For CLI UX, a tmux transcript or captured
shell output is the surface. The artifact must show the exact text a user sees.

Good LazyClaude CLI QA:

```sh
npm exec --yes --package ./ -- lazyclaude-ai --dry-run install
```

PASS if the output shows the intended version, install paths, plugin key, and
`Launch with: claude`.

## Accessibility and Clarity

- Avoid long wrapped commands when a shorter command exists.
- Avoid jargon in first-use docs.
- Make fallback behavior explicit only where it helps action.
- Keep warnings near risky operations such as publish, uninstall, or registry
  mutation.

