Ui picker
Skill Bandersnatch0x/design-playbook/packages/design-playbook/skills/ui-picker
UI shell and component semantics. Use when scaffolding a product page (list, dashboard, settings, detail, agent-admin), or when the wrong template/Badge-Tag pairing is about to be coded.From its SKILL.md
npx -y skills add Bandersnatch0x/design-playbook --skill ui-pickerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, 650 tokens by cl100k_base, as published. Nobody here has run it
ui-picker
Before code: map the job to a template (shell) and component semantics. Appearance follows meaning.
Steps
1. Density + scene
Choose density (console-tight vs marketing-loose) and scene class (list / detail / settings / dashboard / editor / agent-admin / …).
When a verified .scratch/<run>/design-baseline/state.json binds a baseline (status: ready from design_baseline.verify), read that binding path first (baseline.path, usually DESIGN.md or .stitch/DESIGN.md). It is the project-specific authority for atmosphere, visual roles, density, layout, motion, and component conventions. Preserve it unless the requested change explicitly revises the baseline.
When .scratch/<run>/reference/contract.md exists (ADR-0011), read its Visual cues for ui-picker, Keep/Change, and Do not copy / exclusions. Use them as input for density, scene, region weight, and risks — never as hex tokens or as a license to copy brand chrome.
Done when: one scene label and one density choice are explicit; a bound baseline is cited by path + SHA-256; if a reference contract exists, the decision report's risks or exclusions surface its Do not copy / brand risks (path citation is enough).
2. Template
Read references/template.md. Assign main / side / action / status regions.
Done when: each region maps to a duty from spec L2 (or a stated gap in the spec).
3. Components
Read references/components.md. For each field/action, pick by role (status vs category vs confirm vs detail).
Load only if needed:
- business risk / desensitize →
references/domain.md - token roles while deciding surfaces → verified
<binding.path>first, then generic fallbackreferences/design.md
Done when: every primary datum/action has a named component role; easy-mix pairs (Badge/Tag, Dialog/Drawer, Dropdown/Menu/Command) are resolved in writing.
4. Decision report
Write, then wait for confirmation if the user is in the loop:
design-baseline: <binding.path> sha256:<digest> | waived:<reason>
scene:
density:
template:
regions: …
components: …
baseline-changes: none | <explicitly approved change>
risks: …
Done when: the report exists, records the bound baseline or explicit waiver, and coding has not started without it.
Branch — structure still open
If template is underdetermined, offer 2–3 IA variants (same spec, different main-region weight), one-line tradeoff each, pick one, then complete step 4.
Defaults that hold
- Brand color as token/role, not a hex literal.
- Easy-mix pair semantics and shell 禁用 rules live in
references/components.mdandreferences/template.md— resolve against those tables, not from memory.
What ships with it: 4 files
3.0 KB alongside SKILL.md
references/
- components.md991 B
- design.md572 B
- domain.md710 B
- template.md749 B