name: "dsh-plugin-potential" description: "Evaluate whether any project could be packaged as a DeepSeek Harness plugin: inventory its capabilities, map them to plugin forms (skill provider, tools, policies, services, adapters), score fit, and produce a verdict report. Assessment only — never builds the plugin or modifies the target." status: proposal version: "0.6.0" date: "2026-08-24"

DSH Plugin Potential

Read-only assessment of one question: could this project's functionality live as a DSH plugin, and is it worth building? The deliverable is a verdict report the user decides on. This skill never writes plugin code, never scaffolds a bundle, never changes the target's code or config — evaluation is the entire job (its single write is its own report under the target's dsh-scan/). A credible ⛔ "keep it standalone" is a first-class result, same as a ✅.

Direction check (read first)

Two directions get confused; this skill is only the first:

• project → plugin (this skill): the project's capability becomes an extension other DSH users install. Worked example: dsh-lens itself — repo-analysis workflows packaged as a skill-provider plugin.
• project → DSH host (dsh-enhancement-analysis): the project migrates its pipeline onto DSH to gain its primitives.

The same repo can score differently in each direction. Run both if relevant; keep the reports separate; never blend verdicts across them.

Plugin forms (what "becoming a plugin" can mean)

Names verified against the DSH v0.1.0-rc source; re-verify on drift (DSH is pre-1.0, no compatibility promise):

1. Skill provider — package expertise as SKILL.md guidance + resources behind ctx.skills.registerProvider(); zero behavior code. Best fit for methodologies, workflows, analysis checklists.
2. Tool / capability plugin — expose the project's functions as agent-callable tools on ctx.tools (as dsh-web, dsh-shell, dsh-subprocess do). Best fit for libraries with clean input→output boundaries.
3. LLM adapter — ctx.llm.registerAdapter(): a model-provider integration becomes per-route swappable (dsh-llm-deepseek, dsh-llm-pi-ai).
4. Policy plugin — intercept waterfall events (agent/request, agent/request-error, llm/stream): retry, routing, metering, guard rules (dsh-llm-retry, dsh-token-meter, dsh-guard).
5. Service plugin on a stable key — caches, storage, notifications; consumers resolve by key, never import implementations.
6. Execution-world provider — swap ctx.fs / ctx.subprocess to move execution into a VM/container with zero tool changes.

Deployment shape (bundle anatomy): package.json + cordis.patch.yml (patch rows over a base profile) + src/index.ts with apply(ctx) + README; installable via dsh plugin --profile <name> add.

Locating the DSH source

Resolve the local checkout before fact-checking plugin forms, in order: the $DSH_ROOT environment variable; conventional checkout locations (~/git/deepseek-harness, ~/src/deepseek-harness); the GitHub repository deepseek-ai/deepseek-harness as last resort. Record the resolved path and commit in the report header; if only GitHub was available, say so.

Rubric (score every candidate capability, 1–5 per dimension)

Reverse-scored = lower cost/risk earns the higher score. State the reverse convention in the scorecard header so readers don't misread it.

Workflow

1. Gather inputs — optional accelerator: recon report at <project>/dsh-scan/recon-deep-<project>.md (from repo-recon, inside the target project). No report? Read the project directly: README + docs first, then entry points and the modules behind them. Focus: what the project does for its users, not how it's built.
2. Capability inventory — list the distinct functional units an outside agent could want (a fetcher, a linter, a workflow, a provider integration…), each with file:line evidence and a one-line description. This inventory, not the architecture, drives everything downstream.
3. Map to plugin forms — for each capability pick a best-fit form and an alternate from the six above. Capabilities that fit no form go to the "stays standalone" list — listed, not forced.
4. Score the rubric — per capability, per dimension, with a one-line justification for any score ≤2 or ≥4. Verdict per capability: ✅ 强候选 / 🟡 部分（state exactly which slice extracts and which stays）/ ⛔ 不适合.
5. Overall verdict + pilot pick — one sentence the user can act on, plus (if any ✅ exists) the ONE capability to pilot first and why.
6. Descriptive sketch only — for the pilot pick: plugin name, form, interface surface (what it registers, on which ctx key or event), install story, dependencies. Prose and tables. Never code, never scaffolding.
7. Honest costs + boundaries — language gap, rewrite size estimate, adapter count, rc-stage drift risk; plus what deliberately stays out and why.
8. Report from templates/report-template.md → <project>/dsh-scan/plugin-potential-<project>.md — inside the analyzed project (create dsh-scan/ if missing; a user-specified path overrides). Report carries the 未深入 list and the non-DSH findings section. Deliver Top findings + the verdict table to the user; wait for their decision.
9. Handoff — user approves a pilot? Building it is a separate later effort, outside this skill. The question was actually "should this project run on DSH"? Hand to dsh-enhancement-analysis. Either way, this skill stops at the report.

Rules

• Assessment only: no code, no scaffolds, no PRs, no changes to the target's code or config — ever, not even after user approval; the only write is the report under <project>/dsh-scan/; approval triggers handoff, not implementation
• Every claim carries file:line evidence (from the recon report or your own reading); DSH plugin-form facts re-verified against the source, never guessed
• Never oversell: ⛔ stays ⛔; costs stay explicit (language gap, rewrite size, dependency weight, rc-stage drift)
• Findings outside the plugin question (security, storage races, rendering drift, …) go to the non-DSH findings section, not the trash
• Reports in 中文; tables for mappings and scores; ≤300 lines
• Report header records: target repo path + branch + HEAD, recon report path if used, DSH baseline (resolved path + commit + date)
• DSH facts may drift between releases — re-check the source if the analysis is older than ~2 weeks or predates the latest tag