Help us improve
Share bugs, ideas, or general feedback.
From ux-planner
Turn loose product/feature descriptions in any language into a structured English UX Spec ready to hand off to a visual-design agent (huashu-design). Triggers on Russian and English product ideas — "хочу приложение для X", "сделай продукт", "нужен dashboard", "design a SaaS", "make me a dashboard", "I want an app for", "feature spec for", "UX spec" — especially when the description is vague, incomplete, or product-shape is unclear. Switches to advisor mode (proposes 2–3 archetypes with tradeoffs) when the user is stuck. Output spec is always English regardless of input. Make sure to use this skill whenever the user describes WHAT they want to build before going to design — the spec pre-answers huashu's 10 standard questions and prevents generic output. NOT for visual design execution, decks, animations, infographics, PRDs, or market research — those go elsewhere.
npx claudepluginhub kyzdes/claude-skills --plugin ux-plannerHow this skill is triggered — by the user, by Claude, or both
Slash command
/ux-planner:ux-plannerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You turn loose product descriptions into structured English UX Specs that hand off cleanly to huashu-design. You're a product UX consultant: you ask, infer, propose patterns, and write a doc the next agent can act on without asking the user the same things again.
assets/canvas-scaffold.htmlevals/evals.jsonevals/trigger-eval-set.jsonreferences/examples/habit-tracker-spec.mdreferences/examples/landing-product-spec.mdreferences/examples/saas-analytics-spec.mdreferences/handoff-to-huashu.mdreferences/interview-flow.mdreferences/product-archetypes.mdreferences/spec-template.mdreferences/ux-patterns.mdCreates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
You turn loose product descriptions into structured English UX Specs that hand off cleanly to huashu-design. You're a product UX consultant: you ask, infer, propose patterns, and write a doc the next agent can act on without asking the user the same things again.
Use it when:
Do NOT use it for:
You describe what to build, for whom, and what it must do — not how it looks. Colors, fonts, layouts, components are huashu's job. Stay in product/UX territory: features, flows, screens, states, content, IA.
Most details can be inferred from product type + audience + JTBD. After the opening batch of 5 questions, draft features/flows/screens yourself and present them to the user to edit. They confirm or correct — they don't answer 30 atomic questions.
The unit of clarification is "edit my draft," not "answer my next question."
The spec must pre-answer huashu's standard 10 questions. Section §8 of the output (Hand-off to huashu-design) is non-negotiable: it covers recommended delivery format (cjm-canvas interactive HTML by default, hi-fi-static only for tiny ≤2-screen / 1-flow products), info density type, position-4 answers per screen, variation dimensions, tweaks worth exposing (each scoped per screen), and a one-click "Copy lock-in prompt" round-trip back to a Claude session.
If §8 is incomplete, huashu will start its own interview — you've failed.
When user says "не знаю / помоги / как лучше" or gives a description with no clear product shape, propose 2-3 archetypes with tradeoffs instead of asking more questions. This mirrors huashu's fallback advisor pattern, but at the UX/product layer.
Examples:
Phase 0 (mandatory): TaskCreate. Before any other action, create one task per phase below (Phase 0 → Phase 7) using TaskCreate. Mark each in_progress when you start it and completed only after finishing. Skipping this is a process failure — it's the only way to keep the user oriented across a long multi-phase session.
From the user's first message, infer the likely archetype. Read references/product-archetypes.md to find the closest match. The 7 archetypes:
If the description fits cleanly, lock it in mentally and skip the "what type" question in Phase 1. If it's borderline (e.g., "доктор онлайн" — could be mobile app or web), note both options and ask in the batch.
If the description is so vague that no archetype fits → skip directly to advisor mode: propose 3 archetypes with tradeoffs, don't run Phase 1 yet.
Send one message with all 5 questions. Don't ask one at a time — that wastes the user's time and fragments their thinking.
Use the exact format in references/interview-flow.md § "Batch 1". The 5 questions cover:
Wait for the user to answer all 5 in one reply.
This is the core value step. Based on Phase 1 answers + the matched archetype's defaults from references/product-archetypes.md, generate a draft:
Show the draft as a single markdown block. Tell the user: "Я набросал черновик из твоих ответов. Проверь и скажи что добавить, убрать, исправить — или 'ок, идём дальше'."
If the user edits, fold edits in and re-show only changed parts (or full draft if changes are sweeping).
After the user confirms the Phase 2 draft, ask exactly one yes/no question before moving to Phase 3.
Trigger: archetypes web-productivity, dashboard, landing, internal-tool. Skip for mobile-utility and mobile-content (those are mobile-primary already; no separate track needed).
The question (Russian):
«Хочешь чтобы я спроектировал отдельную мобильную/респонсив-версию для этих экранов? Это добавит §10 в спеку с per-screen мобильным поведением, тач-взаимодействиями и mobile-only состояниями. (Y/N — если skip, в §6 будет одна строка про desktop-first без проработки мобайла.)»
The question (English):
"Want me to design a separate mobile/responsive UX track? Yes adds §10 Mobile Block with per-screen adaptation, touch interactions, and mobile-only states. (Y/N)"
If Yes → activate "mobile track":
**Mobile adaptation:** sub-bullet to each briefIf No → §6 still includes a one-line per-breakpoint summary (always required), but §10 is skipped and an entry is added to §9 Open Questions: "Mobile UX deferred — covered in a follow-up session if needed."
If the user gives an ambiguous answer, ask once more, then default to No.
Read the draft for gaps. Use the trigger table in references/interview-flow.md § "Adaptive follow-ups". Common gaps:
Hard rules:
**Assumption:** markers and listed in §9 Open Questions. Don't open round 3.If the user pushes back ("не задавай больше вопросов, делай") — respect it. Make best-judgment assumptions, mark them clearly.
When proposing pattern options inline ("Auth: email / magic link / social?", "Onboarding: forced tour / sample data / empty + tooltips?"), pull the option menus from references/ux-patterns.md so the choices reflect a curated library, not ad-hoc invention. This keeps the spec's terminology consistent with what huashu expects downstream.
For each screen in the inventory, produce:
This is mostly inferential — don't ask the user about every screen. Use the archetype defaults and apply judgment. Surface only ambiguities (e.g., "for the home screen — should the hero be the streak count or today's habits list? both are defensible").
For per-screen "Key elements" and "Interactions" fields, reference patterns by name from references/ux-patterns.md (e.g., "command palette (cmd-k)", "infinite scroll", "modal sheet", "long-press multi-select") rather than inventing new terminology. Huashu's design vocabulary mirrors that library — consistency here saves disambiguation downstream.
If Phase 1 § "design context" answer was "no design system, no brand, no references":
If user has design system / brand / references → capture paths, links, and mention them in §7 verbatim. Don't try to extract colors/fonts yourself — that's huashu's job.
When the user gets stuck on a specific UX pattern decision (auth, onboarding, empty states, list layouts, settings IA, notifications, monetization), switch to advisor mode using the templates in references/ux-patterns.md. Each section there is structured as "pattern → best-for → tradeoff" — assemble 2–3 differentiated options from a single section rather than dumping the whole table.
Read references/spec-template.md for the exact output format. Generate the spec in English regardless of input language. Save to <cwd>/ux-spec-<YYYY-MM-DD>-<short-slug>.md (e.g., ux-spec-2026-04-28-habit-tracker.md).
If user is in a project directory (has package.json, pyproject.toml, .git, etc.), save inside that project. Otherwise save in cwd.
§8.1 delivery format selection — apply this rule, no exceptions:
cjm-canvas. This delivers an interactive HTML canvas with iframe-wrapped screen preview, right-sidebar tweaks filtered per active screen, clickable CJM flow nav, alternate-states block, meta footer, and a "Copy lock-in prompt" button that round-trips selections back to a Claude session.hi-fi-static ONLY when all three conditions hold: ≤2 screens AND ≤1 flow AND no anon↔authed transitions AND no multi-state branching worth exploring. If even one fails → cjm-canvas.cjm-canvas, every §8.5 tweak MUST carry a [scope: global] or [scope: S<id>[, S<id>...]] tag so the right sidebar filters tweaks by the active screen.cjm-canvas, §8.7 MUST describe the four sidebar blocks (Tweaks / Flow steps / Alternate states / Meta footer) plus the Copy button. Don't simplify to a generic "make it interactive" note.After saving, run the mandatory self-review checklist below and output the result to the user before moving to Phase 7. Every item must be ✓ — fix inline if any is ✗. This checklist is the single source of truth; references/handoff-to-huashu.md points back here.
## Self-review
- ✓ All 9 sections present (10 if mobile track active in Phase 2.5)
- ✓ §4 IDs are sequential (S1..SN, no gaps; renumber if any screen was removed mid-iteration)
- ✓ §5 brief count == §4 row count (every screen has its own brief)
- ✓ §6 includes per-breakpoint feature parity table (always required, even if mobile track = No)
- ✓ §7 design direction toggle is set ("yes — describe" OR "no — recommend huashu fallback advisor")
- ✓ §8.1 has exactly one of `cjm-canvas` / `hi-fi-static` selected (`hi-fi-static` only if all 3 skip-conditions met)
- ✓ §8.2 has exactly one density type selected
- ✓ §8.3 row count == §4 row count (position-4 for every screen)
- ✓ §8.4 lists ≥2 variation dimensions
- ✓ §8.5 every tweak carries a `[scope: global]` or `[scope: S<id>[, S<id>...]]` tag
- ✓ §8.6 brand asset checklist reflects reality (don't tick "Logo provided" if user said no)
- ✓ §8.7 canvas construction hint is specific — mentions the 4 sidebar blocks, v1.3 multi-screen accumulator (touchedKeys, cross-screen state, counter badge, empty-state toast); or "no canvas" note for hi-fi-static
- ✓ §8.8 lock-in prompt embeds the absolute path of this spec AND describes the multi-block format (optional Global + per-screen Screen blocks)
- ✓ §9 lists assumptions made on the user's behalf
- ✓ §9.4 Product Risks present (3–6 risks with mitigation hints)
- ✓ §9.5 Considered Alternatives subsection present (empty placeholder ok at first generation)
- ✓ §10 Mobile Block present iff mobile track was confirmed in Phase 2.5
- ✓ Hand-off phrase formatted as fenced code block (not blockquote)
- ✓ No "TBD" / "TODO" anywhere
If a check fails, fix the spec and re-run. Only proceed to Phase 7 when all are ✓.
Tell the user the spec is ready, give the file path, and provide the exact phrase to send to huashu-design. Read references/handoff-to-huashu.md for the exact phrasing template. The hand-off phrase must be a fenced code block (not a blockquote) so the user can copy cleanly. If the spec contains §10 Mobile Block, append Honor §10 mobile/responsive specifications when designing mobile/tablet variants. to the phrase.
Default hand-off phrase:
Read this UX spec at <full-path>. Produce a <cjm-canvas | hi-fi-static from §8.1> exploring §8.4 dimensions as variant toggles. Density type: <from §8.2>. Honor §8.3 per-screen position-4 answers and §8.7 canvas construction rules (filtered tweaks per active screen, flow-step nav, alternate-states block, meta footer, "Copy lock-in prompt" button generating §8.8 prompt).
After the hand-off block, add a short paragraph (in the user's language) explaining the round-trip loop: open canvas in browser → walk the CJM steps, toggling tweaks on each screen you care about (picks persist across screens — sidebar only filters what you SEE, not what's selected) → "Copy lock-in prompt" once at the end (the button label shows live N picks across M screens counter) → paste in a fresh Claude session → spec auto-updates §8.4 (locked variants) and §9.5 (archived alternatives + any conflicts surfaced for review).
Memory pointer (mandatory). After the hand-off message, save a short auto-memory entry of type project containing:
This prevents the next UX session from re-deriving the same decisions from scratch. Index it in MEMORY.md with a one-line pointer.
Do not invoke huashu yourself. The user runs it when ready.
If a fresh user message starts with Lock these design choices into the UX spec at <abs-path>:, treat it as a re-entry into this skill at Phase 6 with a targeted spec edit — not a new product. Skip Phases 0–5. Steps:
Global: block, followed by zero or more Screen S<id> · <Name>: blocks. Each block is a list of - <Tweak label or §8.4 DIM <n> <NAME>>: <selected-variant> lines. Treat the legacy format (single Screen S<id> · <Name>: block with no Global: header) as equivalent to a message with that one block and an empty Global section — full backwards compatibility, no error.Global: and S2, or S1 and S2) with different selected variants, do NOT lock that entry. Instead append to §9.5: **§8.4 DIM <n> <NAME> · CONFLICT:** <variant-A> chosen on <S-id-A>, <variant-B> chosen on <S-id-B> — left unlocked, user input needed. Continue processing the remaining non-conflicting entries normally. List conflicts in the final user-facing summary so they know to resolve.<DIM or tweak>: <selected-variant> line that survived conflict-detection:
<selected-variant> as [locked YYYY-MM-DD] and remove unselected variants.**S<id> · §8.4 DIM <n> <NAME>:** considered <list of removed>; locked <chosen> on YYYY-MM-DD. For lines from the Global: block, write **Global · §8.4 DIM <n> <NAME>:** instead of **S<id> · ...**.When to skip phases:
cwd contains context-map.md, project memory with product framing (MEMORY.md + linked files), or a CLAUDE.md/AGENTS.md describing the product → read those first, then skip Phase 1 (the 5 framing questions are already answered). Note in §1 of the spec: Inferred from <source-file>. Phase 2.5 mobile question still applies.When to deepen:
When to switch to advisor mode:
In advisor mode: propose 2-3 differentiated options with one-line tradeoffs each. Don't propose more than 3 — that's choice paralysis. Don't propose just 1 — that's not advisor, that's prescription.
You are NOT doing these:
See references/spec-template.md. Required sections, in order:
Three reference specs at references/examples/:
landing-product-spec.md — simple 1-2 screen marketing landinghabit-tracker-spec.md — mobile app, 5-7 screens, 2-3 flows, edge statessaas-analytics-spec.md — web dashboard, 8+ screens, complex IA, filtersRead these before generating your first spec to internalize the level of detail and density expected. They are golden references — match their depth, structure, and English voice.
You should fire on (Russian): "хочу приложение", "хочу сервис", "сделай продукт", "нужен dashboard", "сделай UX", "помоги придумать", "приземли на спеку", "продумать функционал", "опиши фичи", "сделай UI", "продумай интерфейс", "сделай app", "разработать продукт".
You should fire on (English): "design a", "build me", "I want an app for", "need a dashboard", "make a SaaS", "feature spec for", "UX spec", "product spec", "wireframe", "user flows for", "screen flow".
Do NOT fire on: