deepseek-harness-actionDeepSeek Harness plugin

Community GitHub Action for DeepSeek Harness — AI Code Review · CI Diagnosis · Auto Fix · Issue → PR

Stars
15
Forks
0
License
MIT
Last commit
Aug 26, 2026
Latest release
v0.8.1

Overview

Community GitHub Action for DeepSeek Harness — AI Code Review · CI Diagnosis · Auto Fix · Issue → PR

Original README

Cached from the project repository on Sep 3, 2026. This is source content, separate from the Agents.md review above.

View source

DeepSeek Harness for GitHub

CI Release MIT

中文

Run DeepSeek Harness directly from GitHub pull requests, issues, failed CI jobs, and maintainer-authored automations.

GitHub PR / Issue / CI  →  DeepSeek Harness  →  Review / Diagnose / Fix / Issue → PR

The Action starts a credential-isolated DSH worker, validates its structured result, and lets a trusted Controller publish comments or validated changes. This is a community project, not an official DeepSeek or GitHub product. It is maintained by @Lixiaoyiao.

Core capabilities

CapabilityWhat it does
Pull request reviewReviews new commits, publishes one summary, and adds high-confidence inline findings
General tasksAnswers repository questions or performs an explicitly authorized coding task
CI diagnosis and repairReads failed checks and logs; trusted workflows may validate and publish a fix
Issue implementationTurns an authorized Issue request into a validated branch and pull request
Composition modesKeeps the existing controlled tool profile by default and offers an experimental native DSH mode
Controlled toolsAdds exact profiles for native, fixed-command, typed Controller GitHub, MCP, Bundle, and Plugin tools
Structured resultsKeeps the schema-v1 audit envelope and can validate an optional maintainer-defined task result

v0.8.1 retains the experimental dsh-mode: native path over the locked DSH 0.1.1-rc.2 runtime and its official ecosystem composition. Native MCP servers, Profile Bundles, direct Cordis Plugins, repository Skills, Subagents, and Workflows retain DSH-native discovery and behavior. controlled remains the compatible default, so workflows that omit dsh-mode retain their existing composition, permissions, tools, budgets, receipts, and outputs.

Native mode is not an unsafe mode. It returns ownership of DSH's internal headless composition, capability graph, and model-visible inventory to DSH. Native MCP servers load through official @deepseek-ai/dsh-mcp-client; Bundles become official Profile layers; direct Plugins load through Cordis; and repository Skills, Subagents, and Workflows retain DSH-native behavior. Its definition-only extension schema declares owners and process requirements, not Action tools, grants, or per-tool budgets. Dynamic ecosystem tools appear only in runtime observedTools, and native toolPolicy never claims Controller effectiveTools.

The Action still owns trusted-workflow admission, exact package pins, lifecycle-script suppression, runtime inventory audit, Docker and .git-less workspace boundaries, the run-scoped DeepSeek credential proxy, GitHub credential isolation, actor/repository trust, validation and deferred writes, deadlines, cancellation, and secret redaction. Native remains Docker-only. Bridge network and read/write mounts are whole-worker capabilities, not per-extension or per-tool sandboxes. A user-configured GitHub MCP with its own credential is a trusted external extension whose direct effects do not receive the Controller Gateway's binding, revalidation, validation, or deferred-mutation guarantees. Controller-owned command.* and github.* capabilities remain a separate, mode-independent plane.

The v0.8.1 behavior-preserving hardening release centralizes byte-safe UTF-8 truncation, moves input-only failures to startup while retaining runtime checks, fails closed on unexpected filesystem errors, closes controlled/native configuration types, and adds generated public-input metadata plus stable denial reason codes. GitHubAuthorityGateway remains the only GitHub authority facade while its deadline, revalidation, mutation, reconciliation, and receipt helpers are easier to audit. This release does not add an Action-owned GitHub MCP backend, Session/Resume, another GitHub capability, or a DSH upgrade.

Live runs

These public runs show the comments and Actions logs produced by this repository.

ScenarioRun
PR review, including a rerun without duplicate commentsPR #3 · Actions run
Diagnosis based on failed checks and logsActions run
Fix and validation in trusted write modeActions run
Issue implementation followed by a pull requestIssue #4PR #5

Quick Start

Run the installer from the root of the repository you want to configure:

bash
npm create deepseek-harness-action@latest

Choose one of these modes:

  • PR Review creates .github/workflows/dsh-review.yml.
  • @dsh Coding Commands creates .github/workflows/dsh-commands.yml.
  • Both creates both workflow files.

For CI or another non-interactive environment, pass the mode explicitly so the installer never waits for stdin:

bash
npm create deepseek-harness-action@latest -- --mode both

For non-interactive use, omitting --dsh-mode keeps the compatible controlled default. The interactive flow asks explicitly; choose Controlled there unless native composition is intended:

bash
npm create deepseek-harness-action@latest -- --mode both --dsh-mode native

The installer creates .github/workflows/ when needed and refuses to overwrite an existing target workflow. It does not add secrets, commit or push changes, or open a pull request. Installer v0.2.0 is built only from the formal v0.8.0 release identity and generates workflows pinned to immutable commit 86fff4c4527694c7eefdc65c6cf7a633b5ea8cb1, not a candidate SHA, floating tag, or branch.

