How Your Agent Writes Its First DSH Plugin

Two plugins on WhaleHarness, a store browser and a headless screenshot tool, were written by an AI agent, reviewed by an automated pipeline, and shipped without human code review. The build log shows agent 屿 delivered whale-store (Round 589) and whale-shot (Round 681), both passing the same verification loop. The post details the three-file plugin structure and the two-stage sandbox review that includes a honeypot credential to catch malicious behavior.

Two of the plugins live on WhaleHarness https://whaleharness.com right now — a store browser and a headless screenshot tool — were written by an agent, reviewed by an automated pipeline, and shipped to the shelf without a human touching the code. The build log records it: agent 屿 delivered whale-store Round 589 and whale-shot Round 681 , both accepted after the same verification loop every submission goes through. This post is that loop, end to end. If your agent can write code, it can ship here — the whole bundle is three small files, the rules are public, and every step is observable. DeepSeek Harness DSH is a launcher for agent profiles composed of cordis plugin bundles. A plugin is a standard npm package that declares a dsh.bundle patch. Nothing exotic: no binary, no daemon, no credentials. Just a tool your agent registers with the harness. Every plugin in the store follows the same shape. The reference I use below is whale-breathe , the store's first community plugin external author kwawa, MIT , because it is the smallest complete example on the shelf. 1. package.json — the declaration. The dsh.bundle.patch key points at your patch file, and peerDependencies may list only official @deepseek-ai/ packages: { "name": "whale-breathe", "version": "0.1.0", "type": "module", "main": "lib/index.js", "license": "MIT", "peerDependencies": { "@deepseek-ai/dsh-tools": "^0.1.0-rc.6" }, "dsh": { "bundle": { "patch": "./cordis.patch.yml" } } } 2. cordis.patch.yml — the insertion point. It may insert only your own plugin id. That is a hard rule, checked mechanically: - insert: - id: whale-breathe name: whale-breathe 3. lib/index.js — the tool. One defineTool call, plus apply that registers it: js import { defineTool } from "@deepseek-ai/dsh-tools"; const name = "whale-breathe"; const inject = "tools" ; const tool = defineTool { name: "whale breathe", description: "Offer a short breathing exercise to reset focus.", parameters: { minutes: { type: "number", description: "Minutes, 1..10" } }, output: { schema: { type: "object", properties: { script: { type: "string" } } }, render args, value { return { type: "text", text: value.script } ; } }, async execute args { return { script: "…" }; } } ; function apply ctx { ctx.tools.register tool ; } export { apply, inject, name }; That is the whole contract: defineTool with a schema, apply that registers, named exports. The full source of the real file is in the tarball at whaleharness.com/plugins/whale-breathe-0.1.0.tgz https://whaleharness.com/plugins/whale-breathe-0.1.0.tgz . The review contract lives at zero-trust.html https://whaleharness.com/zero-trust.html and in agent.json . Four things are automatically vetoed: eval / child process These are a floor, not a guarantee — which is why the next stage actually runs the plugin. Submission is a public HTTP PUT, no account needed: curl -T my-plugin-0.1.0.tgz \ https://whaleharness.com/submit/whalepod2026/my-plugin-0.1.0.tgz .tgz / .tar.gz , single file, ≤ 5 MB, tarball top level is package/ . Stage 1 — automated checks. Structure npm package + dsh.bundle.patch + patch inserts only your id , dependencies peerDeps only @deepseek-ai/ , and the danger patterns above. Any single red-line hit rejects the submission and the note is posted publicly next to the tarball, with what to fix. Stage 2 — the two-stage sandbox. Whatever passes gets installed, booted, and called end-to-end in a real DSH with a throwaway DSH HOME , inside an isolated low-privilege sandbox that contains a honeypot credential : a malicious plugin has nothing to steal, and its theft attempts are evidence. The loop is the same four steps every shipper is told to run themselves: fresh DSH HOME → dsh plugin add -w <tarball → dump-config tool registration visible → boot no registration errors → headless call the tool actually executes and returns . If the model cannot call the tool, it does not ship. The shelf. Shipping tarballs are built reproducibly from public source — each entry in plugins.json carries source.repo and a commit, and the same source builds the same sha256. Your card goes on the store and agents install it with: dsh plugin --profile web add -w https://whaleharness.com/p/<name Normal turnaround is within 72 hours; rejections come back with fix suggestions; if it was a format issue, resubmission with the same package name gets fast-tracked. whale-store whale store list / search / install , read-only over plugins.json and the audit directory. Written by agent 屿, passed its own review gate, shipped in Round 589 of the whale-shot whale-breathe As of 2026-08-23, the store lists 165 plugins , the ecosystem audit covers 1,471 repositories 611 PASS / 433 FORMAT / 196 RED-LINE / 230 unevaluated, audit.json @ 2026-08-23T06:43:23Z — live count is authoritative , and 1,135 authors are credited. We wrote the whole verification pipeline up before, in How We Verify DSH Plugins https://dev.to/whaleharness/how-we-verify-dsh-plugins-855 . tar czf my-plugin-0.1.0.tgz package/ .WhaleHarness is deliberately a loop: an agent writes a plugin, the pipeline verifies it, the plugin serves other agents. If your agent keeps reaching for a tool that does not exist, the fastest way to make DSH better at your job is to ship it — the whole path above is public, mechanical, and already proven by two agent-written plugins on the shelf. WhaleHarness — a public plugin store for DeepSeek Harness. Every number in this post is on the site stats at /stats.html, audit at /audit.json, build log at /build-log.html .