A DeepSeek Harness plugin is not a long prompt. It is code that changes the harness itself: a sidebar, a memory store, a router, a vision tool, a web fetcher. That difference matters. A bad skill produces a bad answer. A bad plugin can read files, make network calls, or change how every other tool in the harness behaves.

The plugin cards in the directory come from public repositories. A card is a pointer, not an inspection. This guide is the inspection order we use before an install command goes into a working harness.

Start with the extension point

Read the card and the repository README until you can answer one question: what part of the harness does this plugin replace or extend?

Most DSH plugins fall into a few groups:

  • Interface plugins add a panel, sidebar, status line, or preview. Their risk is mostly what they render and what they read to render it.
  • Memory and context plugins store conversation state, project notes, or embeddings. Their risk is where that store lives and who can read it.
  • Routing and orchestration plugins decide which tool or model handles a request. Their risk is silently changing behavior you rely on.
  • Tool plugins add a capability such as browser control, vision, or a remote API. Their risk is the permission and the data that leaves your machine.
  • Workflow plugins chain several steps together. Their risk is the sum of every step, plus the fact that the chain is harder to stop.

A plugin that claims to do three of these at once is not automatically bad, but it needs a longer test. You are not only installing a feature; you are installing a policy about how the harness works.

Read the install command as code

The card may show a command, a prompt, or both. Treat the command as code even when it is one line.

  • Does it download a release, clone a repository, or run a remote script?
  • Does it write outside the plugin directory?
  • Does it modify a config file you already maintain?
  • Does it pin a version, or follow the default branch?
  • Does it ask for a token, a key, or a path to your home directory?

A command that pipes a remote script into a shell is not automatically malicious, but it is not auditable in one line. Prefer a plugin with a tagged release and a short install command you can read. If the only install path is "run this script from the README," read the script first or skip the plugin.

Follow the data

For any plugin that stores or sends data, find the destination before you install it.

  • Local only: the plugin writes a file or a local database. Check the path and whether it is inside your project or in a shared home directory.
  • Remote model: the plugin sends prompts or context to an API. Check whether that includes file contents, conversation history, or secrets from the environment.
  • Remote service: the plugin calls a vendor endpoint for search, vision, or storage. Check what is uploaded and what the vendor retains.
  • Mixed: the plugin stores locally but syncs to a remote service. This is the case most likely to surprise you.

A plugin that needs a key should tell you which scope it needs. A vision plugin needs an image, not your whole workspace. A search plugin needs a query, not your repository. If the README does not say, assume the broadest plausible access until you read the code.

Check the release history

A plugin is a dependency. Dependencies age.

  • When was the last release?
  • Do the release notes mention breaking changes to the harness?
  • Are issues about data loss, crashes, or permission errors answered?
  • Does the repository have a license that permits your use?
  • Is the install command the same one the release notes describe, or has the README drifted?

A popular plugin with a dead repository is a liability. A small plugin with a recent release and a clear changelog is often the better bet. Stars measure attention, not maintenance. The How ranking works guide explains how the directory orders these cards.

Test in a throwaway workspace

Install into a copy of your workspace, or into a fresh project with one harmless file. Then run one task that exercises the plugin's extension point:

  • For a sidebar, open it and check what it renders and which files it reads.
  • For memory, add one note, restart the harness, and see what persists.
  • For routing, send one request and inspect which tool was chosen and why.
  • For a tool plugin, run it on a small, non-sensitive input first.

Watch for changes you did not ask for: new config files, modified settings, background processes, or network requests during startup. A plugin that phones home before you use it is telling you something about its design.

Plan the removal before you need it

Find the uninstall path in the README or the repository. If there is none, that is a reason not to install.

Removal should cover:

  • the plugin directory or package;
  • any config entry added by the installer;
  • any local store or cache it created;
  • any credential you added for it.

Write those four paths down before the install. If the plugin breaks the harness, you will not want to reconstruct them from memory. The install, update, and remove guide covers the general procedure; plugins add the config and store steps.

Red flags worth taking seriously

Skip a plugin when the install instructions ask you to:

  • disable a safety check or run with elevated permissions by default;
  • paste a long-lived production token into a config file;
  • upload an entire home directory or repository to a remote service;
  • replace the harness's routing without a way to inspect the choice;
  • run an unpinned script from a URL you cannot read.

None of these is proof of bad intent. Each one removes your ability to verify what happened, which is the same problem in practice.

What a good plugin card tells you

A useful card names the repository, the license, the last update, and the install command. It does not tell you the plugin is safe. That is the inspection above. When the card carries an editor's note, the note is our writing and should say who the plugin is for and who should skip it. When it does not, the card is only a pointer to the publisher's material.

Install one plugin at a time, test the extension point, and keep the removal steps next to the install command. A harness with three plugins you understand is more useful than one with ten you cannot debug.