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
- 01Start with user experience flows
- 02Separate current and desired flows
- 03Clarify architecture and side-effect ownership
- 04Attach function, file, and test anchors
- 05List decisions and open questions
Use cases
- 01Plan architecture for a new feature
- 02Analyze existing flows and define target behavior
- 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-planAfter installing, type/ux-flow-planin Claude Code to confirm it loaded.
Details
From the project READMEUX Flow Plan
Create a high-level architecture plan that starts from the user experience and only then maps to code-level anchors.
Steps
-
Restate the feature goal in product terms, using the user's language.
-
Build the current-state UX flow as a tree:
User action └─ System behavior └─ Existing architectural layer └─ Relevant function/file anchor -
Build the desired-state UX flow as a second tree:
User action └─ System behavior └─ New or changed architectural layer └─ Relevant function/file anchor -
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
-
Attach implementation anchors after the trees, not before:
- Function names
- File paths
- Existing abstractions to reuse
- Tests that should cover the flow
-
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.