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/jiuge2467/dsh-studio/cordis-plugin-developmentnpx skills add jiuge2467/dsh-studio --skill cordis-plugin-developmentgit clone --depth 1 https://github.com/jiuge2467/dsh-studioWhat 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.
This is a copy
100% identical to cordis-plugin-development — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
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 jiuge2467/dsh-studio (11 stars, last pushed 15d ago), 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. It is 100% identical to cordis-plugin-development, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
audit
Use when asked to audit a codebase, or when the /audit command runs — find security, correctness, and quality issues across a project and report them organized by severity.
vuln-check
Use when asked to check for security vulnerabilities, or when the /vuln-check command runs — scan the project for known vulnerable dependencies and security anti-patterns.
bug
Use when the user reports a bug or asks to capture one — ask the minimal questions needed, then produce a structured bug report the team can act on.
pr-comments
Use when the user asks to review pull request comments, or when the /pr-comments command runs — fetch and analyze PR review comments on the current branch and summarize actionable items.
practice
Use when the user asks to practice programming with dsh-tui, or wants to level up a specific skill through guided exercises.
release-notes
Use when asked to generate release notes, or when the /release-notes command runs — derive user-facing release notes from the change history since the last release.