Plugins for DSH can register tools, skills, services, and routes with the host. Successful registration does not mean the model will invoke them. A plugin may quietly register three tools at startup, only two of which have never been invoked in the past dozens of sessions. The code exists, has been tested, and loads normally; it is simply that no task ever reaches them. There is an even more subtle class: a plugin only wraps an existing host method, registers nothing, so from the manifest it looks as if it does nothing, while in reality it is actually taking effect.

consumer_audit turns this into a verifiable list. It reads the composition lines of the active profile, resolves which package each line contains, statically scans that package’s registration sites, then counts how many times each registered tool and skill appears in session logs under DSH_HOME, and finally reports those with a count of 0.

Installation and Enablement

Install the plugin with the following command:

dsh plugin --profile <profile> add github:qimen039-code/dsh-consumer-audit

After installation, DSH must be restarted for the tool to appear in the model tool table.

Prerequisites and environment:
* Node 22.15 or a newer version is required. DSH session logs are stored in a multi-frame zstd format, which older versions cannot read.
* The DSH loader resolves plugin packages only from the active profile’s own node_modules. Packages placed under profiles/node_modules will not take effect and can cause startup failure.

Core Features

The plugin provides the following capabilities:

  • consumer_audit: performs the audit check.
  • consumer-audit: the corresponding skill.

Usage

Because session logs are in a multi-frame zstd format, the model cannot open them directly with a regular text-reading tool. The plugin provides a dedicated evidence retrieval interface and code entry points.

Evidence retrieval interface:

{"action": "evidence", "name": "some_tool", "limit": 5}

Code invocation example:

import { collect } from "dsh-consumer-audit/collect";
import { ablation } from "dsh-consumer-audit/audit";

Report Content and Interpretation

The report contains findings (issues discovered) and notes (descriptive information). The report does not include semantic judgments; it provides observed data only.

Finding types:
* tool_never_invoked: The tool is registered but has never been invoked in the scanned logs.
* skill_never_loaded: SKILL.md exists on disk but the skill has not been loaded in a session.
* prompt_only_capability: Only a prompt is registered.
* row_without_capability: The line is mounted and the package resolves, but nothing is registered.
* duplicate_prompt_section: Two packages register prompt sections with the same name.
* package_unresolved: The package is neither in the profile nor part of the set shipped with the harness.
* tool_never_delivered: It was invoked, but every return included isError.
* skill_never_delivered: Same as above, for a skill.

Notes:
* The consumed field in the report records three layers of data: attempts / failed / succeeded, only up to the “delivery” layer.
* Registration sites in the source code only indicate that a capability was declared; they do not prove that it works.
* Invocation counts describe only the scanned logs. Unscanned profiles and invocations before the log window are read as unused.
* First-party packages (prefixed with @deepseek-ai/) are shipped with the harness, are not searched, and are recorded as shipped in the report.
* Packages that wrap existing service methods do not register new capabilities, so invocation counts cannot determine their effect.

Applicable Scenarios

  • After installing a new plugin, verify whether it is actually invoked in sessions.
  • When you suspect a feature has been implemented but is not properly wired in.
  • Before cleaning up a profile, confirm that removing a capability will not have an impact.
  • When writing your own plugin, identify which parts of the code are never invoked.

References