DeepSeek Harness Plugin Hub

发布与管理完整 Harness Profiles,发现适合你的插件。

探索

插件目录环境预设文档中心动态

社区

发布插件联系我们报告问题

相关链接

Plugin Hub GitHubDeepSeek Harness 官方项目系统状态隐私说明
© 2026 DeepSeek Harness Plugin HubPowered byPaxTech

独立、非官方社区项目,与 DeepSeek 官方无隶属、授权或背书关系。

Pr Watch — DeepSeek Harness 插件(DSH Plugin)
DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins
P

dsh-pr-watch

Pr Watch

DeepSeek Harness 插件:报告你创建的 pull request 自上次检查以来的变化——已合并、已关闭或已变得过时。

插件会安装到这里;不确定时保持 web。

npx -y @deepseek-ai/dsh plugin --profile web add github:Shyboy0499/dsh-pr-watch#00d98fa286dae02db38fba7e7ea5378031c42eb6
README兼容性版本

兼容性与来源证明

Pr Watch 以 dsh-pr-watch 发布,当前版本为 0.1.0。Plugin Hub 会校验它的 manifest,并保存精确安装来源,便于复现安装结果。

DSH 兼容范围
*
运行环境
any
发布来源
github
Registry 更新时间
2026/9/14

版本

0.1.0stable
2026/9/14

相关插件

正在加载相关插件…

最新版
0.1.0
DSH
*
HMR
重启进程
Tree shaking
未声明可安全裁剪
解包体积
未提供
文件数
未提供
Surface
any
许可证
MIT
发布源
github
GitHub
★ 1
周下载
0
最近提交
2026/9/20
查看源码 ↗
README Badge

点击下方 Badge 复制 Markdown,粘贴到 README 即可。

这是你的 Plugin?认领权益 · 优先安全扫描

验证 package.json 声明的 GitHub 仓库,即可管理这个公开页面。认领后,Hub 会优先安排当前版本的安全扫描,并在通过后公开展示结果。

认领这个 Plugin →
报告问题

相关插件

继续浏览 developer-tools 分类下经过校验的插件。

Web App@deepseek-ai/dsh-web-appdsh 浏览器界面捆绑包:位于 dsh-base 之上的 Web 补丁层,加上运行时粘合插件(提供前端 dist、Web 界面提示符、bash 运行时变量和 URL 行)Sdk Minimal@deepseek-ai/dsh-sdk-minimal独立的最小 SDK 配置包:JSON-RPC、一个 DeepSeek 适配器、持久化 Shell 和 JSONL 会话Sdk App@deepseek-ai/dsh-sdk-appdsh SDK 配置包:基于 dsh-base 提供 stdio JSON-RPC 服务和进程生命周期管理Subagent Codex@deepseek-ai/dsh-subagent-codex基于官方 app-server 协议的一次性 Codex 子代理提供程序

README

dsh-pr-watch

Reports what changed in your authored pull requests since your last check — merged, closed, or gone stale.

dsh-pr-watch is a dependency-free DeepSeek Harness (dsh) plugin that exposes one agent tool, pr_watch. It tracks every pull request you authored, across all repositories — including ones you have never cloned — and tells you only what changed since you last looked.

Status: pre-release. The design and implementation plan are complete; the implementation is in progress. Nothing is published to npm yet, so the install command below does not work today. It is included so the intended path is clear, not because it is ready.

  • Design: docs/superpowers/specs/2026-09-10-dsh-pr-watch-design.md
  • Plan: docs/superpowers/plans/2026-09-10-dsh-pr-watch.md

Why

An agent has no memory of your last check, so every status question gets re-derived from scratch. That is fine for one pull request and useless for thirty. The friction is not seeing your pull requests — it is re-checking the same ones over and over and having to remember what the state was last time.

pr_watch closes that gap by storing a snapshot and reporting deltas.

Features

BehaviourDetail
MergedA pull request you authored was merged
Closed without mergeDistinguished from a merge, not lumped in with it
Became staleNo activity for 14 days (configurable)
Newly noticedA pull request appeared that the snapshot did not know about
Uncloned repositoriesTracked by owner/repo#number, so a local checkout is never required
Reported once, then silentMerges and staleness never repeat on later checks

How it works

