What problem does it solve? List screens built with ad-hoc markup drift from the shared design system: skeletons, empty states, sorting, pagination, and row actions get reimplemented inconsistently across sections. This rule defines exactly how a list screen must be assembled from the shared kit components so every section behaves identically. ## Core Features & Use Cases - Assembly contract: Mandates that pages come from the shared list-page component, mechanics from the shared list-screen base, and tables from rt-table with [dataSource] — never custom markup. - Sort, filter, and row-action rules: Sortable headers name server fields, action availability lives in row fields, unavailable actions are hidden rather than disabled, and loading failures surface as toasts. - Tree-specific bindings: The companion implementation.md maps every rule article to concrete files such as admin-list-page.component.ts, AdminListScreenBase, and the ADMIN_LIST_HOST token. - Use Case: When editing a screen under libs/admin/*/feature/list or the kit table/pagination, load this rule to know the block order, where the query state lives, and what the kit already provides before writing any markup. ## Quick Start Load the lists rule before editing any list screen under libs/admin feature folders and follow its assembly contract for the table, toolbar, and pagination.