skills/ux-list-screen-attributes/SKILL.md
Step 5.3 of Sketch the Solution. Define ABC spec for each screen: what user gets, does, and how they navigate. Use when asked to 'screen attributes', 'ABC spec', 'screen requirements list', or 'what goes on each screen'.
npx skillsauth add arndvs/ctrlshft ux-list-screen-attributesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Output "Read UX List Screen Attributes skill." to chat to acknowledge you read this file.
Phase: /ux-screen-requirements → Step 3 of 3
For each screen, create a concrete specification: what the user gets (sees), what they can do (actions), and how they navigate to the next screen.
attributes.md and flow-diagram.md:### [Screen Name]
**A — What the user gets (sees/receives):**
- [e.g., "List of member snippets: avatar, name, skills, location"]
- [e.g., "Content preview: title, summary, author, date, tags"]
- [e.g., "Dashboard metrics: activity count, recent posts"]
**B — What the user can do (actions):**
- [e.g., "Search by keyword", "Filter by skill/location"]
- [e.g., "Sort by date/relevance", "Post new content"]
- [e.g., "Edit profile", "Delete content"]
**C — How they navigate next:**
- [e.g., "Click member → Member Profile"]
- [e.g., "Click content → View Content"]
- [e.g., "Navigation bar → Dashboard, Profile, Settings"]
Define snippets — condensed preview representations of entities in list views:
Prioritize within each section — most important items first. The most important action should be the most prominent on the screen.
Cross-reference against the system map — ensure every entity's CRUD operations have corresponding screen actions.
Append to screen-requirements.md: Per-screen ABC specification with prioritized attributes.
development
Use when implementing UI, checking dark/light mode, or validating animations — adds a visual feedback loop via browser screenshots so frontend changes are verified, not assumed.
development
Use when Claude Code sessions had many manual approval ("press 1") prompts or when auditing hook permissions; identifies which Bash commands required approval.
tools
Use after merging a PR or during periodic cleanup to archive plan-mode files by linking them to merged PRs.
testing
Use when stress-testing a plan against the project's domain model — grills the design, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise.