mcpField
U
ux-flow-plan

ux-flow-plan

github.com/jnsahajDesign & UI106142 installsUpdated 3w ago
Repository

About ux-flow-plan

ux-flow-plan is a skill for producing high-level architecture plans, starting with user experience and system flows before mapping them to code anchors. It helps developers distinguish current and desired behavior and clarify boundaries, implementation decisions, and open questions.

Key features

  1. 01Start with user experience flows
  2. 02Separate current and desired flows
  3. 03Clarify architecture and side-effect ownership
  4. 04Attach function, file, and test anchors
  5. 05List decisions and open questions

Use cases

  1. 01Plan architecture for a new feature
  2. 02Analyze existing flows and define target behavior
  3. 03Clarify ownership of UI, persistence, and side effects

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jnsahaj/skills --skill ux-flow-plan

After installing, type/ux-flow-planin Claude Code to confirm it loaded.

Details

From the project README

UX Flow Plan

Create a high-level architecture plan that starts from the user experience and only then maps to code-level anchors.

Steps

  1. Restate the feature goal in product terms, using the user's language.

  2. Build the current-state UX flow as a tree:

    User action
    └─ System behavior
       └─ Existing architectural layer
          └─ Relevant function/file anchor
    
  3. Build the desired-state UX flow as a second tree:

    User action
    └─ System behavior
       └─ New or changed architectural layer
          └─ Relevant function/file anchor
    
  4. Identify the architectural boundary decisions:

    • Which layer detects the condition
    • Which layer owns side effects
    • Which layer updates UI/status
    • Which layer persists or mutates state
  5. Attach implementation anchors after the trees, not before:

    • Function names
    • File paths
    • Existing abstractions to reuse
    • Tests that should cover the flow
  6. End with a small decision list:

    • Recommended architecture
    • Alternatives rejected
    • Open questions or assumptions

Rules

  • Start with UX and system flow, not line numbers or code edits.
  • Use tree diagrams for flows whenever possible.
  • Keep function names and file paths attached as anchors, not as the main narrative.
  • Do not over-specify implementation details before the architectural boundary is clear.
  • Separate "current flow" from "desired flow".
  • Call out whether a feature is coupled to an existing concept or intentionally independent from it.
  • Prefer plain product and architecture language over framework-specific jargon unless the jargon names a real boundary.

Comments

Markdown supported