How do I install the Orlix Tcti Debug skill?

Run npx skillmds@latest add rudironsoni/orlix-tcti-debug in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Orlix Tcti Debug safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Orlix Tcti Debug?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Orlix Tcti Debug free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Orlix Tcti Debug?

rudironsoni (@rudironsoni) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Orlix Tcti Debug by rudironsoni — Agent Skill

Name: Orlix Tcti Debug
Author: rudironsoni

Orlix Tcti Debug

OrlixTCTI debugging with native LLDB and kernel-owned C proof. Use for crashes, watchpoints, disassembly, ELF, Mach-O, instruction encodings, symbols, sections, relocations, and OrlixTCTI runtime corruption.

rudironsoni 4141343 3 files · 3.0 KB Updated Sep 17, 2026

File contents

OrlixTCTI Debug

Use native LLDB to locate the first incorrect state transition. Keep durable diagnostics and proof in the owning kernel subsystem.

Workflow

Reproduce the defect through its smallest owning suite and record the exact failing state. This step is complete only when the failure is repeatable or its nondeterminism is explicitly bounded.
Inspect the live process with native LLDB breakpoints, conditional breakpoints, hardware watchpoints, stepping, variables, registers, memory, expressions, disassembly, symbol lookup, and command-only stop hooks. This step is complete when the first incorrect transition and its writer are identified.
If native LLDB cannot expose the required state, add temporary C instrumentation inside the owning Orlix subsystem, guarded by its existing debug configuration and removable after diagnosis. This step is complete when structured C state identifies the transition LLDB could not observe.
Fix the root cause in its owning layer, then remove temporary instrumentation that is not a durable invariant. This step is complete when the original reproducer remains green without diagnostic scaffolding.
Add a KUnit regression for OrlixTCTI internals. Add or update kselftest when the defect changes Linux-visible behavior. This step is complete only when the owning tests fail on the defect and pass on the correction.

Ownership

OrlixTCTI invariants and runtime assertions belong in C under arch/orlix.
OrlixTCTI regression tests belong in KUnit.
Linux-visible behavior belongs in kselftest.
LLDB and LLVM binary tools observe execution. Their output does not replace behavioral proof.

Native LLDB Surface

Breakpoints and conditional breakpoints.
Watchpoints and hardware watchpoints.
thread step-in, thread step-over, and thread until.
frame variable, register read, memory read, and expression.
disassemble, image lookup, and command-only target stop-hook.

Hard Guardrails

Never use LLDB Python scripts, breakpoint command add --python-function, the LLDB Python API, Python callbacks, external-language callbacks, helper processes, or helper scripts in the debugging session.
Never move debugging logic outside the repository because it is temporary.
Never guess instruction encodings or treat debugger observations as final correctness proof.

Binary Tools

file <path>
xcrun llvm-objdump -d <path>
xcrun llvm-readelf -a <path>
Externally configured LLDB MCP lldb_command

---name: orlix-tcti-debugdescription: OrlixTCTI debugging with native LLDB and kernel-owned C proof. Use for crashes, watchpoints, disassembly, ELF, Mach-O, instruction encodings, symbols, sections, relocations, and OrlixTCTI runtime corruption.---# OrlixTCTI DebugUse native LLDB to locate the first incorrect state transition. Keep durablediagnostics and proof in the owning kernel subsystem.## Workflow1. Reproduce the defect through its smallest owning suite and record the exact failing state. This step is complete only when the failure is repeatable or its nondeterminism is explicitly bounded.2. Inspect the live process with native LLDB breakpoints, conditional breakpoints, hardware watchpoints, stepping, variables, registers, memory, expressions, disassembly, symbol lookup, and command-only stop hooks. This step is complete when the first incorrect transition and its writer are identified.3. If native LLDB cannot expose the required state, add temporary C instrumentation inside the owning Orlix subsystem, guarded by its existing debug configuration and removable after diagnosis. This step is complete when structured C state identifies the transition LLDB could not observe.4. Fix the root cause in its owning layer, then remove temporary instrumentation that is not a durable invariant. This step is complete when the original reproducer remains green without diagnostic scaffolding.5. Add a KUnit regression for OrlixTCTI internals. Add or update kselftest when the defect changes Linux-visible behavior. This step is complete only when the owning tests fail on the defect and pass on the correction.## Ownership- OrlixTCTI invariants and runtime assertions belong in C under `arch/orlix`.- OrlixTCTI regression tests belong in KUnit.- Linux-visible behavior belongs in kselftest.- LLDB and LLVM binary tools observe execution. Their output does not replace behavioral proof.## Native LLDB Surface- Breakpoints and conditional breakpoints.- Watchpoints and hardware watchpoints.- `thread step-in`, `thread step-over`, and `thread until`.- `frame variable`, `register read`, `memory read`, and `expression`.- `disassemble`, `image lookup`, and command-only `target stop-hook`.## Hard Guardrails- Never use LLDB Python scripts, `breakpoint command add --python-function`, the LLDB Python API, Python callbacks, external-language callbacks, helper processes, or helper scripts in the debugging session.- Never move debugging logic outside the repository because it is temporary.- Never guess instruction encodings or treat debugger observations as final correctness proof.## Binary Tools- `file <path>`- `xcrun llvm-objdump -d <path>`- `xcrun llvm-readelf -a <path>`- Externally configured LLDB MCP `lldb_command`

Frequently asked questions