role-based-cabinet-ux

Designs and validates role-based cabinet UX for multi-role CRM and marketplace systems.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill role-based-cabinet-ux-tech-hy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: role-based-cabinet-ux
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/role-based-cabinet-ux
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill role-based-cabinet-ux-tech-hy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams building CRM or marketplace cabinets often split one person into duplicate accounts per role, leak internal operator data to members, or hide critical status blockers. This Skill provides a structured workflow to design cabinet UX where one canonical identity holds multiple roles with safe visibility boundaries. ## Core Features & Use Cases - Role Capability Matrix: Map capabilities and visibility boundaries for investor, seller, operator, moderator, and admin roles using a canonical single-identity model. - Role Journeys & Status Design: Build step-by-step journeys per role and merge them into one cabinet surface with explicit status, safe explanation, next action, and last-updated blocks. - Anti-Pattern Validation: Check designs against common failures such as duplicate accounts per role, raw payload exposure on member endpoints, and unexplained disabled states. - Use Case: When designing a marketplace where a user can be both investor and seller, use this Skill to define one account with role-aware modules, safe access-request statuses, and role-by-role QA evidence. ## Quick Start Ask the AI to design the cabinet UX for a marketplace where one user can be both investor and seller, using the role matrix, journeys, and anti-pattern references.

Frequently Asked Questions about role-based-cabinet-ux

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a cabinet UX for users with multiple roles?

Use one canonical identity and attach roles as capabilities rather than creating separate accounts. Map capabilities per role first, build journeys per role, then merge overlapping flows into a single cabinet surface with role-aware modules.

How to handle investor and seller roles in one marketplace account?

Keep a single account and let the user switch context or modules instead of accounts. The role matrix defines which capabilities and status modules each role sees, such as access requests for investors and listing freshness for sellers.

What status information should a member cabinet show?

Each critical process needs current status, a safe explanation, the next action, and a last-updated timestamp. Internal operator reason text must never appear on member or public surfaces unless explicitly safe-translated.

What are common anti-patterns in role-based account design?

Common failures include duplicate accounts per role, using URL contact IDs as authority, leaking raw model payloads to member endpoints, hiding blocked reasons behind generic failure text, and skipping role-specific UAT.

When should internal operator data be hidden from members?

Internal decision context, operator comments, and reason codes are visible only to operator and admin roles by permission. Members see only safe status summaries and guidance, and public users see only published public-safe listing data.