Agent Skills › trycompai/crm › ux-flow-plan

ux-flow-plan

GitHub

创建以用户体验为核心的架构规划，先构建用户流程树，再映射代码锚点。明确架构边界决策，区分当前与期望状态，辅助开发前理清逻辑与实现细节。

.agents/skills/ux-flow-plan/SKILL.md trycompai/crm

Trigger Scenarios

需要制定功能架构方案梳理复杂业务的用户交互流程在编码前进行系统设计

Install

npx skills add trycompai/crm --skill ux-flow-plan -g -y

More Options

Non-standard path

npx skills add https://github.com/trycompai/crm/tree/release/.agents/skills/ux-flow-plan -g -y

Use without installing

npx skills use trycompai/crm@ux-flow-plan

指定 Agent (Claude Code)

npx skills add trycompai/crm --skill ux-flow-plan -a claude-code -g -y

安装 repo 全部 skill

npx skills add trycompai/crm --all -g -y

预览 repo 内 skill

npx skills add trycompai/crm --list

SKILL.md

Frontmatter

{
    "name": "ux-flow-plan",
    "description": "Create UX-first plans as flow trees, then attach concrete function names, files, and implementation anchors after the high-level flow is clear.",
    "user-invocable": true
}

UX 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.