skills/ux-screen-requirements/SKILL.md
Phase 5 of Sketch the Solution. Define goals and ABC requirements for every screen. Use when asked to 'screen requirements', 'screen specs', 'define screens', or 'screen goals'.
npx skillsauth add arndvs/ctrlshft ux-screen-requirementsInstall 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 Screen Requirements skill." to chat to acknowledge you read this file.
Pipeline position: /ux-user-stories → /ux-system-map → /ux-flow-diagram → /ux-model-attributes → /ux-screen-requirements → /ux-interface-design → /ux-test-driven-design
Goals for each screen in a flow diagram. The purpose is to get a user to the next phase in UX.
Define what every screen must contain so users know: where they are, what they can do, and where they can go. This is the hand-off document for UI designers.
flow-diagram.md from Phase 3 (screen list and navigation paths)attributes.md from Phase 4 (data attributes per entity)system-map.md from Phase 2Invoke /ux-create-screen-goals
Define 1-2 primary goals for each screen in the flow diagram.
Invoke /ux-inform-engage-invite
Structure each screen's intent: inform the user (trust, context), engage them (show value), invite them forward (CTA).
Invoke /ux-list-screen-attributes
For each screen define: A) what the user gets, B) what they can do, C) how they navigate next.
Generate screen-requirements.md containing:
After completion, offer:
/ux-interface-design — proceed to Phase 6/sketch-the-solution — return to orchestratorIf context is high, follow the standard handoff protocol (@~/dotfiles/instructions/handoff.instructions.md).
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.