docs(webkit): ship the webkit-lists skill — the index page and its filter system

[gabriel-lisboa-azion]

Why

Every list page in a product is the same page, and every one of them gets rebuilt by whoever needed it. In our own sample app, six surfaces narrowed six different ways: a chip bar on one, a badged funnel of Selects on four more, three width-tuned Selects in a row on another, and the table's own field/operator/value builder on Billing — whose operator column offered is one of on every row, a control with one option.

/webkit-tables already fixes what happens inside the Table. Nothing fixed the page around it.

What the skill fixes

1. The page skeleton — shell → column → parent section → one band holding the controls row, the filter bar and the card-wrapped table. The most common way this page is built wrong is putting a full section step between the search and the rows it filters; they are not three things stacked on a page, they are one thing.
2. Search vs filters — search runs inside the table (v-model:globalFilter); filters narrow :data from outside it. With the reason: a field is often not a column at all (an author who renders inside a Last Modified cell), and the table's applied-filter band only exists once a filter exists, so the affordance that starts filtering has nowhere to live inside the table.
3. Which columns become fields — enumerable column → one field; date column → relative periods plus Custom…; free-text column → nothing, the search covers it; magnitude → nothing, because a field over it offers one option per row.
4. The applied state — { fieldId: values[] }, flat, arrays, empty means absent. Fields intersect, values inside a field union. Count fields, not values: three authors is one filter on Author, and reading "3" suggests three columns are cut when only one is.
5. The bar composition — one Popover anchor walking fields then values, Chip kind="dashed" as the trigger, filled / outlined per field, chips in catalog order and never reordered.
6. The pagination rewind — filtering :data from outside does not trip TanStack's autoResetPageIndex, so a narrowed list lands on an empty page offset.

Scope

scope: general — it ships to consuming projects. There is deliberately no @aziontech/webkit/filter-bar: the field catalog and its match functions are the consumer's data, so a package component would take them as props anyway and you would own the same file with more indirection. The skill teaches the composition from Popover + Chip instead, the way /webkit-navigation teaches the two app shells.

Registration

The four registries a consumer skill touches: CLAUDE_BUNDLE in src/cli/plan.js, the copy-list assertion in test/cli/plan.test.mjs, the Skills section of CLAUDE.fragment.md, and webkit-ui-craft (description, review chain, progression table).

Verification

validate-authoring-docs exits 0 · check-authoring-docs ratchet reports 0 new violations · plan.test.mjs + invariant.test.mjs 33/33, including the two that matter here — every skill declares a non-empty enforced_by, and every entry resolves to a rule of its own population.