Use cases

DSH plugins for GitHub Integration

Issues, pull requests, repositories and release workflows.

This directory lists 1 DeepSeek Harness plugin for GitHub Integration. Their verification levels run L1 0, L2 0, L3 1, L4 0, L5 0: no listing here has been installed or run in a sandbox, so none claims L4 or L5. 0 have passed an automated security scan, and the other 1 are marked unverified rather than safe. Declared compatibility targets are ^0.1.5-rc.1 1. Together these 1 listings carry 3,650 GitHub stars, led by Better Sidebar at 3,650. Licences are mainly MIT 1, and the code is written mostly in TypeScript. Every entry records its source repository, licence, declared harness target and a copy-ready install command; the most recently checked is Better Sidebar (2026-09-18). A verification level measures how far the install path was exercised — it is not a safety guarantee, so read the source before you install.

GitHub is where most DSH plugin sources and most team work already live, so this use case covers repository browsing, issue and pull request workflows, review comments, and release automation driven from a session. The published listings here lean local-git rather than full GitHub API clients: the useful ones surface diffs, history and commit state beside the chat so a change can be inspected before it leaves the machine.

The useful distinction is read versus write. Browsing a repository or reading a diff needs almost no trust. A plugin that comments on issues, opens pull requests, or pushes branches should be scoped to a single repository and use a token you can revoke. Treat any tool that wants a broad repo scope as a reason to pause, not a convenience.

How to evaluate

Check three things before you install. First, write surface: which git or GitHub verbs the plugin actually exposes, and whether any of them can push. Second, token handling: credentials should live in a profile file or environment the model cannot dump wholesale into the transcript. Third, reviewability: a commit, a staged patch, or a visible diff is reviewable; a silent git push is not.

Plugins that only read repository state are the safe floor. Plugins that mutate remotes should show the exact command or API call before it runs, and should default to a dry run or an approval gate.

What good looks like

A strong GitHub-facing plugin keeps the remote as an explicit step: the agent proposes a change, you see the diff, then it commits and optionally pushes. Status is honest about what is staged versus committed versus pushed. Issue and PR helpers either work against a pinned token with a narrow scope, or they refuse to write at all and only prepare a patch for you to open yourself.

Sparse coverage in this directory is not a defect of the category — it is a signal. Full GitHub API clients with issue automation are still rare in the DSH ecosystem; most “integration” today is local git plus a browser tab.

Common failure modes

The usual failure is a plugin that claims “GitHub integration” while only cloning a repo and running shell commands. The second is a write path that embeds a PAT in config the model can read. The third is treating stars or commit frequency as proof the integration is safe: community size does not narrow a token’s scope for you.

Install order and boundaries

Start with read-only, minimal issue scope. Write actions — comments, PRs, merges — belong in an isolated profile first, then in the daily path once you have seen what they do.

1 plugin

Better Sidebar

omdsh-dev