Choose the interface you’re building for
Start with the user action and decide where it should appear. Plugin logic runs on the Harness host. The client determines how it displays and interacts with it.
| Goal | Start here |
|---|---|
| Register a tool, model adapter or reusable agent capability | DeepSeek Harness architecture |
| Extend the Harness Web UI | Harness plugin and client architecture |
| Show native tool cards, panels or actions in DSH Go | DSH Go native plugin guide |
Build a small native example
- Pick a working example
Start with one of the maintainer examples, such as a tool card. Keep the tool result readable even when the client cannot render the card.
- Declare what the app should render
Use the repository plugin kit and the DSH Go docs. The host executes plugin logic and the app renders supported declarative views. The kit is distributed in the repository.
- Verify the fallback
Test a successful tool run and a missing or unsupported native surface. Record the DSH Go and engine versions, connection type and expected rendering in your README.
Check host compatibility before publishing
Native features have different host requirements. Tool cards can travel with tool results, while richer live surfaces may need bridge features on a specific engine or connection. Treat Web UI extensions and DSH Go native surfaces as separate targets.
List the minimum host and client versions you checked. Describe what remains usable when a view or action is unavailable, and verify the Android interface separately from installation.