Preface¶

DeepSeek Harness (dsh) packages models, tools, sessions, sandboxes and interfaces as plugins, officially described as “everything is a plugin”. There are already many interface enhancement plugins in the community, most of which modify how Harness is viewed and operated. There is another category of issues in front-end projects: whether to require secondary confirmation before deletion, whether the submit button is disabled after the request is sent, and whether form progress will be lost when exiting halfway. Tools like axe and Lighthouse can check absolute rules such as contrast ratio and missing alt text, but experience issues are often relative— the same secondary confirmation can be a protection for users who operate occasionally, but a nuisance for operators who handle hundreds of records every day.

dsh-user-experience takes the target user profile as the prerequisite for walkthrough: no experience conclusion should be drawn without clarifying “who it is for”. It scans React/Vue source code to locate problems, can supplement browser evidence when the page is opened, and after confirmation, provides task Prompts that can be copied directly to coding Agents. This article is organized after checking against the plugin directory page, GitHub repository README and package.json.

What is this¶

dsh-user-experience is a UX walkthrough plugin for DeepSeek Harness, maintained by DietCokewithSugar, licensed under MIT. The community plugin directory categorizes it under “Interface Enhancement”, with 18 GitHub stars as of now. The repository package.json version is 0.4.1, and the plugin configuration id is ux-experience.

It does not aim to change the skin of Harness, but to discover front-end experience issues in advance during the development phase. The repository README positions it as a pipeline, not a CLI that requires memorizing slash commands: just speak naturally, or modify the front-end files and the walkthrough will run automatically. The walkthrough conclusions come with file locations and rule numbers, but do not modify code automatically.

The capability boundaries are subject to the repository README:
- Support React + TypeScript (.ts/.tsx), React + JavaScript (.js/.jsx), Vue 3 (.vue SFC)
- Support conservative candidate extraction for CSS/SCSS/Sass/Less/PostCSS; visual conclusions still require real page evidence
- When the current Harness session can open the project, further screenshots, DOM measurements can be taken, and key tasks can be executed based on the user profile
- Explicitly does not support Svelte, Vue 2, mini-programs (.wxml), etc.; it will inform you truthfully during detection without giving low-quality guesses

The community directory deepseek-harness-plugin.com is an independent site, not officially affiliated with DeepSeek/HyperGiant, and should not be regarded as an official app store. The official repository is at deepseek-ai/deepseek-harness, and one of the ways to discover plugins is the GitHub dsh-plugin topic.

Core Features¶

Persona-driven, draft personas first if no profile exists¶

Every conclusion is anchored to a clear target user. If there is no existing profile in the project, the plugin will guess 1-3 draft personas from the README and routes, and ask “According to these users?” with short cards. After confirmation, the walkthrough will proceed. The personas will be saved to .ux/personas.yml, which can be shared via git, so team members do not need to repeat this step.

The walkthrough will also judge the product type (consumer, enterprise, ecommerce, content, finance, healthcare, developer-tool, internal-tool or other) from the project documentation and this business process, and then apply the corresponding experience priorities.

27 rules, speak based on evidence level¶

The rules are based on Nielsen’s usability heuristics, totaling 27. The judgment is mainly based on the model, supplemented by AST/CSS verification. Each conclusion is marked as static (source code/CSS), rendered (real screenshot/DOM/size) or interactive (recorded persona task steps). Without browser capabilities, it will continue static walkthrough without pretending to have viewed the page.

Layout density, visual language, and whether main operations are clear require at least rendered evidence; issues such as redundant processes, deep navigation, and delayed form validation require at least interactive task records. CSS can only provide inspection clues, and without real route screenshots, it will not assert that there are problems with whitespace, hierarchy or visual quality.

The high-frequency inspection order is: feedback and system status → form and process recovery → information architecture, navigation and main operations → cognitive load, consistency, edge cases, basic usability and performance. The final report is still sorted by severity. The interface uses level 1 to 4 issues, and P0-P3 are only for internal identification.

