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/muratgur/ordinus/provider-runtime-adapternpx skills add muratgur/ordinus --skill provider-runtime-adaptergit clone --depth 1 https://github.com/muratgur/ordinusWrote 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/muratgur/ordinus/provider-runtime-adapter)<a href="https://agentmods.dev/skills/muratgur/ordinus/provider-runtime-adapter"><img src="https://agentmods.dev/badge/skills/muratgur/ordinus/provider-runtime-adapter.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 | $0.00054 | $0.00456 |
| Opus 5 | $0.00027 | $0.00228 |
| Sonnet 5 | $0.00011 | $0.00091 |
| Haiku 4.5 | $0.00005 | $0.00046 |
Grade A, and why
provider-runtime-adapter 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.
How it starts
The opening of the file, as written. The whole thing — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Provider Runtime Adapter
Objective
Keep local AI CLI integrations provider-neutral, observable, and owned by Electron main process.
Adapter Boundary
Provider adapters should hide provider-specific CLI details behind a shared runtime shape. Start with only the methods needed by current product behavior.
Preferred concepts:
detect: determine whether the CLI is available.getAuthStatus: report whether the provider appears ready.startRun: launch one user-approved run.cancelRun: stop an active run.parseEvents: normalize stdout/stderr into observable run events when needed.
Do not implement all concepts until the product flow needs them.
Runtime Rules
- Run provider processes from Electron main process or a main-owned worker.
- Do not allow renderer to pass arbitrary shell commands.
- Store run state and events durably only after the run model is intentionally designed.
- Normalize provider behavior without erasing useful provider-specific diagnostics.
- Treat Codex and Claude as peers. Do not let the first provider shape the whole architecture.
- When provider state or events are shown in renderer UI, align user-visible statuses and event labels with the status vocabulary in
DESIGN.md.
Workflow
- Define the user action that needs provider runtime support.
- Add the smallest provider-neutral interface needed for that action.
- Implement detection or process behavior in main process.
- Validate executable paths, workspace boundaries, and allowed arguments in main.
- Stream or record events in a way the UI can explain clearly, using
DESIGN.mdstatus language for user-visible states. - Support cancellation before adding more automation.
- Run typecheck, lint, build, and a runtime smoke test.
Red Flags
- Renderer sends raw command strings or CLI args.
- Provider-specific flags leak into UI state too early.
- Long-running process state exists only in memory when the UI needs to recover it.
- A provider integration assumes a single operating system.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 51 lines · 54 tokens per session scan A be5792f493be
provider-runtime-adapter is a skill published in the GitHub repository muratgur/ordinus (110 stars, last pushed yesterday), licensed MIT. It adds 54 tokens to every session and 456 once invoked, about $0.0003 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
electron
Use when building, hardening, or shipping a cross-platform Electron desktop app — main/renderer/preload process model, typed contextBridge IPC, locking down nodeIntegration/contextIsolation/sandbox/CSP, or packaging with signing and auto-update. NOT a Rust-backed shell on the native webview (that is tauri), nor the…
ai-deployment-patterns
Guides expert-level ai deployment patterns implementation: ai-ml and devops decision frameworks, production-ready patterns, and concrete templates for ai deployment patterns workflows. Use when the user asks about ai deployment patterns, ai deployment patterns configuration, or ai-ml best practices for ai projects. Do…
automation-architect
Workflow automation design using Zapier, Make, and n8n covering trigger-action architecture, multi-step automation workflows, error handling strategies, personal versus business automation patterns, ROI calculation, and a library of common automation recipes. Use when the user asks about automation architect, related…
sales-icp
Build a comprehensive Ideal Customer Profile (ICP) for any B2B business - firmographic, technographic, behavioral, pain-point, budget, and channel dimensions, plus negative ICP, 100-point scoring rubric, buyer personas, prospecting playbook, and a draft first-outreach message that inherits sales-outreach Phase 0…
sales-qualify
Qualify a sales lead using BANT (Budget/Authority/Need/Timeline) and MEDDIC (Metrics/Economic Buyer/Decision Criteria/Decision Process/Identify Pain/Champion) frameworks against publicly available signals using OSINT only - no scraping of platforms whose ToS forbid it (LinkedIn §8.2, Glassdoor, G2, Capterra…
ai-evaluation-patterns
Guides expert-level ai evaluation patterns implementation: ai-ml and testing decision frameworks, production-ready patterns, and concrete templates for ai evaluation patterns workflows. Use when the user asks about ai evaluation patterns, ai evaluation patterns configuration, or ai-ml best practices for ai projects.…