ss-flow
$
npx mdskill add bitjaru/styleseed/ss-flowDesign clear navigation flows using proven UX patterns.
- Creates structured user journeys with logical entry and exit points.
- Reads design system references and component inventories for context.
- Applies information architecture principles like progressive disclosure.
- Outputs flow maps that guide developers toward implementation.
SKILL.md
.github/skills/ss-flowView on GitHub ↗
--- name: ss-flow description: Design user flows and navigation structure following proven UX patterns argument-hint: [flow-name] [description] allowed-tools: Read, Write, Edit, Grep, Glob, Bash --- # UX Flow Designer ## When NOT to use - For implementing a single page → use `/ss-page` after the flow is settled - For copy on each step → use `/ss-copy` after the structure is settled - For information architecture of an entire product — narrow scope to one flow first - For high-fidelity mockups — this produces a flow map, not pixel-perfect designs Design a user flow: **$0** Description: $ARGUMENTS ## Instructions 1. Read the design system reference: - `CLAUDE.md` for component inventory - `DESIGN-LANGUAGE.md` for layout patterns (sections 13-14, 19-20) - `components/patterns/` for available building blocks 2. Apply these UX principles: ### Information Architecture - **Progressive Disclosure**: Show only what's needed at each step. Hide complexity behind logical drill-downs. - **Miller's Law**: Chunk information into groups of 5-9 items maximum. - **Hick's Law**: Minimize choices per screen. Fewer options = faster decisions. ### Navigation Patterns - **Hub & Spoke**: Dashboard → detail pages → back to dashboard (default for mobile apps) - **Linear Flow**: Step 1 → Step 2 → Step 3 (for forms, onboarding, checkout) - **Tab Navigation**: 3-5 top-level sections via BottomNav ### Screen Flow Rules - Every flow must have a **clear entry point** and **clear exit point** - Maximum **3 taps** to reach any key feature from the home screen - Back navigation must always be available (except root screens) - Error states must provide **recovery paths** (retry, go back, contact support) - Loading states must use skeleton screens (never spinners in cards) ### Page Composition (from DESIGN-LANGUAGE.md) - Follow the **Information Pyramid**: Hero → KPI Grid → Details → Lists - Each screen should answer ONE primary question - Above the fold: the most important metric or action - Use the 4 section types: Full Card (A), Grid (B), Carousel (C), Hero (D) 3. Output format: - **Flow diagram** in ASCII showing screen connections - **Screen inventory** listing each screen's purpose and key components - **Edge cases** (empty states, errors, loading) for each screen - **Scaffolded pages** using `PageShell`, `TopBar`, `BottomNav` patterns 4. Generate the actual page files using `/ss-page` conventions.
More from bitjaru/styleseed
- ss-a11yAudit a component or page for accessibility issues and fix them
- ss-auditAudit screens for UX issues using Nielsen's heuristics and modern mobile UX best practices
- ss-componentGenerate a new UI component following the StyleSeed design conventions
- ss-copyGenerate UX microcopy (button labels, error messages, empty states, toasts) following a casual-but-polite voice and tone
- ss-feedbackAdd appropriate user feedback states (loading, success, error, empty) to a component or page
- ss-lintQuick automated lint — detects common design system violations in seconds
- ss-motionApply a named StyleSeed motion to a component — either one of the 5 personality seeds (Spring/Silk/Snap/Float/Pulse × entrance/exit/hover/press/layout) or a distinctive keyword move from the motion library (toggle-flip, toggle-curtain, reveal-blur, pop-in, shimmer, …). Translates vibe words into framer-motion code from one source of truth.
- ss-pageScaffold a new mobile page/screen using the StyleSeed layout patterns
- ss-patternGenerate a composed UI pattern (card layout, list, form section, grid, etc.) using design system primitives
- ss-reviewReview UI code for design system compliance, accessibility, and best practices