The following examples illustrate how the rules are linked to the working mode:
- R-04 Irreversible operation without secondary confirmation, R-07 Submit button not disabled during submission: use model + AST
- R-09 Light/dark mode adaptation missing: pure AST, no token consumption
- R-10 Cluttered layout, R-13 Unclear page purpose or main operation: must have rendered evidence
- R-14 Redundant interactions for key tasks, R-20 Lost form progress when exiting halfway: must have interactive records

Automatically run a walkthrough after editing front-end files¶

After modifying front-end files (including CSS), the static walkthrough will be automatically performed on the complete component/page to which the file belongs at the end of the round, without asking for user profile or scope. If there is no profile, it will first draft a profile before conducting the walkthrough. Only level 1/2 issues will trigger a notification to avoid interrupting coding. Automatic walkthrough is enabled by default, and can be turned off via .ux/rules.local.yml or plugin configuration.

Walkthrough initiated actively by the user in natural language will be upgraded to include screenshots and persona tasks when tools are available.

Report cards and confirmation closed loop¶

The first screen of the report only contains information that users can understand: which page, what happened, and how serious it is. File paths, rule IDs, and internal numbers are folded in the “Technical Details” section, and can be copied as structured YAML after expansion. You do not need to memorize numbers to make judgments: click “Confirm Exists/Not an Issue”, or say “The 2nd rule is not valid” or “Ignore all issues below level 3”.

After confirming an issue, the card provides “Copy task Prompt for AI”. The Prompt only describes the observed phenomenon, occurrence scenario, user impact and acceptance goals, does not preset code modification methods, and clearly states that the plugin only read part of the code and requires the full context to be supplemented. For copy issues, you can directly modify the copy.

During the next walkthrough, if an issue disappears and the location is indeed rescanned, the plugin will record it as an implicit confirmation—the user has fixed it. If the location is not scanned this time or the code block is deleted, it will be marked as stale and not counted as “scanned and found nothing”.

Choose the operating mode according to the scenario: auto mode (generate report without interruption) for walkthrough triggered by code changes; review mode (batch confirmation) for walkthrough initiated actively by users; interactive mode (confirm one by one) for fine-tuning rules. The judgment order is: mode in .ux/rules.local.yml → plugin configuration → automatic detection.

Installation and Activation¶

The installation command given on the community directory page is:

dsh plugin add github:DietCokewithSugar/dsh-user-experience

The repository README is targeted at the web client, specifying the web profile (this plugin declares dsh.client.platform as web in package.json):

dsh plugin --profile web add github:DietCokewithSugar/dsh-user-experience

For reproducible installations, both the directory page and the repository recommend pinning the commit hash. The repository README usage is as follows (please go to the main commit history to copy the latest 40-digit SHA; the one below is from the original README, used to bypass getRepoRefs/resolveGit failures on some Windows + pnpm 11 environments):

dsh plugin --profile web add github:DietCokewithSugar/dsh-user-experience#57fe06eb8bc1313a931bfb50eb2416c52bb1fdea

If dsh-user-experience was already added to the profile’s package.json from a previous failed installation, delete that line first before installing. Refresh the page after successful installation, and a restart is generally not required. The repository has pre-built lib/ committed, so prepare/preinstall/postinstall will not be executed when installing from GitHub. Only restart or reload the web profile if you are prompted that hot reloading is not possible.

Local build and testing use @deepseek-ai/dsh-*@0.1.0-rc.6 and @deepseek-ai/cordis@4.0.1; these are provided by the profile via peer dependencies at runtime, with the DSH range >=0.1.0-rc.6 <0.2.0. Harness, Cordis, and React are peer dependencies of the host profile, and this plugin does not bundle a private copy into the profile.

Available configurations after installation (override by id in the profile’s cordis.patch.yml or --patch layer; the user’s .ux/rules.local.yml has higher priority):