After installation, add DEEPSEEK_API_KEY under Settings → Secrets and variables → Actions. Open or update a non-draft pull request to trigger Review. For Coding Commands, put an @dsh command on the first line of an Issue or pull request comment. See Setup for the complete onboarding and security guide.

Manual installation

Add DEEPSEEK_API_KEY under Settings → Secrets and variables → Actions, then create .github/workflows/dsh-review.yml:

yaml
1name: DSH review
2
3on:
4  pull_request_target:
5    types: [opened, synchronize, ready_for_review, reopened]
6
7permissions:
8  contents: read
9  pull-requests: write
10
11jobs:
12  review:
13    if: github.event.pull_request.draft == false
14    runs-on: ubuntu-latest
15    timeout-minutes: 30
16    steps:
17      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4
18        with:
19          ref: ${{ github.event.pull_request.base.sha }}
20          persist-credentials: false
21          fetch-depth: 1
22      - uses: Lixiaoyiao/deepseek-harness-action@v0.8.1
23        with:
24          deepseek-api-key: ${{ secrets.DEEPSEEK_API_KEY }}
25          dsh-version: 0.1.1-rc.2

Open a non-draft pull request. The Action checks out only the trusted base SHA, reads the pull request through GitHub APIs, and never executes fork code.

For production, replace v0.8.1 with the full immutable release commit SHA. See Setup for permissions, pinning, checkout rules, and complete templates.

Common @dsh commands

Put the command on the first line of an Issue or pull request comment.

CommandPurpose
@dsh task --read <question>Explain code, inspect the repository, or answer a general question
@dsh task --write <task>Request a coding task; every write gate must still pass
@dsh reviewReview the current pull request again
@dsh diagnoseDiagnose failed checks and logs
@dsh fixRepair a same-repository pull request in trusted write mode
@dsh implementImplement an Issue and open a pull request

--write, fix, and implement request capabilities; they do not grant them. The workflow must explicitly enable write mode and provide Controller-run validation. See Usage for commands and automation, and Configuration for the gates.

Maintainers can change the trigger phrase, add label/assignee routes, filter actors or historical comments, select a base branch, and choose a deterministic branch template. These settings change routing and naming only; GitHub authority still comes from the Controller policy and workflow token scopes.

Security

  • The Agent receives neither the real GITHUB_TOKEN nor the real DeepSeek key. Only the Controller can call Action-owned github.* mutation APIs; an explicitly configured external GitHub MCP uses its own credential and authority as described below.
  • Repository content, diffs, issues, pull requests, comments, logs, model output, and tool output remain untrusted data.
  • Fork review uses a .git-less, credential-free worker and must check out only the trusted base SHA with persist-credentials: false.
  • Writes require a trusted same-repository context, authorized actors, Docker, allow-write: "true", non-empty fixed validation commands, and successful validation. Protected-path and Validation Integrity checks still apply.
  • Typed github.* mutations are exact-ID, entity-bound, deferred until Controller validation, and reconciled with bounded receipts. No arbitrary REST, GraphQL, URL, or credential pass-through exists.
  • Validation Integrity provides high-confidence weakening detection plus baseline replay for its supported entrypoints, scripts, test/config weakening, lock/toolchain controls, and known wrappers/interpreters; it is not complete cross-language dependency provenance or a formal proof.
  • Validation may use Docker bridge networking. On self-hosted or corporate-network runners, repository validation code may reach runner-accessible network services; use dedicated runners and runner-level segmentation/egress controls.
  • An approved Bundle, Plugin, or stdio MCP server is trusted worker code. Controlled ToolRuntime limits model-routed calls; native leaves routing and inventory to DSH. Neither model is a sandbox for extension startup, background work, or direct process I/O, and any bridge/RW capability applies to the whole worker.
  • github.* uses the Controller GitHub Gateway. A separately configured GitHub MCP uses its own external credential and is outside the Gateway's binding, revalidation, validation, and deferred-write guarantees.

Read the complete Security policy before enabling write mode, host execution, network access, or third-party extensions.

Documentation

GuideContents
Setup · 中文Installer, manual setup, Secret, permissions, safe checkout, and templates
Usage · 中文@dsh commands, tasks, review, diagnose, fix, implement, and automation
ConfigurationInputs, permission profiles, tools, validation, extensions, and outputs
Architecture · InvariantsComponent ownership, authority boundaries, and stable system invariants
TroubleshootingDenials, Docker, timeouts, cancellation, validation, and extension failures
Security policyTrust model, credential boundaries, network behavior, and known limitations
Extension contractsDeep technical contracts for MCP, Profile, Bundle, Plugin, ToolRuntime, and receipts
Maintainer release guideLocal checks, Core E2E, release canary, version updates, and publishing
Contributing · ChangelogDevelopment workflow and release history

Development

Node.js 24 is required.

bash
npm ci
npm run check

See CONTRIBUTING.md. The Marketplace dist/ bundle is committed for releases and must not be edited by hand.

License

MIT. Third-party licenses are listed in THIRD_PARTY_NOTICES.md and BUNDLED_DEPENDENCIES.md.

DeepSeek Harness supplies the headless runtime and official extension mechanisms. The GitHub integration also draws on the MIT-licensed Claude Code Action patterns and the execution/publication separation described by Codex GitHub Action; exact attributions are recorded in the third-party notices.