diff --git a/.changes/user-interface/fix-11423-shape-and-css-triggers-7d3a91c2.md b/.changes/user-interface/fix-11423-shape-and-css-triggers-7d3a91c2.md new file mode 100644 index 00000000000..27a5e45fd80 --- /dev/null +++ b/.changes/user-interface/fix-11423-shape-and-css-triggers-7d3a91c2.md @@ -0,0 +1,7 @@ +--- +bump: patch +--- + +### Fixed + +- `/user-interface:design` now auto-invokes on questions about one visual value, such as what a nested element's corner radius or a layer's shadow should be, including questions that give every number. `/user-interface:write-css` lists fixing a layout in a stylesheet among its triggers. `probes/design.json` adds shape probes for the new trigger. diff --git a/plugins/user-interface/probes/design.json b/plugins/user-interface/probes/design.json index 43778ab1521..1bb6f0ff38a 100644 --- a/plugins/user-interface/probes/design.json +++ b/plugins/user-interface/probes/design.json @@ -2,7 +2,7 @@ "skill": "user-interface:design", "plugin": "user-interface", "skill_dir": "plugins/user-interface/skills/design", - "ranking_note": "Covers the component-api concern spoke, the design-system note, and the order of work. The pair is planning:design, which owns language-neutral types, contracts and module boundaries: a UI component's props API comes here, a non-UI contract goes there. The throwaway layout variants and the CSS writer could also take a component request. For the order of work, user-interface:audit takes a review of built UI and session-flow:recommend-skills a menu of every installed skill, while a question about which interface skill or concern to run for a screen comes here. user-interface:write-animation builds one animation, so a request to animate a menu (neg-train-06) goes there. The design-system note probes stand in for the candidate triggers DESIGN.md, document our components and agent invented a variant, which stay out of the description until a model-graded run shows they route here. Build-a-component probes (pos-*-build-*) cover the build triggers #11423 adds; competitors there are the same-plugin neighbors a UI request could reach (styling code, animation, review, naming, plugin settings) plus prototype:explore-directions.", + "ranking_note": "Covers the component-api concern spoke, the design-system note, and the order of work. The pair is planning:design, which owns language-neutral types, contracts and module boundaries: a UI component's props API comes here, a non-UI contract goes there. The throwaway layout variants and the CSS writer could also take a component request. For the order of work, user-interface:audit takes a review of built UI and session-flow:recommend-skills a menu of every installed skill, while a question about which interface skill or concern to run for a screen comes here. user-interface:write-animation builds one animation, so a request to animate a menu (neg-train-06) goes there. The design-system note probes stand in for the candidate triggers DESIGN.md, document our components and agent invented a variant, which stay out of the description until a model-graded run shows they route here. Build-a-component probes (pos-*-build-*) cover the build triggers #11423 adds; competitors there are the same-plugin neighbors a UI request could reach (styling code, animation, review, naming, plugin settings) plus prototype:explore-directions. Shape probes (pos-*-shape-*) ask what one radius or shadow should be, including a question that gives every number, which the model otherwise answers without loading the skill.", "competitors": [ "planning:design", "prototype:explore-directions", @@ -116,6 +116,18 @@ "expect_trigger": true, "request": "Should we write our own data grid with sorting and column resizing or pull in something like AG Grid or TanStack Table? We're on React with Tailwind." }, + { + "id": "pos-train-shape-01", + "split": "train", + "expect_trigger": true, + "request": "Our product tiles have 12px corners and the thumbnail image inside each one, inset by 8px, also has 12px corners. It looks slightly off but I can't say why. What should the thumbnail's corners be?" + }, + { + "id": "pos-train-shape-02", + "split": "train", + "expect_trigger": true, + "request": "Every surface in our admin app uses the same drop shadow, so the dropdown menu over a card doesn't look like it's floating above it. How should the shadows differ between the card and the menu?" + }, { "id": "neg-train-01", "split": "train", @@ -242,6 +254,12 @@ "expect_trigger": true, "request": "My Go CLI `syncctl status` currently dumps everything as one wall of text. I want it to show each remote as a row with a colored state (ok / drifting / failed), a summary line at the bottom, and degrade cleanly when piped or when NO_COLOR is set. How should the output be laid out?" }, + { + "id": "pos-validation-shape-01", + "split": "validation", + "expect_trigger": true, + "request": "On mobile our bottom sheet has big rounded top corners and a 1px hairline border, and the list rows inside it have their own rounded backgrounds. The edges where they meet look clumsy. What radius and border treatment would make them sit together?" + }, { "id": "neg-validation-01", "split": "validation", diff --git a/plugins/user-interface/skills/design/SKILL.md b/plugins/user-interface/skills/design/SKILL.md index d51a2559ee4..191c65c7496 100644 --- a/plugins/user-interface/skills/design/SKILL.md +++ b/plugins/user-interface/skills/design/SKILL.md @@ -1,5 +1,5 @@ --- -description: "Design and build anything a person or agent interacts with: web and app components, forms, screens and pages, CLI output, TUIs, prompt themes, PowerShell formatting, banners, Claude Code mods. Detects the project's own design system and the design tools installed, routes each concern to the best present source with the project first, and fills gaps with its own guidance. Use when asked to build a component or page in any stack, to choose between building a component and adopting a library, or to decide how something should look: 'build the checkout page in React', 'build or buy a date picker', 'design this CLI output', 'how should this TUI look', 'style this error message', 'when should my CLI use color', 'design a mod band', 'make this UI match our design system', 'which design tool should I use'. The CSS alone: /user-interface:write-css. Throwaway layout variants: /prototype:explore-directions." +description: "Design and build anything a person or agent interacts with: web and app components, forms, screens and pages, CLI output, TUIs, prompt themes, PowerShell formatting, banners, Claude Code mods. Detects the project's own design system and the design tools installed, routes each concern to the best present source with the project first, and fills gaps with its own guidance. Use when asked to build a component or page in any stack, to choose between building a component and adopting a library, or to decide how something should look, down to one corner radius or shadow, even with every number given: 'build the checkout page in React', 'build or buy a date picker', 'design this CLI output', 'how should this TUI look', 'style this error message', 'when should my CLI use color', 'design a mod band', 'make this UI match our design system', 'which design tool should I use'. The CSS alone: /user-interface:write-css. Throwaway layout variants: /prototype:explore-directions." argument-hint: "[what to design]" user-invocable: true disable-model-invocation: false diff --git a/plugins/user-interface/skills/write-css/SKILL.md b/plugins/user-interface/skills/write-css/SKILL.md index bf7fa5ada97..d7dc7a24bb6 100644 --- a/plugins/user-interface/skills/write-css/SKILL.md +++ b/plugins/user-interface/skills/write-css/SKILL.md @@ -1,5 +1,5 @@ --- -description: "Write and review CSS in any stack (stylesheets, utility classes, CSS-in-JS, scoped component styles) with modern techniques, after finding the project's tokens, browser targets, lint rules and conventions, which always win, and asking when no token fits instead of inventing one. Use when: 'write the CSS for', 'style this component', 'add a variant to this stylesheet', 'restyle this page', 'review this CSS'." +description: "Write and review CSS in any stack (stylesheets, utility classes, CSS-in-JS, scoped component styles) with modern techniques, after finding the project's tokens, browser targets, lint rules and conventions, which always win, and asking when no token fits instead of inventing one. Use when: 'write the CSS for', 'style this component', 'fix this layout in the stylesheet', 'add a variant to this stylesheet', 'restyle this page', 'review this CSS'." argument-hint: "[review] [--no-lint] [--show-suppressed] [--target ] [what to style or review]" user-invocable: true disable-model-invocation: false