ddtcorex/dsh-maestro-review

Automated merge-request review for DeepSeek Harness: pluggable ReviewProvider, reviewer/auditor child agents on disposable worktrees, and GitLab webhook intake.

Automated merge-request review for DeepSeek Harness, built around a pluggable ReviewProvider abstraction (GitLab first, with other forges plugging in behind the same interface). An orchestrator spins up reviewer and auditor child agents against a disposable worktree of the MR, with model selection overridable globally (reviewModel) and per project mapping. A webhook intake receives GitLab MR events and enqueues reviews with dedup and retention. Review findings are written through the report_review_findings tool by tool-only review subagents (never free text), with history and signals tracked per MR. Review runs mount workspace-search, Magento/Hyva scan, query-log-stats and GitLab diff tools. A client half renders a settings/tunnel UI into DSH Web slots (notification copy stays local; delivery goes through the optional maestroNotifier service). The same pipeline also runs headless from GitLab CI through a shared reviewer project with a small bridge job, requiring no DSH host and no project mapping, with quick (diff-only) and on-demand deep modes.

Infrastructure & Deployment ★ 1
View on GitHub ↗

Install

dsh plugin --profile web add @ddtcorex/dsh-maestro-review

Copied verbatim from the README's 'Install' section. No placeholder is used. The README notes the package ships four Cordis patch rows (maestro-review-host, maestro-review-webhook, maestro-review-orchestrator, maestro-review-settings-rpc) served by this npm package, and that a release also ships a companion Docker image (ddtcorex/maestro-reviewer) that must stay in lockstep with the npm package.

Compatibility

The README states no Node or DSH version range. It installs into a profile (e.g. --profile web) and registers four Cordis patch rows served by the package: maestro-review-host (package root, bundled skills), maestro-review-webhook (intake), maestro-review-orchestrator (pipeline) and maestro-review-settings-rpc (settings UI). A client half is injected into DSH Web slots, and configuration is read through the shared namespaced settings store (~/.dsh/dsh-maestro-config/settings.json) with machine runtime state in a package-local sidecar. Development runs pnpm (verify/test/build); release also publishes the ddtcorex/maestro-reviewer Docker image.

Details

FAQ

Do I need a local checkout for CI review?
No. The README ('CI reviewer') states the same pipeline runs headless from GitLab CI: a shared reviewer project holds the secrets and image and serves any number of source projects through a small bridge job, with no DSH host and no project mapping needed. Quick runs are diff-only; on-demand deep clones the MR head.
How does it store its settings?
The README (Settings) says it reads configuration through the shared namespaced settings store (~/.dsh/dsh-maestro-config/settings.json) via the flat adapter in src/host/config-store.ts, over an embedded store copy generated from dsh-maestro-core with no runtime dependency, while machine runtime state stays in a package-local sidecar.
What must stay in lockstep when releasing?
The README (Release) says a release ships two artifacts that must stay in lockstep: the npm package and the ddtcorex/maestro-reviewer Docker image. Because the image installs the npm package from the registry rather than copying source, tagging a release alone is not enough to ship it to CI users.

Alternatives

MicroMilo/upstream-radar · coppynight/dsh-doctor · Jesse-njx/dsh-plugin-manager-registry

More plugins in Infrastructure & Deployment

Browse more in Infrastructure & Deployment

Guides for Infrastructure & Deployment plugins