一键在 Manus 中运行任何 Skill

ipc-contract-design

星标80

分支5

更新时间2026年5月19日 06:42

Design and maintain Ordinus typed IPC contracts. Use when adding or changing window.ordinus APIs, ipcMain handlers, ipc channel names, shared request/response types, Zod schemas, preload bridge methods, or renderer calls into main process.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

muratgur

muratgur/ordinus

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

IPC Contract Design

Objective

Keep Ordinus IPC small, typed, explicit, and stable enough for the renderer to act as a safe UI over main-process capabilities.

Contract Shape

Define channel names in src/shared/ipc.ts.
Define shared request/response schemas and types in src/shared/contracts.ts.
Register handlers in main process modules, not renderer.
Expose renderer-facing methods through window.ordinus in preload.
Use feature-shaped methods such as workspace.selectFolder() instead of generic transport methods.

Workflow

Name the user-facing capability before creating an IPC method.
Add or update shared types and Zod schemas.
Add the IPC channel constant.
Implement the main handler and validate untrusted input.
Add the narrow preload method that invokes that channel.
Consume the method in renderer through window.ordinus.
Run typecheck, lint, and build.

Guidelines

Keep method names domain-oriented: app.getInfo, db.getStatus, workspace.selectFolder.
Prefer one explicit method over a generic catch-all channel.
Keep renderer errors user-readable and main errors diagnostic enough to debug.
When IPC responses drive renderer status, empty states, or error copy, align user-visible naming with DESIGN.md.
Do not add IPC for future features until there is an immediate caller.
Do not return secrets, raw environment details, or unrestricted local paths unless the UI truly needs them.

Anti-Patterns

window.ordinus.invoke(channel, payload).
Passing raw command strings from renderer to main.
Duplicating response shapes separately in main and renderer.
Letting renderer decide privileged policy such as workspace boundaries or executable paths.

同仓库更多 Skills

同仓库

provider-runtime-adapter

muratgur/ordinus

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.

2026-06-2280

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

name	ipc-contract-design
description	Design and maintain Ordinus typed IPC contracts. Use when adding or changing window.ordinus APIs, ipcMain handlers, ipc channel names, shared request/response types, Zod schemas, preload bridge methods, or renderer calls into main process.

IPC Contract Design

Objective

Keep Ordinus IPC small, typed, explicit, and stable enough for the renderer to act as a safe UI over main-process capabilities.

Contract Shape

Define channel names in src/shared/ipc.ts.
Define shared request/response schemas and types in src/shared/contracts.ts.
Register handlers in main process modules, not renderer.
Expose renderer-facing methods through window.ordinus in preload.
Use feature-shaped methods such as workspace.selectFolder() instead of generic transport methods.

Workflow

Name the user-facing capability before creating an IPC method.
Add or update shared types and Zod schemas.
Add the IPC channel constant.
Implement the main handler and validate untrusted input.
Add the narrow preload method that invokes that channel.
Consume the method in renderer through window.ordinus.
Run typecheck, lint, and build.

Guidelines

Keep method names domain-oriented: app.getInfo, db.getStatus, workspace.selectFolder.
Prefer one explicit method over a generic catch-all channel.
Keep renderer errors user-readable and main errors diagnostic enough to debug.
When IPC responses drive renderer status, empty states, or error copy, align user-visible naming with DESIGN.md.
Do not add IPC for future features until there is an immediate caller.
Do not return secrets, raw environment details, or unrestricted local paths unless the UI truly needs them.

Anti-Patterns

window.ordinus.invoke(channel, payload).
Passing raw command strings from renderer to main.
Duplicating response shapes separately in main and renderer.
Letting renderer decide privileged policy such as workspace boundaries or executable paths.