dsh-task-sounds
DeepSeek Harness Web UI 的任务完成与提问提示音。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:henrytang2011win-coder/dsh-task-sounds#4e7990b0e561f052c3bcee00a322baecd8fa71c0DeepSeek Harness Web UI 的任务完成与提问提示音：Agent 完成任务或向你提问时播放提示音。
Task Sounds 以 dsh-task-sounds 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Task-complete & question notification sounds for the DeepSeek Harness Web UI. A small chime plays when the agent finishes a turn, and a different "ding-dong" plays when the agent asks you a question mid-task (questions, plan reviews, and approval prompts all pause the agent waiting for your input).
No assets, no network, no host process: chimes are synthesized in the browser with the Web Audio API, so the plugin is tiny and works offline. A mute toggle sits in the session header (🔔 / 🔕) and the choice survives reloads.
dsh plugin --profile web add dsh-task-sounds
Restart dsh web, then start a task or let the agent run: you'll hear
Click the 🔔 in the session header to mute; click again to unmute.
A pure-client Cordis plugin (browser half only). It registers one small entry
in the session header utilities slot (conversation.session.header.utilities)
and watches the conversation snapshot the framework provides through the
standard session kit:
snapshot.turnEnds — a new completed turn whose end time is recent triggers
the done chime (history replay is seeded as seen on mount, so reloading
or paging older messages never chimes);snapshot.pending — a new pending interaction (question / plan-review /
approval) triggers the question chime.Both signals are per-session and deduplicated, so each event chimes exactly
once. Audio is unlocked on the first pointer/key interaction to satisfy
browser autoplay policies, and the mute state lives in localStorage.
The DSH plugin market (dshmarket) reads its catalog from the curated awesome-dsh-plugin registry. To list this plugin there:
Push this repo to GitHub (any public repo). Add the dsh-plugin topic
to the repo. Note the registry's CI requirements: the repo must be
at least 1 day old and have 10 or more commits before the PR — so
create and push the repo first, then submit the PR later.
Publish to npm (npm publish from this directory — the package is
publish-ready; npm run prepack runs as a health check). The market
registry-verifies the npm package against the repo, so publish before
the PR.
Open a PR against awesome-dsh-plugin/awesome-dsh-plugin adding one
file data/plugins/henrytang2011win-coder__dsh-task-sounds.yml — the exact
content is in
awesome-dsh-plugin-entry.yml, already
filled in. Then, inside your clone of that repo, regenerate both READMEs
and commit them together:
npm ci
node scripts/generate-readme.mjs
The dsh.bundle manifest this package declares is exactly what the
registry checks for installability.
The site and every market instance pick the entry up automatically (usually within a day), after which anyone can install with:
dsh plugin --profile web add dsh-task-sounds
npm install # no runtime deps — peer react only
npm run prepack # health check used before publishing
The client half is plain JavaScript — no bundler needed. The module loader
resolves require("react") from the platform seed words, and the host half
(lib/index.js) is intentionally an empty apply.
MIT