Preface¶
When building frontend pages with DSH, the model outputs an “average of seen pages”: centered slogans, three-line subtitles, a small tag above, a row of icon cards, soft gradients, a few thin dividers, monospace font for comments. Individually, each is correct, but combined, none of the decisions are made for the client.
stevenwang15/dsh-taste-skill is a native DSH bundle plugin that wraps taste-skill v2 (skill name design-taste-frontend) into a DSH skill. After installing into a profile, an entry design-taste-frontend appears in the DSH skills directory: the model auto-loads based on the description, or you can type /design-taste-frontend to force a call. The approach is: direction is dealt by scripts, specifications are measured one by one by a real browser, and rework is based on screenshots I look at, rather than writing rules into prompts and expecting the model to self-comply.
What is this¶
| Plugin Name | dsh-taste-skill |
| Maintainer | stevenwang15 |
| Category | Workflow |
| License | Wrapper MIT; Skill body from Leonxlnx/taste-skill, MIT |
| Current Version | Plugin 2.1.6 / Upstream Skill 2.1.5 |
| Form | Registers only 1 native skill design-taste-frontend |
| Runtime | Node 22+; Chrome / Edge / Chromium only needed for visual inspection |
| Dependencies | No external dependencies, no API key required |
Used for landing pages, marketing sites, portfolios, product pages, event pages; it also covers application interfaces like dashboards, backends, settings, and inboxes. It does three things: design from scratch, redesign, and review (only gives opinions, does not touch code). Explicitly does not provide: templates, does not modify DSH’s own interface, does not automatically download a browser.
What problems does it solve¶
When the model picks direction itself, it tends to pick the most familiar one. This plugin replaces that average set with four things:
- Direction is dealt by scripts. 20 directions researched from real award-winning sites are randomly dealt 3 at a time; the model can only choose one that can accommodate the client’s own materials.
- Ideas must come from the subject. Page concept sentences grow from the client’s inventory (meaning of the name, the street it’s on, that constraint, what it produces), and then tested against “nearest competitors”: if the sentence holds true if swapped with the neighbor’s, it belongs to the category, not to this client.
- Specifications rely on measurement, not self-awareness. Headings within two lines, no eyebrow tags, no monospace fonts, no 01/02/03 numbering, no hairlines, no gradients, static elements no shadows, icon cards and glassmorphism all no—these are measured one by one by a real browser.
- Rework based on looking at your own screenshots. 1440 / 768 / 390 measurement tiers plus screenshots; pick out the three worst problems based on a judge-style scoring sheet, fix them, look again; at most three rounds.
Core Capabilities¶
1. Dealing researched directions, not the model’s taste¶
scripts/draw.mjs first deals 3 directions for you to choose. Once selected, it delivers the配套 Hero layout (58), layout blueprint (185), font system (44), color palette (56), photography reference (19 sets), animation recipe (18), and similar research sites (202) for that direction in one go. The extraction remembers the ones recently used, so consecutive projects won’t look the same.
2. Layout blueprints distributed by “what this section needs to prove”¶
Not a template to the end: first write the argument (one claim + evidence per section, delete sections with no claim), then distribute layouts based on section roles (intro / about / features / list / stats / faq / cta / footer, etc.), ensuring adjacent sections don’t repeat composition.
3. Real photos, with authorization and attribution¶
scripts/assets.mjs searches for real photos of the subject world from Openverse, Wikimedia Commons, the Art Institute of Chicago, the Metropolitan Museum of Art (old photos, maps, material close-ups, prints, similar collections), returning only commercially usable licenses (CC0 / Public Domain / CC BY / CC BY-SA) by default. --get downloads and records title, author, license, and source into assets/credits.json; --credits prints the attribution line needed for the footer. Video works the same way (--video, takes 720p or less, attaches a poster frame). For things where honest photos can’t be found, draw with code: the subject’s objects, its interface, its tiles. The page must have at least 4 real photos; this is a hard floor.
4. Anti-pattern checklist: both a spec and a measurable gate¶
scripts/lint.mjs statically scans the source code for disabled patterns and clichés; scripts/inspect.mjs measures in a real browser: heading line count, font size, actually loaded fonts, colors, dividers, shadows, gradients, contrast, overflow, and “frames”: whether left/right margins are equal, whether a whole section is squeezed to one side, whether there are white spaces exceeding half a screen, whether there is a title on the first screen, whether each section has a subheading. If there is a FAIL, it must be fixed; WARN is treated as an error unless it can be explained in one sentence to a designer.
5. Scroll scenes and “one thing to touch”¶
For pages with scroll narratives, scripts/scenes.mjs takes a frame-by-frame snapshot of each scene at 0 / 10 … 100% progress (desktop, mobile, reduced motion sets) to confirm it really runs, rather than stopping at the first frame. Every page also requires something the visitor can interact with (not decorative animation): choose a wood type to see a chair, input a name to see a font, adjust loan parameters to see real monthly payment. Use the subject’s real content, usable with a thumb on mobile, with a normal fallback when scripts are absent.
6. Application interfaces are also managed¶
Dashboards, backends, settings, inboxes, and other interfaces where “people work inside” follow an independent process from references/app-screens.md: their own card drawing (draw.mjs --app), their own rules (quiet borders, aligned numbers, colors only on data, navigation collapsing on mobile), their own checks (inspect.mjs --app). 7 style categories / 5 shells / 25 screen patterns.
Installation & Enablement¶
The installation command comes from the original README:
dsh plugin --profile desktop add https://github.com/stevenwang15/dsh-taste-skill.git
On desktop, you can also paste the same repository address in Settings → Plugins. After installation, restart DSH (profiles with HMR enabled will hot-load), and design-taste-frontend will appear in the skills directory of new sessions.
You can also install the tarball from a Release, or from a local directory:
dsh plugin --profile desktop add https://github.com/stevenwang15/dsh-taste-skill/releases/download/v2.1.6/dsh-taste-skill-2.1.6.tgz
dsh plugin --profile desktop add ./dsh-taste-skill # local directory
After installation, you don’t need to remember commands; the model will auto-load based on descriptions, for example:
- “Make a single-page official website for a boutique coffee roasting workshop, with real photos”
- “This landing page looks too much like AI-made, look at what’s wrong and redo the visuals”
- “Give me a SaaS backend dashboard interface, and review the current version while you’re at it”
To force loading, type /design-taste-frontend.
Build artifacts land in the workspace .taste-skill/: direction.json (direction table), history.json (extraction history, cross-session to avoid duplication), inspect/ (screenshots and report.json).
Environment Requirements¶
- Node 22+. DSH’s built-in runtime is 24.x; when the plugin loads, it writes the available Node absolute path into the skill body, so it doesn’t matter if the host PATH has Node 20.
- Chrome / Edge / Chromium is optional. If missing,
scripts/browser-check.mjswill report it explicitly;inspect.mjs/scenes.mjswill exit cleanly with exit code 2, and the skill will take the fallback path: only runlint.mjsfor static checks, and note “no visual check run” in the report. The plugin will not automatically download a browser. - Network is only needed when looking for images (
assets.mjs). Everything else is offline.
How a single build works¶
The complete flow given in the README:
| Step | What to do |
|---|---|
| 1 | Inventory: 8–12 things unique to this client |
| 2 | Write arguments: one claim + evidence per section |
| 3 | Draw direction: draw.mjs deals 3 directions, choose one that can carry the inventory items |
| 4 | Find ideas: write “⟨client’s something⟩ becomes ⟨direction-required device⟩”, and test with competitors |
| 5 | Write copy: copy first, layout second; headings within two lines, fill content for each section |
| 6 | Build site: tokens → first screen → blueprint for each section → images → interactive thing → scroll scenes → full height → frames → state and semantics |
| 7 | Pass the gate: lint.mjs + inspect.mjs, add scenes.mjs if there are scenes; fix until 0 FAIL |
| 8 | Look at images: open each screenshot, score item by item based on the scoring sheet, fix the three worst problems, at most three rounds |
| 9 | Animation: signature motion + entrance for each section + control feedback + one moving photo; only transform / opacity, with prefers-reduced-motion fallback |
| 10 | Report: direction and seed, concept sentence, final score, source for each image, which parts are placeholder assets |
A full build takes about 30–45 minutes and hundreds of thousands of tokens; the bulk is finding/drawing images and rework.
Content Inventory¶
Library scale listed in README: 20 design directions, 58 hero layouts, 185 layout blueprints, 44 font systems, 56 color palettes, 202 research sites (distilled from 247 curated sites), 18 animation recipes, 7 application interface style categories / 5 shells / 25 screen patterns, 19 photo sets, 11 reference documents, 6 scripts (draw, assets, lint, inspect, scenes, browser-check, plus zero-dependency lib/), evaluation set evals/evals.json.
Relationship with Upstream¶
Skill content is isomorphic with the upstream: SKILL.md, references/, library/, scripts/, assets/ are included as-is (upstream 2.1.5, commit 12af471), with only three DSH-side adaptations:
| Upstream | This Plugin |
|---|---|
Discovered by copying to ~/.claude/skills/ |
Bundle registration: ctx.skills.register(), resourceBase points to the skill directory inside the package |
Extraction history written to ~/.taste-skill/history.json |
Written to workspace .taste-skill/history.json, isolated by project |
| Assumes Node 22 and Chrome on PATH | Detects Node and browser on load, writes absolute path and detection results into the skill body; exits cleanly and falls back when no browser is present |
Therefore, when the upstream updates, just replace skills/design-taste-frontend/; no need to change rules, libraries, or workflows.
Applicable Scenarios & Notes¶
Suitable for batch producing or redoing frontend pages in DSH, and for those who want specifications not to rely on the model self-complying with prompts. The plugin runs with the permissions of the current DSH process; before installing, read the source code and license (wrapper MIT, skill body is upstream MIT original), and confirm that cordis.patch.yml and index.js registration behavior meets expectations.
Two engineering details worth noting: first, ctx.skills.register() must explicitly include the source field; without it, the skill will still appear in the session directory, but skill(name) will throw loaded skill "…" source must be a string when actually loaded; second, when there is no browser, the visual gate will fall back, and the report must honestly state “no visual check run”.
Verification commands:
npm test # 24 assertions: export, registration contract, description length, payload integrity, load-time validation
npm run doctor # Prints Node / browser detection results
npm pack --dry-run # Checks release content
Uninstall:
./scripts/uninstall-local.sh desktop
Conclusion¶
The value of this plugin is not in giving the model more prompts, but in making “direction, specification, and rework” three things that become executable script gates: direction is dealt from a research library, specifications are measured one by one by a real browser, and rework is based on screenshots I look at. The directory page is at https://www.skillhub.cn/plugins/stevenwang15/dsh-taste-skill, source code is at https://github.com/stevenwang15/dsh-taste-skill, and the skill body comes from https://github.com/Leonxlnx/taste-skill .
