# Dsh Plugin Creator

> Create a @deepseek-ai/dsh-* plugin package end-to-end — choose the extension point or capability seam, scaffold the package, implement the tool/hook/service, and run the repo gates. 触发：新增插件 / 加工具 / 开发 capability。

- Skill: `lovstudio/dsh-plugin-creator` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add lovstudio/dsh-plugin-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lovstudio/dsh-plugin-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: lovstudio (https://skillmd.com/u/lovstudio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lovstudio/dsh-plugin-creator

---


# DSH 插件工坊 · DSH Plugin Studio

Use this skill when adding or modifying a plugin (`@deepseek-ai/dsh-*` package) in this repository. It compresses the repo's extension-point map, package checklist, and testing policy into one ordered procedure. Each step names the authoritative file; the full grounded detail with per-step sources lives in `references/plugin-dev-sop.md`.

## Triggers

Activate when the user asks to add a plugin, package, capability seam, tool, hook, or model provider to this repo.

- "给本项目加一个插件" / "新增一个 capability" / "加一个模型工具" / "封一个 skill"
- "create a dsh plugin", "add a package", "scaffold a tool", "add an llm adapter"

Do not activate when the task only runs a skill, reviews code, or fixes a bug in an existing package without adding a contribution.

## Mental model

- Everything is a plugin; there is no privileged core (`docs/architecture.md`). Extending dsh means mounting a plugin beside the others.
- Two plugin forms (`packages/AGENTS.md` "Plugin exports"): a function plugin exporting `name`/`inject`/`Config`/`apply` with no default export, or a `Service` subclass with a default export. Never mix the forms.
- Every contribution is an effect: `ctx.effect()` / `ctx.on()` / `ctx.waterfall()`. A registry's `register()` returns the disposer, so teardown and hot-reload unwind automatically.

## Workflow

### 1. Decide the mechanism and home

1. Read `docs/architecture.md` "Where new behavior goes" and pick the mechanism: register a `ctx.tools` tool, listen on an `agent/*` / `tools/*` event, or define a new capability seam.
2. Check `docs/cookbook/extension-cookbook.md` "feature → mechanism map" for an existing mechanism before inventing one.
3. A swappable capability needs all three seam roles — Service Definition, Service Provider, Consumer — never one role alone (`docs/glossary.md` capability-seam).
4. Pick an existing group under `packages/<group>/`; a new group is a pure container.

### 2. Scaffold the package

Create `packages/<group>/<pkg>/` with `package.json`, `tsconfig.json`, `src/index.ts`, `src/types.ts` (types only), `src/invariant.ts`, and a bilingual `README.md` + `README.zh.md`. Follow the `package.json` invariants (private, version aligned to root, `type: module`, cordis in both peer and dev deps, exact `files` list) and register the package in exactly one aggregate — `tsconfig.host.json` or `tsconfig.client.json`. Full checklist: `docs/cookbook/adding-a-package.md`.

### 3. Implement the plugin

- Waterfall listeners must call `next()` to delegate; returning without it short-circuits (`docs/cordis-primer.md`).
- Typed events use declaration merging and carry an `@mode` tag.
- Name the current role from the role table (`Controller`/`Store`/`Registry`/`Provider`/`Backend`/…), not the first implementation.
- Deployment-varying choices are `Config` fields, not `DEFAULT_*` constants; explicit `resolve(request): Spec`, no hidden `?? default` in `run()`.
- Optional services use `ctx.get(name)`; cross-boundary ids use `Branded<B>`.
- For a tool, follow the `execute()` contract in `docs/cookbook/adding-a-tool.md`: typed args, one canonical JSON value, honor `exec.signal`, `output.render` owns prose, presenters stay pure.

### 4. Add the invariant

Every package owns `src/invariant.ts` registering its manifest name and checking one event or data relation, or stating `No runtime invariant:` with a reason (`packages/AGENTS.md`).

### 5. Test

Follow `docs/testing.md`: an HMR-safety test for every registry, per-file 100% coverage on `packages/*/*/src`, a non-unit REAL-composition test for any product-visible plugin, and a keyless snapshot in the same PR for any model- or user-visible change.

### 6. Document

Write the package `README.md` with service API, config, events, and extension points first, then the canonical `## Model Experience` and `## Known Limitations and Deferred Work` sequence. Pair it with `README.zh.md`, and add an Agent Note in the same PR for any non-trivial change.

### 7. Verify

```sh
pnpm install
pnpm run doc-sync
pnpm run constraints && pnpm run typecheck && pnpm run lint
pnpm run build && pnpm run hygiene
```

Then run only the checks the changed surface reaches — do not default to the full suite.

### 8. Commit

Split independent changes; label `kind/*` plus every material `area/*`; keep the Agent Note in the same PR.

## References

- `references/plugin-dev-sop.md` — the full grounded SOP with per-step sources.
- `references/skill-composition.md` — how this skill hands off to the `dsh-*` skill family.

## 通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 `task-specific`（仅本次）还是 `reusable`（可跨任务复用）。
2. `task-specific` 只修改当前任务，不改 Skill。
3. `reusable` 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. `reusable` 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。