Agent Skills
› muratgur/ordinus
› provider-runtime-adapter
provider-runtime-adapter
GitHub设计本地AI CLI(如Codex、Claude)的Provider运行时适配器,确保集成中立且可观测。规范检测、认证、运行生命周期及事件解析接口,要求由Electron主进程管理流程,禁止渲染器执行任意命令,保障安全与状态持久化。
Trigger Scenarios
需要对接新的本地AI CLI工具
实现或修改Provider的运行生命周期管理
处理CLI进程的启动、取消及事件流
优化主进程与渲染器之间的通信安全
Install
npx skills add muratgur/ordinus --skill provider-runtime-adapter -g -y
SKILL.md
Frontmatter
{
"name": "provider-runtime-adapter",
"description": "Design Ordinus provider runtime adapters for local AI CLIs. Use when working on Codex, Claude, or future provider detection, auth status, run lifecycle, process management, cancellation, event parsing, output capture, or provider-neutral runtime interfaces."
}
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.
Version History
- f507122 Current 2026-07-05 18:19


