菜单
Use for QEMU board, SoC, machine, memory map, boot path, FDT/ACPI, and IRQ topology modeling. Extends qemu-plan and qemu-rlcr-loop; board work must add or extend qemu-qtest coverage for verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use as the first step for any non-trivial QEMU task. Produces a small implementation or debugging plan under a .oh-my-qemu task workspace with acceptance criteria, scope boundaries, artifact policy, and verification gates.
Use for booting Linux in QEMU through either direct kernel loading or firmware and bootloader stages, selecting the path from task inputs while preserving provenance, boot logs, debug handoff, and verification evidence.
Use for QEMU peripheral, accelerator, MMIO, qdev, or SysBusDevice modeling. Extends qemu-plan and qemu-rlcr-loop; register-bank modeling must use QEMU's registerinfo framework and qtest verification.
Use for adapting a QEMU TCG host backend, including optional op support, constraints, register allocation, host code emission, qemu_ld/st, atomics, and vector ops. Extends qemu-plan and qemu-rlcr-loop.
Use for adding, reviewing, or debugging a guest ISA instruction in a QEMU TCG frontend. Extends qemu-plan and qemu-rlcr-loop; this skill only defines frontend decode/translation decisions.
Use as a QEMU flow primitive to summarize sanitized oh-my-qemu agent workflow feedback, draft improvement proposals, and file them with gh when approved.
| name | qemu-workflow-board-modeling |
| description | Use for QEMU board, SoC, machine, memory map, boot path, FDT/ACPI, and IRQ topology modeling. Extends qemu-plan and qemu-rlcr-loop; board work must add or extend qemu-qtest coverage for verification. |
Use this domain skill when changing a QEMU machine or SoC: CPU clusters, memory maps, reset vectors, firmware/direct-kernel boot, FDT/ACPI, interrupt topology, and board-level device wiring.
qemu-plan for non-trivial work..oh-my-qemu/<task-slug>/.qemu-rlcr-loop and keep
implementation/debugging inside RLCR rounds.qemu-build for target binary builds.qemu-qtest to add or extend board qtest cases for machine creation, memory-map probes, and representative IRQ/device wiring.qemu-debug and qemu-model-verification for boot/runtime evidence.No .plan/, .humanize/, root notes, or helper files in source directories.
Do not produce source code intended for QEMU upstream submission. QEMU currently declines contributions believed to include or derive from AI-generated content. Do not add DCO or review trailers.
A board model is topology and boot policy. A peripheral model is behavior.
The board should define:
The board should not emulate device register semantics.
Record these before implementation:
Use dependency order:
Reuse architecture helpers before hand-rolling boot code. For example, RISC-V boards should prefer existing reset-vector and direct-kernel helpers unless the real hardware requires a custom ROM path. If firmware intentionally receives no FDT, model that intentionally instead of generating a fake one.
Board-modeling work must be verified through qemu-qtest, not only through boot smoke. For every new board, SoC, memory-map change, reset-vector change, or IRQ topology change:
tests/qtest/<board-or-soc>-test.c case, or extend the closest existing board qtest;tests/qtest/meson.build under the correct architecture bucket;build/;.oh-my-qemu/<task-slug>/.If a board change cannot be covered by qtest, record the technical reason in the plan and use qemu-model-verification for the replacement evidence. A firmware boot log is supplemental evidence, not a substitute for qtest coverage.
At minimum:
qemu-qtest adds or extends a board case for the changed machine/SoC behavior;.oh-my-qemu/<task-slug>/logs/ when firmware compatibility is in scope;docs/devel/code-provenance.rst.docs/devel/codebase.rst.docs/system/gdb.rst.