orlix-implementation-boundaries

Use before implementing or triaging Orlix changes when ownership could involve OrlixKernel, OrlixMLibC, OrlixOS, OrlixHostAdapter, OrlixTerminal, upstream Linux, upstream mlibc, packages, product payloads, session APIs, or generated trees. Routes fixes to the correct layer and blocks wrong-layer shortcuts.

Jump to install

Repository: rudironsoni/OrlixSystem
Last source activity: June 7, 2026 at 17:42
Detected SKILL.md language: English
Stars: 0
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/rudironsoni/OrlixSystem --skill orlix-implementation-boundaries

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

Orlix Implementation Boundaries

Use this skill before changing code for non-trivial Orlix behavior, especially kernel/libc/package/runtime issues.

Routing

Linux semantics: OrlixKernel/Sources/ports/orlix, upstream Linux overlay paths, Linux-native drivers, boot, KUnit, or kselftest.

Libc behavior: OrlixMLibC/Sources and OrlixMLibC/Tests.

Delivered OS Kit, app-facing Linux session API, target-derived payload metadata, curated distribution policy, and package/rootfs assembly: OrlixOS.

Private iOS mechanics: OrlixHostAdapter/Sources.

iOS host UI, Ghostty rendering, and terminal presentation: OrlixTerminal.

Architecture truth: docs/architecture, docs/adr, and docs/reference.

Refusals

Do not:

edit generated upstream trees or disposable build output; reading generated trees for diagnosis is allowed;

add or change durable upstream patches before proving the lower owning layer is compliant and the patch is not hiding an OrlixKernel, OrlixOS, or toolchain mismatch;

modify upstream tests through durable patch stacks used by conformance schemes; move extra regressions to Orlix-owned tests;

move Linux policy into OrlixHostAdapter;

move libc behavior into OrlixKernel;

move syscall semantics into OrlixOS;

recreate a separate OrlixKit target/module; OrlixOS is the Kit;

hardcode product bundle identifiers or payload resource names in runtime code when they belong in project.yml or target metadata;

disable upstream package capabilities or invent package-specific linker/tool wrappers instead of fixing OrlixOS package-toolchain inputs;

add public runtime facades or shell/package management APIs;

restore retired local-kernel prototype paths.

Output

Before implementation, state the owning layer, why that layer owns the behavior, the files to inspect first, and the verification gate.