Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/deepseek-ai/deepseek-harness/cordis-plugin-developmentnpx skills add deepseek-ai/deepseek-harness --skill cordis-plugin-developmentgit clone --depth 1 https://github.com/deepseek-ai/deepseek-harnessWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00080 | $0.04618 |
| Opus 5 | $0.00040 | $0.02309 |
| Sonnet 5 | $0.00016 | $0.00924 |
| Haiku 4.5 | $0.00008 | $0.00462 |
Grade A, and why
cordis-plugin-development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
8 near-identical copies found in the catalogue:
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 2 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
- cordis-plugin-development — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 421 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Develop Dynamic Cordis Plugins
First determine whether a capability belongs on Host or Client, then query the real interface before writing code. Never infer a complete API from a Service name, Event payload, Slot props, theme token, or example.
Standard workflow
- Call
cordis_inspect_listto obtain the Providers, methods, and schemas currently registered on Host and Client. - Select the smallest set of
cordis_inspect_querycalls needed to read the exact Services, Events, Builtins, Slots, Theme tokens, or Tools that the implementation will use. - For a new Plugin, design its first Package. To modify an existing Plugin, first use
cordis_inspect_self(pluginId, packageId)to read the base source and diagnostics. - Write plain JavaScript in
code.host,code.client, or both, then callcordis_define. - Call
cordis_runwith the finalpluginIdandpackageIdreturned by define. - Handle approval, waiting, Client loading, and render failures from the Run card, steering messages, or
cordis_inspect_self. - Use
cordis_stopto disable the Plugin temporarily. Usecordis_undefineonly when it is no longer needed.
Do not wait in the same turn for user approval or asynchronous browser results. After cordis_run returns awaiting-approval or starting, end the current Tool flow and wait for the system to report the final outcome through state updates and steering.
Tool usage guidance
| Tool | Use it when | Do not |
|---|---|---|
cordis_inspect_list |
Discover current Host/Client Providers and method schemas in one call; refresh after the runtime capability directory changes | Hard-code Provider names and skip list; treat a manifest as business data |
cordis_inspect_query |
Confirm exact Service methods, Event modes, Builtins, Slots, tokens, or Tool schemas before writing code | Use it instead of calling a real Service from the Plugin; assume a Client query will finish without a responding page |
cordis_inspect_self |
List current Plugins, inspect version pointers, or read exact Package source and runtime diagnostics | Fetch all source just to build a list; use it to modify or start a Plugin |
cordis_define |
Create a Plugin's first version or append an immutable Package to an existing Plugin; let the user preview the code first | Expect define to execute apply, request approval, or update current |
cordis_run |
Activate an exact Package; use run for first activation, restart, or rollback, and update to switch versions |
Use run to switch versions implicitly; treat pending or starting as success |
cordis_stop |
Pause current effects while preserving Packages, grants, and version pointers for later use | Use stop to mean permanent deletion |
cordis_undefine |
Permanently remove a Plugin and all of its Packages and clear historical business views | Call it while rollback, inspection, or restart is still needed |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 421 lines · 80 tokens per session scan A 01811d3ee9c0
cordis-plugin-development is a skill published in the GitHub repository deepseek-ai/deepseek-harness (204,393 stars, last pushed yesterday), licensed MIT. It adds 80 tokens to every session and 4,618 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
dsh-web-release
Release and publish the dsh-web monorepo (DSH Web GUI plugin family + skin collection) — bump all packages to one unified version, commit and tag (tags are cut from main after dev integration; dev is the integration branch), push the vX.Y.Z tag that triggers the GitHub Actions publish pipeline, and verify the npm…
dsh-web-community-plugin-developer
Develop a DSH community plugin and register it in the dsh-web Community Plugins index — author the plugin in the contributor's own repository following the official cordis bundle standard, add its entry to packages/dsh-community-plugins/community.json, regenerate the index with scripts/community-index, rebuild and…
dsh-web-skin-developer
Build a new skin for the dsh-web skin collection (DSH Web GUI) and publish it into the Skin Center — the first-level settings section — scaffold with scripts/dsh-skin-new, author the v2 skin.json manifest plus skin.css token remap (pure asset directory, no package.json, no build step), validate with scripts/dsh-skin…
dsh-web-pre-push-checks
Use before pushing, opening or updating a pull request, or claiming dsh-web checks pass. Selects the required repository gates and diff-specific generation, build, and GUI evidence.
dsh-web-documentation
Use when adding or editing dsh-web README files, docs, AGENTS.md instructions, user-facing configuration text, or bilingual documentation pairs.
dsh-web-sdk-compatibility
Adapt and repair dsh-web after an approved official @deepseek-ai SDK/runtime cohort is selected or installed. Compare public API, type, service-injection, module-table, protocol, and behavior changes; map every change to repository consumers; implement the smallest fixes and durable compatibility contracts; handle…