@tamsensedev/runner 0.10.0 → 0.18.0

package/library/skills/app-screens/references/tables-forms-settings.md

@@ -1,104 +1,104 @@
-# Tables, lists, forms and settings
-
-Read this when building a table, a data list, a form or a settings view. Numbers are defaults; the project's existing table, form and settings components win, and a sibling screen's patterns should be reused exactly.
-
-## Tables
-
-**Rows**
-
-- Single-line data rows 40 to 48px (dense tools 32 to 36px). Two-line rows with media 56 to 72px: media height plus 24 to 32px.
-- Line two of a cell sits about 20px below line one, one size smaller (12 to 13px) and muted. Two-line rows need at least a 40px pitch or the subline touches the next row.
-- Key-value rows inside cards 24 to 32px. Overview lists show 2 to 6 rows.
-
-**Header**
-
-- 12px (11 to 14), regular or medium weight, muted, sentence case. Uppercase tracked headers read louder than the data; use them only if the project does.
-- No fill band. A rule under the header only if it is the strongest line in the table.
-- Header row 36 to 40px. Numeric headers right-aligned and flush with their values. A sort glyph on the active column only.
-
-**Dividers**
-
-- No zebra striping.
-- Row rules 1px, 3 to 7% darker than the surface (about #efefef to #f4f4f4 on white), or none with a generous pitch.
-- One extent per screen: full inner width, or starting at the text column.
-
-**Figures and alignment**
-
-- Numbers right-aligned in tabular figures. Fixed decimals per metric: money 2, percentages 1 or 2, counts 0. Thousands separators everywhere; abbreviate (12.7k) only where precision does not matter. A sign on every change. Format with `Intl.NumberFormat` and `Intl.DateTimeFormat` in the user's locale.
-- The identity column (name, title) gets the most width, a third to a half, and is never the one cut off. Shorten names consistently rather than truncating them at random widths.
-- One right edge per row: every right-aligned figure ends on the same line.
-- Two measures can stack in one cell (a count over its percentage, a date over its time) on one right edge, instead of taking two columns.
-- Dates: ISO-like and right-aligned where rows are compared; relative ("Today", "6 days ago") for recency, switching to an absolute date after about a week.
-- IDs in monospace at body size, truncated in the middle or to about 8 characters, with a copy button.
-- Truncate to one line with an ellipsis and a way to see the full value (title attribute, tooltip, detail view). Never truncate numbers, amounts or dates.
-
-**Ink inside rows**
-
-- Only the identity and the key number in the primary text colour; everything else muted.
-- A missing value is a muted dash; a real zero is printed ("0", "$0.00").
-- The sign carries meaning, not colour: no red on every negative amount. Colour only rows that need attention.
-- Link colour on the name cell only.
-
-**Status pills**
-
-- 20 to 24px tall, 12px text at 500, nothing under 11px.
-- Pale tint with dark text of the same hue (for example #dcfae5 with #04250e, #ffedea with #831c1e); optionally a 1px border one step darker.
-- Neutral states as monochrome chips. A saturated fill with white text only for the rare state that needs action, and not when more than about a fifth of visible rows carry it.
-- One status mark per row. Pills never shrink: `flex: none; white-space: nowrap`.
-
-**Media in rows**: 16px logos in dense rows, 24 to 32px avatars, 40 to 48px in two-line rows. Circles for people, small radius for artwork. One fixed media slot so text starts on one edge, 10 to 16px gap.
-
-**Actions and paging**
-
-- No pagination on an overview. Cap the rows, state the total, link "View all".
-- Row actions: none, or one menu button at the far right. When most rows need an action (an order to pack, a failed deploy to retry), put a visible ghost button or text action in one trailing column at the same position on every row.
-- Checkboxes only when bulk actions exist.
-- Hover: a subtle background change at most; selected row in a master-detail list takes the same fill as the active nav item, so it cannot be confused with focus.
-- Toolbar: one search field 32 to 36px tall.
-- **Full list screen**: total above the table ("1,284 orders"), sticky header row, paging or load more with the range ("1 to 50 of 1,284"), filters and sort reflected in the URL.
-
-**Large lists**: over about 50 to 100 rendered rows, paginate or virtualize; say which.
-
-## Lists that carry data
-
-- Ranked list with one figure: the row's background fill can be the bar (its width the share of the largest). Only in one-figure lists; otherwise the fill cuts through text.
-- Bar list: label line, then a thin bar (2 to 10px) with the value after its end; one colour, longest bar about 88% of the width.
-- Inline bars in a list are thin and muted unless they are the screen's main series.
-- Legend as table: dot, name, value and change on one row.
-- Feed: row cards about 64px tall with a relative date on the right.
-- Tree: no dividers, 8 to 16px indent per level, about 30px pitch.
-
-## Forms
-
-- **Label above the field**, 14px at 500, 6 to 8px gap. No floating labels, no placeholder standing in for a label. Placeholders show an example value.
-- Inputs 36 to 40px in forms (44px on phones), radius from the project's control radius. One control height per context.
-- Inputs keep their own background and a 1px border one step stronger than card borders, with a visible focus ring.
-- Spacing: about 24px from a section description to the first label, 16px between fields, 24px before the submit row.
-- Field width hints at the expected input (a postcode field is short). One column for most forms; two columns only for pairs that belong together (first and last name).
-- Required and optional marked consistently; mark the minority.
-- Validation inline next to the field on blur or submit, focusing the first error on submit; keep what was typed. Server errors appear at the field they concern when possible, otherwise above the form.
-- Submit stays enabled until the request starts, then shows progress and prevents double submission.
-- Toggles 28 x 16 to 36 x 20; the on colour a success green or near-black, not the brand accent by default. A toggle saves immediately; a checkbox waits for Save.
-- Disabled controls stay readable (not 30% opacity) and say why they are disabled.
-- A read-only value with an action (a link with Copy) can share one border with squared inner corners.
-- Warn before leaving with unsaved changes.
-
-## Settings
-
-- Each area (General, Members, Billing, Notifications) is its own view with its name as the `h1`, not one long page scrolled by anchors.
-- A section is a row: a label column (about 280 to 450px: 16px/500 title and a 14px muted description) beside a panel (about 600 to 700px). Stack them below about 900px.
-- Sections split by a full-width 1px rule with 32px above and below, or by space alone.
-- Switch row: title, optional status badge, muted description, toggle on the right, vertically centred on the title line.
-- **One save model per view**: either every control saves itself with a quiet "Saved" confirmation, or one Save button per panel at its bottom right. Never a mix.
-- **Show what the setting produces**: a small preview of the result (the invite email, the notification) beside the control is the most useful thing a settings screen can add.
-- Plan-gated features: a slim notice with an upgrade button above the locked panel; the panel stays readable.
-- **Destructive actions** go last, in their own section, as an outlined or text button in the danger colour, with the consequence in words and a confirmation that names the object (typing the name for irreversible deletes). Prefer undo when recovery is possible.
-
-## Buttons
-
-- Height 32 to 36px desktop (28 in dense toolbars), 44px on phones. Radius from the project scale.
-- One filled primary per screen or panel. Secondary: outlined or tonal. Tertiary: text.
-- Controls in one row share one height.
-- Label is a verb and object in sentence case. Icon-only buttons need an accessible name and a tooltip.
-
-Sources: adapted from Leonxlnx/taste-skill references/app-screens.md sections 7 to 8 (MIT, changed: condensed, defaults placed under the project's system, house bans relaxed where products commonly differ).
+# Tables, lists, forms and settings
+
+Read this when building a table, a data list, a form or a settings view. Numbers are defaults; the project's existing table, form and settings components win, and a sibling screen's patterns should be reused exactly.
+
+## Tables
+
+**Rows**
+
+- Single-line data rows 40 to 48px (dense tools 32 to 36px). Two-line rows with media 56 to 72px: media height plus 24 to 32px.
+- Line two of a cell sits about 20px below line one, one size smaller (12 to 13px) and muted. Two-line rows need at least a 40px pitch or the subline touches the next row.
+- Key-value rows inside cards 24 to 32px. Overview lists show 2 to 6 rows.
+
+**Header**
+
+- 12px (11 to 14), regular or medium weight, muted, sentence case. Uppercase tracked headers read louder than the data; use them only if the project does.
+- No fill band. A rule under the header only if it is the strongest line in the table.
+- Header row 36 to 40px. Numeric headers right-aligned and flush with their values. A sort glyph on the active column only.
+
+**Dividers**
+
+- No zebra striping.
+- Row rules 1px, 3 to 7% darker than the surface (about #efefef to #f4f4f4 on white), or none with a generous pitch.
+- One extent per screen: full inner width, or starting at the text column.
+
+**Figures and alignment**
+
+- Numbers right-aligned in tabular figures. Fixed decimals per metric: money 2, percentages 1 or 2, counts 0. Thousands separators everywhere; abbreviate (12.7k) only where precision does not matter. A sign on every change. Format with `Intl.NumberFormat` and `Intl.DateTimeFormat` in the user's locale.
+- The identity column (name, title) gets the most width, a third to a half, and is never the one cut off. Shorten names consistently rather than truncating them at random widths.
+- One right edge per row: every right-aligned figure ends on the same line.
+- Two measures can stack in one cell (a count over its percentage, a date over its time) on one right edge, instead of taking two columns.
+- Dates: ISO-like and right-aligned where rows are compared; relative ("Today", "6 days ago") for recency, switching to an absolute date after about a week.
+- IDs in monospace at body size, truncated in the middle or to about 8 characters, with a copy button.
+- Truncate to one line with an ellipsis and a way to see the full value (title attribute, tooltip, detail view). Never truncate numbers, amounts or dates.
+
+**Ink inside rows**
+
+- Only the identity and the key number in the primary text colour; everything else muted.
+- A missing value is a muted dash; a real zero is printed ("0", "$0.00").
+- The sign carries meaning, not colour: no red on every negative amount. Colour only rows that need attention.
+- Link colour on the name cell only.
+
+**Status pills**
+
+- 20 to 24px tall, 12px text at 500, nothing under 11px.
+- Pale tint with dark text of the same hue (for example #dcfae5 with #04250e, #ffedea with #831c1e); optionally a 1px border one step darker.
+- Neutral states as monochrome chips. A saturated fill with white text only for the rare state that needs action, and not when more than about a fifth of visible rows carry it.
+- One status mark per row. Pills never shrink: `flex: none; white-space: nowrap`.
+
+**Media in rows**: 16px logos in dense rows, 24 to 32px avatars, 40 to 48px in two-line rows. Circles for people, small radius for artwork. One fixed media slot so text starts on one edge, 10 to 16px gap.
+
+**Actions and paging**
+
+- No pagination on an overview. Cap the rows, state the total, link "View all".
+- Row actions: none, or one menu button at the far right. When most rows need an action (an order to pack, a failed deploy to retry), put a visible ghost button or text action in one trailing column at the same position on every row.
+- Checkboxes only when bulk actions exist.
+- Hover: a subtle background change at most; selected row in a master-detail list takes the same fill as the active nav item, so it cannot be confused with focus.
+- Toolbar: one search field 32 to 36px tall.
+- **Full list screen**: total above the table ("1,284 orders"), sticky header row, paging or load more with the range ("1 to 50 of 1,284"), filters and sort reflected in the URL.
+
+**Large lists**: over about 50 to 100 rendered rows, paginate or virtualize; say which.
+
+## Lists that carry data
+
+- Ranked list with one figure: the row's background fill can be the bar (its width the share of the largest). Only in one-figure lists; otherwise the fill cuts through text.
+- Bar list: label line, then a thin bar (2 to 10px) with the value after its end; one colour, longest bar about 88% of the width.
+- Inline bars in a list are thin and muted unless they are the screen's main series.
+- Legend as table: dot, name, value and change on one row.
+- Feed: row cards about 64px tall with a relative date on the right.
+- Tree: no dividers, 8 to 16px indent per level, about 30px pitch.
+
+## Forms
+
+- **Label above the field**, 14px at 500, 6 to 8px gap. No floating labels, no placeholder standing in for a label. Placeholders show an example value.
+- Inputs 36 to 40px in forms (44px on phones), radius from the project's control radius. One control height per context.
+- Inputs keep their own background and a 1px border one step stronger than card borders, with a visible focus ring.
+- Spacing: about 24px from a section description to the first label, 16px between fields, 24px before the submit row.
+- Field width hints at the expected input (a postcode field is short). One column for most forms; two columns only for pairs that belong together (first and last name).
+- Required and optional marked consistently; mark the minority.
+- Validation inline next to the field on blur or submit, focusing the first error on submit; keep what was typed. Server errors appear at the field they concern when possible, otherwise above the form.
+- Submit stays enabled until the request starts, then shows progress and prevents double submission.
+- Toggles 28 x 16 to 36 x 20; the on colour a success green or near-black, not the brand accent by default. A toggle saves immediately; a checkbox waits for Save.
+- Disabled controls stay readable (not 30% opacity) and say why they are disabled.
+- A read-only value with an action (a link with Copy) can share one border with squared inner corners.
+- Warn before leaving with unsaved changes.
+
+## Settings
+
+- Each area (General, Members, Billing, Notifications) is its own view with its name as the `h1`, not one long page scrolled by anchors.
+- A section is a row: a label column (about 280 to 450px: 16px/500 title and a 14px muted description) beside a panel (about 600 to 700px). Stack them below about 900px.
+- Sections split by a full-width 1px rule with 32px above and below, or by space alone.
+- Switch row: title, optional status badge, muted description, toggle on the right, vertically centred on the title line.
+- **One save model per view**: either every control saves itself with a quiet "Saved" confirmation, or one Save button per panel at its bottom right. Never a mix.
+- **Show what the setting produces**: a small preview of the result (the invite email, the notification) beside the control is the most useful thing a settings screen can add.
+- Plan-gated features: a slim notice with an upgrade button above the locked panel; the panel stays readable.
+- **Destructive actions** go last, in their own section, as an outlined or text button in the danger colour, with the consequence in words and a confirmation that names the object (typing the name for irreversible deletes). Prefer undo when recovery is possible.
+
+## Buttons
+
+- Height 32 to 36px desktop (28 in dense toolbars), 44px on phones. Radius from the project scale.
+- One filled primary per screen or panel. Secondary: outlined or tonal. Tertiary: text.
+- Controls in one row share one height.
+- Label is a verb and object in sentence case. Icon-only buttons need an accessible name and a tooltip.
+
+Sources: adapted from Leonxlnx/taste-skill references/app-screens.md sections 7 to 8 (MIT, changed: condensed, defaults placed under the project's system, house bans relaxed where products commonly differ).

package/library/skills/avoiding-generic-ai-design/SKILL.md

@@ -1,92 +1,92 @@
----
-name: avoiding-generic-ai-design
-description: Use before finishing any new or restyled UI, when a task says a design looks generic, templated or AI-made, or when reviewing UI for that. Lists the dated patterns that make interfaces read as generated, what to do instead, and why the project's own design system always overrides this list.
----
-
-# Avoiding the generic AI look
-
-Generated interfaces look alike because they are built from the same defaults: a violet gradient, a tiny uppercase label over every heading, three identical icon cards, a big number with a green "+12%", a soft shadow under everything. None of it is wrong on its own; it reads as generated because it appears everywhere, without a reason. This skill helps you notice those defaults and replace them with decisions.
-
-## This list never overrides the project
-
-- If the project's DESIGN.md, tokens, component library or existing screens use a pattern listed here (eyebrow labels, monospace numbers, pill badges, hairline tables, a violet brand), it is the product's decision. Use it consistently. Do not "fix" it.
-- If the task explicitly asks for one of these looks, build it.
-- The list applies where a choice is free: a new product, a new surface with no precedent, or your own additions inside an existing look.
-
-A bold, motivated choice is not a tell. When unsure whether something is a default or a decision, treat it as a decision and leave it.
-
-## How to use it
-
-### While planning
-
-Before building a new surface, write down the three defaults you would reach for without thinking (for example: KPI cards with icons, an area chart with a gradient, a zebra table). Then decide what replaces each, based on the content and the job of the screen. You cannot avoid a pattern you have not named.
-
-### Pass 1: look at the render (the patterns that matter most)
-
-Take screenshots (see `design-review`) and look at the whole screen before any detail. These compositional failures are invisible in a diff and do the most damage:
-
-1. **No focal point.** Everything competes; the eye lands nowhere. Make the one thing the screen is for dominate and demote the rest.
-2. **Flat hierarchy.** Title, body and metadata are one size, weight and colour. Build tiers from weight and a text-colour ramp, not size alone.
-3. **Monotone layout.** Same card, same gap, same density edge to edge. Group by meaning, vary density by zone, size blocks by their content.
-4. **Timid or smeared colour.** One accent on everything, or five low-commitment tints. One accent for action, selection and meaning; neutrals for structure.
-5. **The template order.** Hero, logos, three features, testimonial, pricing, call to action; or KPI row, big chart, two small charts, table. Order blocks by the questions the person actually has.
-6. **Could belong to anyone.** Cover the product name: would the screen work for a competitor or another industry? Bring in the product's real objects, data and words.
-
-### Pass 2: scan your changes (line-level patterns)
-
-Read your diff for the specific patterns in [references/tells.md](references/tells.md). The most common ones:
-
-- Gradient text, gradient buttons, violet or indigo gradient washes, glow shadows, decorative glass and backdrop blur.
-- A small tracked uppercase label (eyebrow) above every heading; a pill badge ("New", "Beta") above a hero headline.
-- Rows of identical cards with an icon in a tinted circle or rounded square on top.
-- A hero metric template: big number, small label, a green delta, a sparkline.
-- A coloured `border-left` stripe on cards, callouts or list items.
-- One medium radius (12 to 16px) and the same soft grey shadow on every element.
-- Emoji or Unicode symbols as icons; mixed icon sets.
-- Monospace used as a "technical" costume for labels rather than for code, IDs or data.
-- Numbered markers (01 / 02 / 03) on content that is not a sequence.
-- Fade-and-rise on every section; hover lift on every card; bounce easing.
-- The warm cream background with a terracotta or clay accent and a serif display; near-black with one acid-green accent.
-- Generic copy: "Unlock", "Seamless", "Supercharge", "Welcome back" with a waving hand.
-
-### Pass 3: fill the gap with substance, not ornament
-
-Removing devices and putting nothing in their place produces an empty page with good manners, which is a tell of its own. Fill the space with:
-
-- the product's real data, objects, names and words;
-- the full content each section needs, at a readable size;
-- scale: make the one important thing larger;
-- a single element that only this product has (see `interface-design` for the fresh-direction process).
-
-Never refill a gap with another ornament.
-
-## Honest content
-
-The most common failure in tests of AI-built UI is invented proof. Never invent:
-
-- metrics, growth figures, user counts or ratings;
-- customer names, logos, testimonials or quotes;
-- prices, plan limits or benchmarks the task did not give.
-
-Use the task's real content. Where it is missing, use neutral placeholders or sample data that is plainly sample ("Example Ltd", "Sample invoice"), computed consistently (totals add up), and list every placeholder in the report so it gets replaced.
-
-## What is not a problem
-
-- Patterns the project already uses (see the top of this skill).
-- Familiar product patterns that help people work: a sidebar with labelled nav, standard tables, tabs, a command palette. App screens should feel familiar; strangeness without purpose is worse than a known pattern done well.
-- One deliberate use of a listed device with a reason you can state in one sentence (a real step-by-step process may be numbered; IDs belong in monospace).
-- Anything outside the lines your change touched.
-
-## Done when
-
-- The render passes the six questions in Pass 1.
-- Your diff adds none of the listed patterns unless the project or the task called for them, and each exception has a one-line reason in the report.
-- No invented proof; placeholders are listed.
-
-## Report or review output
-
-In a code step, mention in the report any listed pattern you kept on purpose and why. In a review, list findings as: the pattern, where it shows (screenshot and `file:line`), why it reads as generated or costs the user, and the specific replacement. Taste alone is not a finding: if the choice is coherent with the product and executed well, leave it.
-
-Related: `interface-design`, `app-screens`, `design-review`.
-
-Sources: adapted from Leonxlnx/taste-skill tells and copy references (MIT), Dammyjay93/interface-design design-deslop (MIT), pbakaus/impeccable craft-floor refuse list (Apache-2.0, changed: rewritten; bans turned into defaults that yield to the project) and the generated-design traits in the frontend-design skill of anthropics/claude-plugins-official (Apache-2.0, changed: condensed).
+---
+name: avoiding-generic-ai-design
+description: Use before finishing any new or restyled UI, when a task says a design looks generic, templated or AI-made, or when reviewing UI for that. Lists the dated patterns that make interfaces read as generated, what to do instead, and why the project's own design system always overrides this list.
+---
+
+# Avoiding the generic AI look
+
+Generated interfaces look alike because they are built from the same defaults: a violet gradient, a tiny uppercase label over every heading, three identical icon cards, a big number with a green "+12%", a soft shadow under everything. None of it is wrong on its own; it reads as generated because it appears everywhere, without a reason. This skill helps you notice those defaults and replace them with decisions.
+
+## This list never overrides the project
+
+- If the project's DESIGN.md, tokens, component library or existing screens use a pattern listed here (eyebrow labels, monospace numbers, pill badges, hairline tables, a violet brand), it is the product's decision. Use it consistently. Do not "fix" it.
+- If the task explicitly asks for one of these looks, build it.
+- The list applies where a choice is free: a new product, a new surface with no precedent, or your own additions inside an existing look.
+
+A bold, motivated choice is not a tell. When unsure whether something is a default or a decision, treat it as a decision and leave it.
+
+## How to use it
+
+### While planning
+
+Before building a new surface, write down the three defaults you would reach for without thinking (for example: KPI cards with icons, an area chart with a gradient, a zebra table). Then decide what replaces each, based on the content and the job of the screen. You cannot avoid a pattern you have not named.
+
+### Pass 1: look at the render (the patterns that matter most)
+
+Take screenshots (see `design-review`) and look at the whole screen before any detail. These compositional failures are invisible in a diff and do the most damage:
+
+1. **No focal point.** Everything competes; the eye lands nowhere. Make the one thing the screen is for dominate and demote the rest.
+2. **Flat hierarchy.** Title, body and metadata are one size, weight and colour. Build tiers from weight and a text-colour ramp, not size alone.
+3. **Monotone layout.** Same card, same gap, same density edge to edge. Group by meaning, vary density by zone, size blocks by their content.
+4. **Timid or smeared colour.** One accent on everything, or five low-commitment tints. One accent for action, selection and meaning; neutrals for structure.
+5. **The template order.** Hero, logos, three features, testimonial, pricing, call to action; or KPI row, big chart, two small charts, table. Order blocks by the questions the person actually has.
+6. **Could belong to anyone.** Cover the product name: would the screen work for a competitor or another industry? Bring in the product's real objects, data and words.
+
+### Pass 2: scan your changes (line-level patterns)
+
+Read your diff for the specific patterns in [references/tells.md](references/tells.md). The most common ones:
+
+- Gradient text, gradient buttons, violet or indigo gradient washes, glow shadows, decorative glass and backdrop blur.
+- A small tracked uppercase label (eyebrow) above every heading; a pill badge ("New", "Beta") above a hero headline.
+- Rows of identical cards with an icon in a tinted circle or rounded square on top.
+- A hero metric template: big number, small label, a green delta, a sparkline.
+- A coloured `border-left` stripe on cards, callouts or list items.
+- One medium radius (12 to 16px) and the same soft grey shadow on every element.
+- Emoji or Unicode symbols as icons; mixed icon sets.
+- Monospace used as a "technical" costume for labels rather than for code, IDs or data.
+- Numbered markers (01 / 02 / 03) on content that is not a sequence.
+- Fade-and-rise on every section; hover lift on every card; bounce easing.
+- The warm cream background with a terracotta or clay accent and a serif display; near-black with one acid-green accent.
+- Generic copy: "Unlock", "Seamless", "Supercharge", "Welcome back" with a waving hand.
+
+### Pass 3: fill the gap with substance, not ornament
+
+Removing devices and putting nothing in their place produces an empty page with good manners, which is a tell of its own. Fill the space with:
+
+- the product's real data, objects, names and words;
+- the full content each section needs, at a readable size;
+- scale: make the one important thing larger;
+- a single element that only this product has (see `interface-design` for the fresh-direction process).
+
+Never refill a gap with another ornament.
+
+## Honest content
+
+The most common failure in tests of AI-built UI is invented proof. Never invent:
+
+- metrics, growth figures, user counts or ratings;
+- customer names, logos, testimonials or quotes;
+- prices, plan limits or benchmarks the task did not give.
+
+Use the task's real content. Where it is missing, use neutral placeholders or sample data that is plainly sample ("Example Ltd", "Sample invoice"), computed consistently (totals add up), and list every placeholder in the report so it gets replaced.
+
+## What is not a problem
+
+- Patterns the project already uses (see the top of this skill).
+- Familiar product patterns that help people work: a sidebar with labelled nav, standard tables, tabs, a command palette. App screens should feel familiar; strangeness without purpose is worse than a known pattern done well.
+- One deliberate use of a listed device with a reason you can state in one sentence (a real step-by-step process may be numbered; IDs belong in monospace).
+- Anything outside the lines your change touched.
+
+## Done when
+
+- The render passes the six questions in Pass 1.
+- Your diff adds none of the listed patterns unless the project or the task called for them, and each exception has a one-line reason in the report.
+- No invented proof; placeholders are listed.
+
+## Report or review output
+
+In a code step, mention in the report any listed pattern you kept on purpose and why. In a review, list findings as: the pattern, where it shows (screenshot and `file:line`), why it reads as generated or costs the user, and the specific replacement. Taste alone is not a finding: if the choice is coherent with the product and executed well, leave it.
+
+Related: `interface-design`, `app-screens`, `design-review`.
+
+Sources: adapted from Leonxlnx/taste-skill tells and copy references (MIT), Dammyjay93/interface-design design-deslop (MIT), pbakaus/impeccable craft-floor refuse list (Apache-2.0, changed: rewritten; bans turned into defaults that yield to the project) and the generated-design traits in the frontend-design skill of anthropics/claude-plugins-official (Apache-2.0, changed: condensed).