screen-design-rules

Applies visual and usability rules when writing or reviewing application screen markup.

1|Updated Jun 25, 2026
One-click install
npx skills add https://github.com/IgorAIvanov/altera03 --skill screen-design-rules-igoraivanov
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: screen-design-rules
Source: https://github.com/IgorAIvanov/altera03/tree/main/skills/src/screen-design-rules
Command: npx skills add https://github.com/IgorAIvanov/altera03 --skill screen-design-rules-igoraivanov

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Dense accounting desktop screens get degraded by generic UI advice written for marketing sites and mobile apps — oversized controls, hand-picked colours, full-width fields, and footer action bars that scroll out of view. This Skill supplies the concrete rules that hold for this application so screens stay dense, readable, and consistent with the framework theme. ## Core Features & Use Cases - Theme-token enforcement: mandates theme variables and .text-muted instead of hex literals or low-contrast opacity utilities, with contrast ratios cited for each rule. - Layout and form conventions: covers density, field widths, disabled vs read-only states, the renderForm() frame with top command panel, right-side filter panels, and self-explaining empty states. - Icon and accessibility rules: requires glyphs from the ui-kit icon set (catalogued in the bundled icons.md reference), SVG sizes in attributes, named icon-only buttons, and keyboard-reachable actions. - Use Case: When writing a new invoice edit form, apply the rules to compose fields via renderForm, size the code field to its content, place Save and Print in the top command panel with icons from the set, and verify the done-checklist before shipping. ## Quick Start Ask the assistant to review the markup of the form or list screen you are writing against the screen design rules before adding any colour, size, or spacing of your own.

Frequently Asked Questions about screen-design-rules

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

FAQPage Schema
How do I style secondary text in a form without breaking contrast?

Use the `.text-muted` class for secondary text such as codes, dates, hints, and empty states. Opacity utilities like `text-base-content/50` render at 2.8:1 contrast, well below the 4.5:1 AA floor, while `.text-muted` is a token chosen to pass on white, zebra stripes, and hover rows.

How should I lay out an edit form with many fields?

Return `this.renderForm(fields)` from `render()` instead of composing the layout by hand. The base places the command panel at the top, makes the field area the scrolling region, and lets you add buttons via `renderActions()` and `renderAuxActions()`.

Can I use Tailwind classes to size SVG icons in shadow DOM?

No. Icons live inside shadow DOM, so Tailwind classes like `h-4 w-4` may never be generated there. Put sizes in the SVG's own `width` and `height` attributes, and prefer glyphs from the ui-kit icon set over hand-written SVG.

What is the difference between disabled buttons and disabled fields for contrast?

A disabled button label may drop to 3:1 contrast since nobody needs to read it, but a disabled field's value must stay at 4.5:1 or higher because users open view mode precisely to read it. Never use `opacity` to indicate disabled state on anything containing text.

Why should filters go in a side panel instead of above the table?

Filters in an accounting list are long-lived, and a control strip above the grid permanently consumes the vertical height a dense table needs. The base classes already place filters in a right-hand collapsible panel, so no custom layout is required.

When is it acceptable to skip renderForm and build a custom layout?

A screen with a genuinely different layout may simply not call `renderForm()` and build its own `render()` method. The base provides a default frame but does not forbid custom composition for screens that do not fit the standard form pattern.