- id: ux-experience
  config:
    maxScanFiles: 300
    maxCandidatesPerRule: 5
    maxCandidatesPerFile: 25
    maxFindings: 30
    excludePatterns: ['test', 'stories']
    mode: detect
    autoScan: true
    autoScanEditTools: ['write', 'edit']
    autoScanMaxFiles: 20
    autoScanDebounceTurns: 1
    outputLanguage: auto

When outputLanguage is auto, it first follows the current user’s language, then falls back to the project’s main README; it can also be explicitly set to zh-CN or en. Report cards and AI task Prompts support both Chinese and English.

Typical Usage¶

The repository README emphasizes: just speak naturally, no need to learn /ux.

You can start the first walkthrough like this:

Check if the checkout flow from product selection to payment works well
We mainly serve operations users

If there is no existing profile in the project, a short card will first appear to confirm the target users. Say “That’s it” or revise the description, and the walkthrough will proceed.

After the report is generated, continue speaking or click the card buttons:

The 2nd rule is not valid
All these points are correct
Ignore all issues below level 3
Delete that entry I confirmed

After confirming an issue, click “Copy task Prompt for AI” and paste it to the coding Agent. You do not need to send instructions again after modifying the front-end files: the static walkthrough will run automatically at the end of the round, and only level 1/2 issues will trigger a prompt.

The repository file conventions are as follows:
| File | Committed to git | Description |
|------|--------------|------|
| .ux/personas.yml | Yes | Project-level user personas, shared by the team; required for CI mode |
| .ux/glossary.yml | Yes | Glossary and judgments, only incremental comparisons will be done later |
| .ux/rules.local.yml | No | Personal walkthrough preferences, supports mode and autoScan |
| .ux/history.jsonl | No | Fingerprint history ledger for long-term metrics, not judgment results |

It is recommended to add the following to the project’s .gitignore:

.ux/rules.local.yml
.ux/history.jsonl

Example personal preferences:

# .ux/rules.local.yml
mode: review
autoScan:
  enabled: true
  debounceTurns: 1

Applicable Scenarios and Notes¶

It is suitable for these situations:
- You are using DeepSeek Harness to develop React (TypeScript/JavaScript) or Vue 3 front-end, and want to see locatable experience issues before merging code
- The team can reach a consensus on “who it is for”, and is willing to put .ux/personas.yml into the repository
- You need to hand over the walkthrough results to another coding Agent for modification, rather than letting the walkthrough plugin modify the code itself

Notes for use:
1. The plugin runs with the permissions of the current dsh process, and may execute code during installation. You should check the source code repository and license before installation; it is recommended to lock trusted commits in production environments.
2. Without a browser/screenshot tool, or when the project cannot be started currently, only static walkthrough can be performed. Conclusions about layout, vision, touch hotspots, redundant processes, etc. will be downgraded or not displayed.
3. Does not support Svelte, Vue 2, mini-programs. Handing over such projects to it will not yield reliable experience conclusions.
4. The plugin does not modify code automatically. The Prompt after confirming an issue only describes the phenomenon, and the specific modification method should be determined by the coding Agent combined with the full repository.
5. The automatic walkthrough scans components/pages, not diff lines; modifying one style may overwrite the entire page report. You can control the frequency with autoScanDebounceTurns.
6. The directory page was added on 2026-08-15, and the repository is still iterating rapidly. The installation commands, configuration items and rule set shall be subject to the directory page and GitHub README opened at that time.

Summary¶

dsh-user-experience takes “who it is for” as the prerequisite for walkthrough, uses 27 rules to scan React/Vue source code, and can supplement screenshots and task records when the page is open. It does not modify your code, only provides locatable, confirmable experience issues that can be transferred to coding Agents.

Directory page: https://deepseek-harness-plugin.com/en/plugins/dsh-user-experience/

GitHub: https://github.com/DietCokewithSugar/dsh-user-experience

Using dsh-user-experience to walk through front-end experience according to user personas during the development phase