Preface

The plugin ecosystem of DSH emphasizes “everything is a plugin.” When using DSH for code inspection, fixing, and delivery in practice, common issues include: inspections relying on a single prompt, lack of unified review after fixes, and no re-runnable verification to confirm whether issues are truly resolved.

Here, we introduce @dsh-external/dsh-inspect. It is a DSH plugin that provides three tools—checkup, fix, and review—to organize the process of “identifying issues → fixing and delivering → quality review” into a simple closed loop.

What Is This

@dsh-external/dsh-inspect is a closed-loop inspection plugin for DSH. Its core capabilities are three tools:

  • checkup: Inspects issues and outputs a categorized issue list.
  • fix: Performs fixes based on tasks or issue lists and outputs a delivery report.
  • review: Reviews deliverables and can re-run verification for individual fixed items.

The owner clue in the documentation is omdsh-dev, and the package name and installation address use dsh-external. The paths for these two are inconsistent, so please verify against the actual repository, license, and source code before installation.

This plugin is orchestrated based on the official DSH workflow engine and has a runtime dependency on schemastery. It does not register in ctx.skills or interact with the TUI; tool triggering mainly relies on tool descriptions.

Core Features

checkup: Inspect Issues and Output a Categorized List

checkup is used to inspect target code or directories.

Input parameters:

  • target (required): The inspection target.
  • angles (optional): Inspection angles, allowing multiple angles to be specified.
  • context (optional): Background information.

Output is a categorized issue list, divided into severe, general, and suggested levels, including evidence and verification methods.

Its mechanism works as follows: Inspectors examine from different angles, and a red team stage attempts to refute issue declarations. Only issues that cannot be refuted are retained. This ensures the issue list is closer to verifiable evidence rather than based solely on static reading.

fix: Perform Fixes and Output a Delivery Report

fix is used to execute fixes and delivery.

Input parameters:

  • task (required): The fix task.
  • issues (optional): Can pass a JSON array of issues output by checkup.
  • acceptance (optional): Acceptance criteria.

Output is a delivery report, including completion status, inspection records, and delivery notes.

Its mechanism involves: first breaking down the task, then implementing in parallel, followed by adversarial checking and converging fix rounds. Each implementation step requires identifying root causes, making changes, and re-running reproduction verification. If an issue persists after a fix, further analysis continues instead of directly marking it as passed.

review: Review Deliverables and Verify If Issues Are Resolved

review is used to review deliverables.

Input parameters:

  • target (required): The review target.
  • dimensions (optional): Review angles.
  • context (optional): Background information.
  • fixed_issues (optional): A list of fixes requiring individual verification.

Output is a categorized review report and a passed result.

If fixed_issues are provided, review will re-run verification for each issue to confirm whether it is truly resolved. For fixes that persist, they can be reported to subsequent processes as severe issues.

Usable Individually or Combined into a Closed Loop

The three tools can be used individually:

  1. checkup: Only inspects, no fixing.
  2. fix: Only performs fixes and delivery.
  3. review: Only reviews deliverables.

They can also be combined into a closed loop:

  1. Use checkup to find issues.
  2. Pass the issue list to fix for resolution.
  3. Use review to review the deliverables.

If review fails, or if manual review is unsatisfactory, feedback can be fed as new issues back into fix until convergence.

Installation and Activation

The installation command is as follows, where <profile> should be replaced with a specific profile, such as tui, headless, web, or a custom profile:

dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git

After installation, restart the corresponding profile:

dsh --profile <profile>

After restarting, checkup / fix / review will be injected with the profile.

If dsh plugin prompts for allowBuilds, add the corresponding configuration in:

$DSH_HOME/profiles/<name>/pnpm-workspace.yaml

Update command:

dsh plugin --profile <profile> update

Uninstall command:

dsh plugin --profile <profile> remove @dsh-external/dsh-inspect

Typical Usage

Closed-Loop Usage

You can trigger the entire closed loop with a single sentence:

Use checkup to inspect ./src, feed the issue list to fix for resolution, then review to ensure quality

The execution path is roughly:

  1. checkup inspects ./src and outputs a three-tier issue list: severe, general, and suggested.
  2. fix receives the issue list and performs breakdown, fixes, and checks.
  3. review reviews the deliverables and outputs whether they pass.

If review finds that fixed issues persist, these issues can be used as new inputs to fix for further processing.

Using checkup Individually

Example:

Use checkup to inspect ./src, focusing on error handling and state synchronization

Key parameters:

  • target: ./src
  • angles: Inspection angles such as error handling and state synchronization
  • context: Optional background information

Using fix Individually

Example:

Fix ./src based on the issue list output by checkup, with the acceptance criterion being that main interfaces no longer throw uncaught exceptions

Key parameters:

  • task: The fix task
  • issues: JSON array of issues output by checkup
  • acceptance: Acceptance criteria

Using review Individually

Example:

Use review to inspect ./src, focusing on verifying whether the recently fixed issues are truly resolved

Key parameters:

  • target: ./src
  • dimensions: Review angles
  • fixed_issues: List of fixes requiring verification

Configuration and Dependencies

Optional Configurations

The plugin supports the following optional configurations:

subagentProvider
maxTotalAgents
plannerModel
workerModel
checkerModel
reviewerModel
mergerModel
redteamModel

These configurations adjust the subagent provider, maximum total number of subagents, and models used for planning, implementation, checking, review, merging, and red team roles.

Runtime Dependencies

The plugin has runtime dependencies on the official DSH workflow engine and schemastery.

peerDependencies declarations include:

@deepseek-ai/dsh-agent
@deepseek-ai/dsh-tools
@deepseek-ai/dsh-workflow
cordis

schemastery has been moved from peer to dependencies. The official Profile’s autoInstallPeers: false does not automatically install peers, so the plugin needs to be installed in a profile that provides a workflows provider.

The official base combination typically includes the required capabilities and usually does not need additional installation. If the profile combination lacks a workflows provider, such as the standard web combination, the plugin can still load normally. However, when calling checkup, fix, or review, it will throw a clear error with guidance instead of hanging the entire profile.

Runtime Environment

Node engine requirements are:

^22.19.0 || >=24.0.0

Erasable-only TypeScript syntax is also required.

Applicable Scenarios and Notes

Suitable Scenarios

This plugin is suitable for scenarios where DSH usage needs to be advanced from “single generation” to a closed loop of “inspection, fixing, and review,” such as:

  • Inspecting issues in a specific directory or module.
  • Performing fixes based on an issue list.
  • Reviewing fixed deliverables.
  • Verifying if individual fixes are resolved.
  • Re-entering feedback into review if it fails.

Pre-Use Notes

  1. The plugin runs with the permissions of the current dsh process. Please check the source code, dependencies, and license before installation.

  2. The license in the documentation is MIT; package.json declares private: true. It is still recommended to verify against the repository source code before actual installation.

  3. The GitHub repository clue in the documentation is https://github.com/omdsh-dev/dsh-inspect; the package name and installation address are @dsh-external/dsh-inspect. The paths for these two are inconsistent, so please verify the final repository address before installation.

  4. The DSH community directory is an independent site and has no official affiliation with DeepSeek or High-Flyer; it should not be referred to as an official app store.

  5. The documentation does not provide a usable directory page URL, so this article does not include a directory page link.

Brief Conclusion

The value of @dsh-external/dsh-inspect lies in consolidating the common inspection, fixing, and review processes in DSH into a single set of tools: checkup finds issues, fix resolves issues, and review verifies if issues are resolved.

It is suitable for installation in profiles that provide a workflows provider. It is recommended to verify the source code, license, and repository address before use.