Skip to main content

ux-flow-plan

Create UX-first plans as flow trees, then attach concrete function names, files, and implementation anchors after the high-level flow is clear.

소스 정보

저장소
trycompai/crm
최근 소스 활동
2026년 8월 6일 07:09
감지된 SKILL.md 언어
영어
스타
11,861
포크
1,762

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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 1. Restate the feature goal in product terms, using the user's language. 2. Build the current-state UX flow as a tree: ```text User action └─ System behavior └─ Existing architectural layer └─ Relevant function/file anchor ``` 3. Build the desired-state UX flow as a second tree: ```text 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.
GitHub에서 보기