Design with DeepSeek Harness.
Turn DeepSeek Harness into a local UI workspace with project rules, reusable skills, model routing, and a browser verification loop.
Start dsh, open your repository, load a design contract, generate the interface, then verify it in the browser.
DeepSeek Harness, or dsh, becomes useful for design when you treat it as the runtime around a repeatable UI process. The model edits the code, project files hold the visual contract, skills encode the craft, and browser checks decide whether the result is acceptable.
This guide follows that process from setup to visual review. Product architecture, provider limits, and tool comparisons are included only where they change how you design with the harness.
Build your DeepSeek Harness design workspace
The public preview requires Node.js `^22.19.0` or `>=24.0.0`. The npm command initializes the web profile on first use, so you can reach a working local UI without cloning the repository.
# 1. Start the official DeepSeek Harness Web UI
# Requires Node.js ^22.19.0 or >=24.0.0
npx @deepseek-ai/dsh web
# 2. Open the local UI (default)
# http://127.0.0.1:3080
# 3. In Settings → Models, add a DeepSeek API key
# or configure another supported provider.
# 4. Choose the project directory as your workspace.
# Optional: run one headless job after the profile is initialized
npx @deepseek-ai/dsh --profile headless "Audit this UI against AGENTS.md"
- Credentials stay referenced: The Web UI stores provider secrets in `$DSH_HOME/.credentials.yaml`; settings keep a credential reference, and the UI receives a redacted descriptor rather than the literal key.
- Treat the preview as pinned infrastructure: The maintainers explicitly warn that compatibility-breaking changes will happen. Pin the version for a team workflow and review release changes before updating.
Give the agent a design contract
A model can write JSX, but a useful design agent needs more than model output. It needs brand rules, references, tools, permissions, and a loop that renders and checks the result. DeepSeek Harness exposes those surrounding pieces instead of hiding them.
- Persistent design context: The default instruction loader reads `AGENTS.md` and `CLAUDE.md` from the project hierarchy. Put tokens, component rules, responsive breakpoints, and review criteria where every run can see them.
- Reusable skills: Local skills can live under `.dsh/skills` or `.agents/skills`. A frontend skill can package the exact brief, checklist, examples, and scripts that stop each UI task from starting at zero.
- Provider choice by task: The Web UI can configure DeepSeek, catalog providers such as Anthropic or OpenAI, and custom OpenAI-compatible endpoints. Use a declared image-capable route for screenshot input; use the native DeepSeek route for text, code, DOM, and spec-driven work.
The important limit is the same for every agent: composability is not taste. Without deliberate typography, spacing, component, and interaction constraints, the runtime will faithfully automate a generic result. Open Design’s role is to supply and organize those design inputs.
Run the UI build and review loop
For interface work, make the brief and acceptance loop explicit. The default DeepSeek route is text-only, so the most reliable baseline is a code-and-spec workflow; attach screenshots only after selecting a model route that declares image input.
- Start dsh from the repository, choose that directory as the workspace, and select the model route for this task.
- Put the brand contract in `AGENTS.md`, `CLAUDE.md`, or a referenced `DESIGN.md`: tokens, primitives, spacing, type, breakpoints, states, and forbidden patterns.
- Load a focused frontend skill from `.dsh/skills` or `.agents/skills`; keep examples and validation scripts beside the instructions.
- Ask the agent to reuse existing components, run the application, and validate responsive states with the project’s own tests or browser tooling.
- Review the visible result, record specific deltas, and iterate in small commits. Revert weak passes instead of layering fixes on a bad base.
A useful prompt names both the visual constraints and the verification evidence:
Implement the account dashboard in React + TypeScript.
Reuse the components and tokens named in AGENTS.md and DESIGN.md.
Use a 240px sidebar, a 12-column content grid, and the documented
mobile navigation pattern. Include loading, empty, error, and focus states.
Run the app and existing UI checks, inspect desktop and mobile breakpoints,
and report the exact files and states you verified.If a screenshot is essential, configure an image-capable provider first. DeepSeek Harness refuses an image before sending when the selected route does not declare image support — a useful guard against silently dropping the reference.
Make the workflow reusable with plugins and skills
DeepSeek Harness is most differentiated below the chat surface. Its plugin tree lets teams make the design workflow part of the runtime instead of a prompt pasted into every session.
- AGENTS.md and CLAUDE.md: The instruction plugin loads the user-global file and the project hierarchy, then notices relevant nested instruction files after first-party file operations. Use it for durable design rules, not one-off requests.
- Filesystem skills: The skill registry discovers project and user roots, ranks duplicates, and exposes a model-facing `skill` tool. This is a natural home for frontend craft, accessibility, responsive QA, and design-system procedures.
- Profiles and bundles: A profile stacks ordered plugin bundles plus user patches. Teams can maintain a design-focused composition with the provider, tools, permission policy, and skill sources they actually need.
- MCP and external capabilities: The source tree includes MCP client capabilities, but user-facing configuration is still developer-oriented. Treat integrations as versioned plugin work during the preview, not a stable checkbox workflow.
Before building a long-lived internal workflow, inspect the effective tree with `dsh --profile web --dump-config`. That output shows what is actually mounted and patchable; it is more reliable than assuming every package in the repository is active in the shipped profile.
Avoid the failures that ruin visual output
The biggest mistakes come from treating a preview like a stable product, treating a text-only route like a vision model, or treating a flexible harness like a source of visual taste.
- Pin before you customize: Compatibility-breaking changes are an explicit preview policy. Pin the npm version and keep profile patches small enough to review after an upgrade.
- Check the selected model’s modalities: The native DeepSeek chat-completions route is text-only. For screenshot-to-code, select and declare an image-capable provider route instead of assuming the attachment will be understood.
- Supply taste as data: Give the agent tokens, canonical components, reference states, and forbidden patterns. A modular runtime without a design contract still produces generic UI.
- Verify what the profile actually mounts: Repository packages are capabilities, not proof that the default profile enabled them. Inspect the composed config before documenting an integration or relying on it.
Each mitigation is a context and verification decision. That is exactly the work a design layer should make repeatable rather than leaving every project to rediscover it.
What the harness contributes to design
DeepSeek Harness (`dsh`) is an MIT-licensed agent harness developed by DeepSeek AI. The public developer preview ships a local Web UI and a headless runner. It is not a model and it is not merely a terminal skin: it is the runtime that assembles a model, tools, context, permissions, sessions, and user interface into an agent.
Its defining idea is “everything is a plugin.” Cordis composes a tree in which the model adapter, tool registry, agent loop, filesystem, shell, sandbox, skills, subagents, persistence, and UI can be mounted, replaced, or patched through profiles and bundles. The shipped `web` and `headless` profiles are starting points rather than fixed products.
- Local Web UI: `npx @deepseek-ai/dsh web` starts a browser workspace on `127.0.0.1:3080` by default. Add a model, choose a workspace, and run tasks from the conversation UI.
- Headless mode: The `headless` profile runs one fresh persisted session, prints the final answer, and exits — useful for scripted audits, builds, and repeatable design checks.
- Composable runtime: Profiles stack plugin bundles and your own patches. That lets a team change providers, tools, policy, and UI behavior without forking an agent loop.
- Developer: DeepSeek AI (official project)
- Status: developer preview; compatibility-breaking changes are expected
- License: MIT
- Primary command: `npx @deepseek-ai/dsh web`
When to choose DeepSeek Harness
The names are easy to conflate. DeepSeek Harness and the DeepSeek TUI currently listed in Open Design are separate projects with different executables and integration status.
| Tool | What it is | Best design use |
|---|---|---|
| DeepSeek Harness (`dsh`) | Official DeepSeek AI plugin-first harness with local Web UI and headless profiles; developer preview | Teams that want to compose the runtime, skills, providers, policy, and UI around a design workflow |
| DeepSeek TUI (`deepseek` / `codewhale`) | A separate terminal coding agent and the DeepSeek adapter Open Design currently supports | Using DeepSeek from inside Open Design today |
| OpenCode | Mature open-source, provider-agnostic terminal agent | Switching models inside a stable TUI workflow with AGENTS.md and MCP |
| Claude Code | Mature coding agent across terminal, IDE, desktop, and web surfaces | Frontend reasoning, image-heavy references, and established design integrations |
| Open Design | Agent-native design workspace and library around supported coding agents | Curated design systems, skills, visual artifacts, and a local workflow independent of one model vendor |
Choose dsh when the harness itself is what you want to extend. Choose DeepSeek TUI inside Open Design when you want the currently supported DeepSeek adapter and a ready design layer. They may converge through a future adapter, but they are not interchangeable today.
Add Open Design as the design layer
Open Design and DeepSeek Harness occupy adjacent layers. dsh composes an agent runtime; Open Design curates the design systems, skills, and local artifact workflow that make an agent useful for visual work. Open Design does not yet ship a dedicated `dsh` adapter, so the accurate workflow today is side by side.
- Install Open Design and use its design systems and skills to establish the visual contract for the project.
- Keep the resulting `DESIGN.md`, references, and project instructions in the same repository DeepSeek Harness opens as its workspace.
- Run dsh for plugin-first experiments and code tasks; reuse the same tokens, rules, assets, and validation criteria rather than maintaining a second design brief.
- When you need DeepSeek directly inside Open Design today, select the existing DeepSeek TUI adapter. Treat a future dsh adapter as a separate integration, not as current behavior.
The result is one owned codebase and one portable design contract across two local-first tools. Open Design remains independent from DeepSeek AI; DeepSeek and DeepSeek Harness are trademarks of their respective owner.
Using DeepSeek Harness for design: FAQ
-
01 What is DeepSeek Harness?
DeepSeek Harness (`dsh`) is DeepSeek AI’s official open-source agent harness. It combines models, tools, context, sessions, policy, orchestration, and UI through a Cordis plugin tree. The public release is currently a developer preview under the MIT license.
-
02 How do I install and run DeepSeek Harness?
Install a supported Node.js version, then run `npx @deepseek-ai/dsh web`. It starts the local Web UI at `http://127.0.0.1:3080` by default. Add a model under Settings → Models, choose a workspace, and start a session.
-
03 Is DeepSeek Harness an official DeepSeek project?
Yes. The repository is published under the `deepseek-ai` GitHub organization and describes dsh as an agent harness developed by DeepSeek AI. It is MIT-licensed and explicitly marked developer preview.
-
04 Can DeepSeek Harness build UI from screenshots?
Only when the selected provider route declares image input. DeepSeek’s own chat-completions route in dsh is text-only, and the harness rejects image attachments before sending them on a text-only route. Use an image-capable provider for screenshots, or describe the target through code, DOM, tokens, and written specifications.
-
05 Does DeepSeek Harness support AGENTS.md and skills?
Yes. Its instruction plugin loads AGENTS.md and CLAUDE.md-compatible project files. Its filesystem skill provider discovers project skills under `.dsh/skills` and `.agents/skills`, plus configured user and bundled roots.
-
06 What is the difference between DeepSeek Harness and DeepSeek TUI?
They are separate tools. DeepSeek Harness uses the `dsh` executable and is an official plugin-first Web UI/headless runtime from DeepSeek AI. DeepSeek TUI uses the `deepseek` or `codewhale` dispatcher and is the separate DeepSeek adapter Open Design currently supports.
-
07 Does Open Design support DeepSeek Harness?
Not as a dedicated first-party adapter yet. Open Design currently supports the separate DeepSeek TUI adapter. You can still use Open Design’s design systems, skills, DESIGN.md files, and artifacts alongside dsh in the same local repository.
-
08 Where does DeepSeek Harness store my API key?
The official model guide says provider keys are stored in `$DSH_HOME/.credentials.yaml`. Settings keep only a credential reference, and the Web UI receives a redacted descriptor rather than the literal secret.
Build the design layer around your DeepSeek workflow.
Use Open Design’s local design systems, skills, and artifact workflow today, and keep the same project contract ready for whichever agent runtime you choose next.