# Qemu Rst Documentation

> Use for writing or updating QEMU reStructuredText documentation, including board and machine docs, system docs, device docs, developer docs, boot command examples, feature status tables, Sphinx index/toctree updates, and docs build validation.

- **Type:** Skill
- **Install:** `agentstack add skill-processmission-oh-my-qemu-qemu-rst-documentation`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [processmission](https://agentstack.voostack.com/s/processmission)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [processmission](https://github.com/processmission)
- **Source:** https://github.com/processmission/oh-my-qemu/tree/main/.agents/skills/qemu-rst-documentation
- **Website:** https://processmission.github.io/oh-my-qemu/

## Install

```sh
agentstack add skill-processmission-oh-my-qemu-qemu-rst-documentation
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# QEMU RST Documentation

Use this workflow when creating or updating QEMU `.rst` documentation, especially board or machine pages under `docs/system/`, device documentation, developer documentation, and boot-command examples tied to modeled hardware.

## Composition

- Use `qemu-flow-plan` for non-trivial docs tied to modeling, boot, or verification work.
- Use `qemu-source-provenance`, `qemu-image-layout`, and `qemu-boot-run` as evidence sources for command examples and supported boot paths.
- Use `qemu-model-verification` for claims about what has been tested.
- For a simple typo or one-line docs fix, skip the full flow but still keep scratch artifacts out of source directories.

## Source-First Rule

Before writing, inspect the checked-out QEMU tree:

- nearby docs in the same directory, such as `docs/system//` or `docs/devel/`;
- the relevant `index.rst` or toctree file;
- existing board or machine docs for tone, section order, and command style;
- `MAINTAINERS` entries when adding a new documented area;
- the implementation, tests, and boot logs that prove the documented behavior.

Do not invent support status from code names alone. Document only behavior that is implemented, verified, or explicitly marked as a limitation.

## Board or Machine Page Shape

For a new board or machine document, prefer this structure unless nearby docs use a clearer local convention:

```rst

=======================

Overview
--------

Supported devices
-----------------

Boot options
------------

Direct Linux boot
~~~~~~~~~~~~~~~~~

Firmware boot
~~~~~~~~~~~~~

Known limitations
-----------------

Running tests
-------------
```

Include only sections that carry useful information. If the board has no firmware path, do not add a placeholder firmware section.

## Content Rules

- Name QEMU machine types exactly as the command line uses them.
- Keep command lines copy-pasteable and line-wrapped consistently with nearby docs.
- Show serial console choices explicitly when boot logs depend on a specific UART or chardev.
- Separate supported hardware from known stubs, unimplemented regions, and compatibility workarounds.
- For boot examples, include enough `-machine`, `-cpu`, memory, storage, kernel, firmware, DTB, initrd, and console options for reproduction.
- Avoid promising hardware accuracy from a boot smoke alone; tie claims to qtest, trace, or workload evidence when available.
- Avoid project-local paths. Use placeholders such as `/path/to/Image` or variables documented in the surrounding text.

## RST Rules

- Match the heading hierarchy and adornment style used by nearby QEMU docs.
- Use inline literals with double backticks.
- Use literal blocks with `::` for shell commands unless nearby docs prefer `.. code-block::`.
- Do not use Markdown fences in `.rst`.
- Keep toctree entries sorted or grouped according to the local index.
- Add the new page to the relevant `index.rst` or toctree; a standalone file is not enough.
- Do not add labels, cross references, or substitutions unless you verify they resolve in the local docs build.

## Validation

Run the narrowest available docs gate from the checked-out QEMU tree:

```bash
ninja -C build docs
```

If the build directory is not configured for docs, inspect available targets first:

```bash
ninja -C build -t targets | rg 'docs|sphinx'
```

At minimum, run `git diff --check` and inspect the rendered RST mentally for heading hierarchy, toctree inclusion, literal block indentation, and overlong command examples. Store any docs build logs under `build/agent//logs/` when the work is part of a larger QEMU task.

## Report

When done, report:

- docs files changed;
- index/toctree updates;
- source evidence used for feature and boot claims;
- docs build or fallback validation;
- any intentionally undocumented or unverified behavior.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [processmission](https://github.com/processmission)
- **Source:** [processmission/oh-my-qemu](https://github.com/processmission/oh-my-qemu)
- **License:** MIT
- **Homepage:** https://processmission.github.io/oh-my-qemu/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-processmission-oh-my-qemu-qemu-rst-documentation
- Seller: https://agentstack.voostack.com/s/processmission
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.