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/singula-ai/alego/cordis-plugin-developmentnpx skills add singula-ai/alego --skill cordis-plugin-developmentgit clone --depth 1 https://github.com/singula-ai/alegoWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/singula-ai/alego/cordis-plugin-development)<a href="https://agentmods.dev/skills/singula-ai/alego/cordis-plugin-development"><img src="https://agentmods.dev/badge/skills/singula-ai/alego/cordis-plugin-development.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $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 5d ago.
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 — 2 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.
- 5d ago First seen · 421 lines · 80 tokens per session scan A d80134069499
cordis-plugin-development is a skill published in the GitHub repository singula-ai/alego (109 stars, last pushed 9d 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 2 lines, and is treated as a copy.
Other skills, from other repositories
new-plugin
Factory line for adding a new HAR verification plugin (like playwright or rocketsim) for any framework — research the framework docs, build the template under src/templates/plugins/, register it everywhere, validate on a real repository, and open a PR. Use when asked to add/create a plugin, plugin template, or…
factory-line
Factory line for executing one station of a declared multi-station program — read the installed line bundle (har line status), plan parallel work into isolated HAR slots, run the cumulative gate with har line gate, and hand off for human review. Use when asked to "run a factory line", "run the next station", "execute…
v1-milestone
Factory line for executing one milestone of the HAR v1.0.0 refactor (epic os-factory/har#225) — plan the wave of parallel subagents, implement each issue in its own HAR slot, ship stacked PRs, run the fixture-e2e milestone gate, and hand off for review. Use when asked to "run the next v1 milestone", "work on v1.0.0"…
ctx
Codebase intelligence and evidence-driven governance with the indexed ctx CLI. Use when exploring an unfamiliar repository, locating symbols or callers, checking for existing implementations, estimating change impact, enforcing architecture rules, scoring a branch, finding hotspots or duplication, or analyzing…
ctx
Codebase intelligence and evidence-driven governance with the indexed ctx CLI. Use when exploring an unfamiliar repository, locating symbols or callers, checking for existing implementations, estimating change impact, enforcing architecture rules, scoring a branch, finding hotspots or duplication, or analyzing…
todos
This chat has a shared, live TODO plan — your tasks for the conversation, which the user also edits. Read this skill and reach for the todo tools whenever a request takes more than a couple of steps. It covers the plan model (group = task, items = its steps; loose items are the user's lane), how to work it: propose…