Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

provider-runtime-adapter

Estrellas80

Forks5

Actualizado22 de junio de 2026 a las 10:53

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.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

muratgur

muratgur/ordinus

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

Explorador de archivos

2 archivos

SKILL.md

readonly

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.md status 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.

Más de este repositorio

mismo repositorio

lavish

muratgur/ordinus

Turn complex or visual agent responses into rich, reviewable HTML artifacts the user can annotate and send feedback on, using the lavish-axi CLI. Use when about to give a plan, comparison, diagram, table, code diff, report, or anything easier to grasp visually than as prose.

2026-06-2180

code-review-and-quality

muratgur/ordinus

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

2026-05-1980

code-simplification

muratgur/ordinus

Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

2026-05-1980

documentation-and-adrs

muratgur/ordinus

Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

2026-05-1980

electron-secure-boundary

muratgur/ordinus

Maintain Ordinus Electron security boundaries. Use when changing BrowserWindow options, main/preload/renderer responsibilities, privileged OS access, filesystem/database/process usage, or anything that could expose Electron or Node capabilities to renderer code.

2026-05-1980

idea-discovery

muratgur/ordinus

Explore a new feature, product idea, technical design, workflow change, or ADR candidate before committing to an implementation plan. Use at the beginning of product or architecture decisions when Codex should challenge assumptions, compare alternatives, inspect relevant docs or code, and help shape a clear recommendation without immediately writing an ADR or implementation plan.

2026-05-1980

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.md status 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.