The naive approach — fetch open pull requests, diff against the snapshot — cannot work. The moment a pull request merges it leaves the open list, so a bare diff cannot tell "merged" from "closed unmerged", and an empty result looks identical to a failed gh call.

So pr_watch fetches in two phases:

  1. Enumerate every open pull request you authored, in one call.
  2. Resolve each snapshot entry that left that set, individually, to learn its terminal state.

Only pull requests that actually changed incur a second call — normally zero or one per check.

Installation

dsh plugin --profile web add dsh-pr-watch

Not yet published — see the status note above.

Requires the GitHub CLI (gh) on your PATH, authenticated:

gh auth login

dsh-pr-watch stores no credentials of its own. It relies entirely on gh's own keyring-backed authentication.

Usage

Ask the agent to check your pull requests, or call the tool directly.

{
  "staleDays": 14,
  "all": false
}

Typical output:

✅ Merged (2):
  octo/repo#41 — Add Russian locale (last activity 1 day ago)
  octo/repo#38 — Fix broken link (last activity 3 days ago)

⏳ Became stale (1):
  octo/repo#29 — docs: clarify install steps (last activity 21 days ago)

🆕 Newly noticed (1):
  octo/repo#44 — Add MCP server entry (last activity today)

Run it a second time and only genuine changes appear. A merge reported today is never reported again.

Parameters

ParameterTypeDescription
staleDaysnumberDays without activity before a pull request counts as stale. Defaults to 14.
allbooleanList every open pull request instead of only what changed. Useful on first run, where everything is "newly noticed". Defaults to false.

Configuration

v1 exposes everything through the tool's two parameters above. It reads no settings file, so there is nothing else to configure yet.

SettingDefaultSettable in v1Purpose
staleDays14Yes — tool parameterDays without activity before a pull request is reported stale
pruneDays90No — compile-time constantDrop entries that reached a terminal state this long ago
Snapshot path$DSH_HOME/pr-watch/snapshot.jsonNo — derived from the environmentFalls back to ~/.dsh/pr-watch/snapshot.json when DSH_HOME is unset

Two further keys appear in the design doc — ignoreRepos and a user-settable snapshotPath — but they are deferred to v2 and not implemented. Honouring them needs a settings loader that does not exist yet, and ignoreRepos additionally needs a rule to evict ignored entries from the snapshot: an entry dropped from enumeration but kept in the snapshot would never resolve, so every check would report it as unresolved forever. See the plan's refinements section for the full reasoning.

Behaviour notes

  • Staleness fires on transition, and only once. A pull request that has been stale for weeks is reported the first time it crosses the threshold, then stays quiet. If it sees new activity, the staleness clock resets and it can be reported again later.
  • A failed fetch writes nothing. If gh fails partway through, the snapshot is left untouched so pending changes are not silently marked as seen.
  • The snapshot is written atomically (temporary file, then rename), so an interrupted write can never leave a truncated file that reads as "everything vanished".
  • A corrupt snapshot is quarantined, never discarded. It is moved to snapshot.json.corrupt-<n> and the tool says so in its output. The alternative — silently resetting — would lose pending changes with no way to tell that from "nothing happened".

Known limitations

A pull request opened and merged between two checks is invisible. It is absent from the open set (it already merged) and absent from the snapshot (it did not exist when the snapshot was taken), so neither phase sees it. This is a direct consequence of enumerating by current state rather than by activity window, and it only becomes likely if you check infrequently. The fix — an activity-window query — is recorded in the design doc as a v2 candidate.

New comments and reviews are not reported. An outcome like "merged" is not the same as "a maintainer replied asking for changes", and the latter is often what should change your next action. It is deferred rather than overlooked: it needs a separate data source and a per-entry comment cursor.

CI status is not reported.

One snapshot per GitHub identity. Running under a second account would share a snapshot and produce spurious "newly noticed" entries.

Development

pnpm install
pnpm run build        # tsdown → lib/
pnpm test             # vitest — no network access
pnpm run lint         # oxlint
pnpm run typecheck    # tsc --noEmit
pnpm run format       # prettier --write .

The test suite makes no network requests. delta.ts is pure — no filesystem, no network, no clock — so every state-transition rule is a fixture-driven unit test with no mocking.

License

MIT