How dsh-auto-review behaves
DeepSeek Harness invokes the plugin on the approval/request answerer chain. The plugin recognises reviewer requests by identity and delegates them, while the reviewer child is bounded by maxDepth and its non-empty reviewerTools allow-list. Each decision follows approval/asked to autoReview/verdict or autoReview/rejection, then approval/decided. Audit events are log-only and marked ignorable: true. An optional invariant companion checks that rejection markers and events correspond.
A deny reason is injected into the calling model's denied tool result. Fallback and never decisions add [auto-review-fallback] and [auto-review-never] markers. The rejection circuit breaker acts after three consecutive denials, or six of the last ten verdicts, per turn.
Configuring dsh-auto-review
DeepSeek Harness reads these Schemastery fields from cordis.yml. An id-targeted override replaces the complete row, so required keys must be restated.
| Key |
Default |
Purpose |
enableByDefault |
true |
Initial session state; /auto-review on|off creates a durable override |
toolsPolicy.default |
human |
Policy for unlisted tools |
toolsPolicy.overrides |
{} |
Per-tool ai, human or never policy |
riskRules |
[] |
Regex rules for reason, toolName or arguments |
reviewerModel |
inherit |
Reviewer model route |
reviewerTimeoutMs |
60000 |
Verdict deadline |
fallbackPolicy |
rejected |
Failure result: rejected, delegate or allow-once |
maxReviewsPerTurn |
10 |
AI-verdict budget |
maxFailuresPerTurn |
10 |
Reviewer-failure budget |
Other documented fields include reviewerProvider (fork), reviewerTools ([read, glob, grep]), reasonMaxChars (2000), reviewerGuidance, reviewerPolicyText and denyGuidance.
Commands and requirements
DeepSeek Harness provides /auto-review on, /auto-review off and /auto-review approve. The last is a one-shot override. The plugin targets DeepSeek Harness 0.1.1-rc.2, with peers >=0.1.0-rc.8 <0.2.0, and requires Node ^22.19.0 || >=24.0.0. It supports all platforms as a host answerer; the optional Web review panel uses the session-projection capability. The reviewer inherits the session agent's route unless reviewerModel is set.
Written from the project's own documentation and kept in sync with it. Where the two disagree, the source is authoritative — read the README on GitHub