OpenParable
Skip to content
← Back to skills

Guide Maintenance

Documents
guide-maintenance

Guide Maintenance is an Agent Skill for documents published in the microsoft/openvmm repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.

Maintain the OpenVMM Guide and its code-sync mapping. Load when: (1) adding, removing, or moving Guide pages, (2) adding new device crates or CLI args that need doc coverage, (3) updating the doc-code-sync mapping table, or (4) auditing Guide freshness against code changes.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/microsoft/openvmm/blob/HEAD/.github/skills/guide-maintenance/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/guide-maintenance, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

Guide Maintenance Skill

Procedures for keeping the OpenVMM Guide (Guide/src/) in sync with the codebase. The doc-code-sync mapping table is maintained in this skill file; .github/instructions/doc-code-sync.instructions.md contains the instructions and heuristics that are automatically loaded during Copilot code review on *.rs and Cargo.toml files.


Adding a New Guide Page

1. Choose the right location

Content typePath pattern
Emulated device referencereference/emulated/<DeviceCategory>/<device>.md
VMBus device referencereference/devices/vmbus/<device>.md
Virtio device referencereference/devices/virtio/<device>.md
Device backend referencereference/backends/<category>.md
Architecture deep-divereference/architecture/openvmm/ or reference/architecture/openhcl/
CLI / managementreference/openvmm/management/
Developer tooldev_guide/dev_tools/<tool>.md
Test frameworkdev_guide/tests/

2. Create the page

  • Follow the style in .github/instructions/guide-docs.instructions.md
  • Include a brief overview, key concepts, and links to relevant rustdoc
  • Reference crate names in backticks
  • Use relative paths from repo root when pointing at code

3. Update SUMMARY.md

Add the page to Guide/src/SUMMARY.md in the correct section. Pages with content get a path; placeholder topics for future work get an empty link ().

- [Page Title](./reference/path/to/page.md)

4. Update the doc-code-sync mapping

This is the critical step. Add a row to the mapping table in this file:

| `path/to/code/crate/` | `reference/path/to/page.md` |

Also add a bullet to the "What to Flag" section if the new page covers a category of change (e.g., "New frobulator variant added → update frobulator.md").


Removing or Moving a Guide Page

  1. Update or remove the entry in Guide/src/SUMMARY.md
  2. Remove or update the corresponding row in the doc-code-sync mapping table
  3. Check for cross-references from other Guide pages (grep for the old path)
  4. If moving: ensure the SUMMARY.md link and the mapping table both point to the new location

Adding a New Device Crate

When a new crate is added under vm/devices/:

  1. Does it need a Guide page? If it's a user-visible device or backend, yes. Internal plumbing crates (e.g., *_resources, *_protocol) usually don't need their own page but should be mentioned in the parent device page.

  2. Create the page following the "Adding a New Guide Page" procedure above.

  3. Update the mapping table with the crate path → Guide page.

  4. Update the "What to Flag" list if the new crate introduces a new category of reviewable change.


Adding or Changing CLI Arguments

When openvmm/openvmm_entry/src/cli_args.rs changes:

  1. Update Guide/src/reference/openvmm/management/cli.md
  2. The CLI page has a disclaimer that it may be out of date — keep it honest, but still update the page when making changes
  3. New arguments should include: flag syntax, description, default value, and any interactions with other flags

Auditing Guide Freshness

To check whether the Guide is in sync with the code:

  1. Scan the mapping table in this file
  2. For each row, check whether the Guide page content still matches the code:
    • Crate names still correct?
    • Struct/enum names still exist?
    • Behavioral descriptions still accurate?
    • Links to rustdoc still resolve?
  3. Check Guide/src/SUMMARY.md for placeholder links () — these are topics that need content. Prioritize ones whose code areas have been actively developed.

Quick audit commands

# Find Guide pages that reference a crate name
grep -r "crate_name" Guide/src/

# Find placeholder topics (empty links) in SUMMARY.md
grep '()\s*$' Guide/src/SUMMARY.md

# Find code crates with no Guide mapping
# Compare vm/devices/*/Cargo.toml crate names against the mapping table

Mapping Table Format

Each row in the mapping table follows:

| `code/path/` | `guide/path.md` |
  • Code paths use repo-root-relative paths with trailing / for directories
  • Guide paths are relative to Guide/src/
  • Multiple Guide pages for one code path: comma-separated
  • Use glob-style * in code paths for crate families (e.g., nvme*/)