osmatrix-ci
osmatrix-ci: run GitHub Actions workflows locally
osmatrix gives agents local guests (an ubuntu container, windows/macos VMs, or any machine over ssh) and local GitHub Actions runs with act. This skill covers the CI loop. Sibling skills in the same plugin: osmatrix-guests (run commands, copy files, forward ports and drive the GUI inside a guest) and osmatrix-setup (host checks, creating guests, troubleshooting).
Use the MCP tools (ci_plan, ci_run, ...) when they are available: they are the supported interface, and their safety annotations let the client ask for confirmation where it matters.
If the osmatrix MCP tools are missing from this session, tell the user before doing anything else. Say that the osmatrix MCP server isn't loaded, so you'll use the osmatrix CLI instead, and suggest the likely fix: enable or restart the osmatrix MCP server in the client's MCP/plugin settings (a server that failed once may stay failed until it is toggled off and on). Then continue with the CLI: every tool has a matching command (see references/reference.md); add --json for machine output. Check osmatrix --version first; if the command isn't found, npx -y osmatrix@0 <command> works once osmatrix is published on npm. Otherwise tell the user it isn't installed, and stop.
Always pass the repository's absolute host path as repo to every ci_* tool: the MCP server's working directory may be the plugin cache, not the user's checkout.
How legs run
A workflow's matrix is expanded into legs. ubuntu-* legs run with act on the host's Docker; windows-* / macos-* legs run act inside the matching VM (host mode), after syncing the repo into it.
A windows/macos leg needs that guest to be ready (env_status, CLI osmatrix status). If the guest is absent or its status detail says "not set up", follow osmatrix-setup first; VM setup takes 20–60 min. VMs are slow to boot (1–3 min), so don't start VMs you don't need, and leave a VM running while you iterate.