An AI workspace can already do a great deal with reusable skills, specialist configurations, external connectors, and projects. We built all four into WorkDSH, an open-source workspace built on DeepSeek Harness. So why did we also make it a plugin-based product?
The answer became clearer when we looked at our own Projects page. A user creates a project to keep a particular task, its materials, and its history together. A developer writes the Projects plugin so the software can create and manage projects at all. Those two things share a name, but they solve different problems.
An actual WorkDSH Projects screen from an early Alpha workspace. The example projects and account details belong to that local environment; they are not preinstalled sample data.
A project organizes a piece of work
Imagine planning a family trip. A project can hold the customer's requirements, previous conversations, supplier documents, and tasks. A planning skill can suggest a route. An expert configuration can review whether the schedule is suitable for children. An authorized connector can retrieve hotel and transport information. When the departure date changes, the team can return to the same project and continue.
For that work, another software feature may be unnecessary. The project already gives the team continuity, and the existing capabilities can help with the task.
The decision changes when the agency wants every formal quote to follow the same rule. A hotel price must be confirmed before it appears on a quote. A low-margin quote needs a manager's approval. Sending a quote must preserve that exact version even if the customer later changes the itinerary.
Chat messages, files, and task history can record what happened. They do not, by themselves, create an editable quote record, a confirmation state, or a check that runs when someone presses Send quote. A skill may remind a person of the rule; software has to enforce it at the point of action.
At that point, an itinerary-and-quoting plugin could give multiple customer projects the same records, editing screen, and approval behavior. It could call a connector for fresh prices, ask a skill to suggest alternatives, and leave the final approval to an authorized person. The project would still own each customer's context. The plugin would supply the reusable operation.
This travel example is illustrative. WorkDSH does not ship an itinerary or quoting application. If an agency already has a reliable booking and quoting system, connecting that system may be the better choice.
What a plugin changes in WorkDSH
DeepSeek Harness provides a plugin runtime and published extension APIs. WorkDSH uses those APIs to add its own features without maintaining a modified upstream Harness checkout. Plugins can be small, such as a tool, or larger, with a page, a service, and rules around the data they own. The WorkDSH Projects, Library, Skills, and Experts features are examples of software functionality delivered through plugins.
This gives us a practical test before building anything new:
- Can the user finish the task with a project and existing capabilities?
- Is there already a suitable system that a connector can reach, or a community plugin that can be installed?
- Does the same missing operation recur across projects, with records and rules the software itself must manage?
Only the third case gives us a strong reason to write a new application plugin. Complexity alone is a poor test. A difficult one-off report may need a project and a good skill. A simple-looking approval button may need durable state and careful authorization.
Two new ways to discover capabilities
The current WorkDSH Skills view connects to SkillHub as a catalog. A catalog entry is something a user may inspect and choose to install; it is not evidence that thousands of skills came preinstalled with WorkDSH. The view shows source and version information so the user can inspect a skill before adding it locally.
Actual Skills view from a local Alpha profile. Installed counts reflect that profile, not a clean installation.
For software extensions, users can install the independently maintained dsh-market plugin through the DSH plugin mechanism. Once installed, it opens a community plugin catalog inside WorkDSH. It is a third-party market, and its listings are not WorkDSH-bundled or WorkDSH-reviewed plugins.
Actual local view after dsh-market was installed. The catalog and its listed plugins are maintained by their respective providers.
The Desktop preview also bundles the Node.js and Python runtimes needed to start WorkDSH. A third-party plugin can still have additional dependencies of its own.
WorkDSH remains an Alpha project. Installation paths, complex document fidelity, and other advanced workflows still need validation. The repository and release notes are the right place to check what a particular build actually includes.
I'm interested in the boundary other builders draw: when do you keep a workflow in prompts and projects, and when do you make the software own a new record and operation?
WorkDSH is independent of WorkBuddy, SkillHub, and dsh-market. The travel application above is a design example, not a shipped feature.
AI disclosure: This article was generated with AI from project source materials. Release-specific claims were checked against the latest Desktop release notes.
Top comments (0)