omarchy-ship

Runs a five-layer verification lane for Omarchy plugins and emits a submission only on a clean verdict.

Updated Sep 20, 2026
One-click install
npx skills add https://github.com/jeremylongshore/omarchy-ship --skill omarchy-ship-jeremylongshore
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: omarchy-ship
Source: https://github.com/jeremylongshore/omarchy-ship/tree/main/skills/omarchy-ship
Command: npx skills add https://github.com/jeremylongshore/omarchy-ship --skill omarchy-ship-jeremylongshore

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Omarchy plugin verification layers have repeatedly reported success without checking anything: gates counted SKIP as PASS, static linters passed broken QML contracts, and renders used seeded fixtures that hid dead endpoints. This Skill runs a pre-submission lane that refuses to report green for anything it did not actually check, distinguishing NOT APPLICABLE from UNPROVEN and refusing to emit a submission when any applicable check could not run. ## Core Features & Use Cases - Five-layer verification: runs the vendored gate lane (checked against canonical first), the repo's offline test suite, rig validation with omarchy-plugin-validate and qmllint, a real headless shell render treating any QML warning as a finding, and a live first-run test with empty cache and real network for plugins that fetch data. - Delegated judgment: spawns a read-only coverage-reporter agent for accounting and a separate submission-auditor agent for qualitative review, then combines results into exactly one verdict: CLEAN, FINDINGS, or INCONCLUSIVE. - Submission emission with refusal: only on CLEAN does it print the marketplace issue body per the submission format, including the coverage fraction as evidence; it never files the issue itself. - Use Case: Before pushing a plugin change or filing a marketplace verify request, run the lane to learn what your green CI actually covers, and get a defensible submission body or a named list of unproven checks with the commands that resolve them. ## Quick Start Ask the assistant to run /omarchy-ship with your plugin directory or name, for example "/omarchy-ship bazaar", to run the full lane and get a verdict.

Frequently Asked Questions about omarchy-ship

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify an Omarchy plugin before submitting it to the marketplace?▼

Run /omarchy-ship with the plugin directory or name. It executes the gate lane, offline tests, rig validation, a real shell render, and a live first-run network check, then prints a verdict and, only on CLEAN, the submission body.

What is the difference between UNPROVEN and NOT APPLICABLE in plugin checks?▼

NOT APPLICABLE means the predicate is false, such as a tree with no QML, and aggregates safely as a pass. UNPROVEN means the predicate is true but the checker could not run, and any UNPROVEN item forces an INCONCLUSIVE verdict with no submission.

Why do omarchy-plugin-validate and qmllint pass a broken plugin?▼

Both are static checks, so they miss QML contract errors like a KeyboardPanel used where a PanelWindow belongs or module.exports invisible to QML. Only loading the plugin in a real shell catches these, which is why the rig render layer treats any QML warning as a finding.

What happens if the omarchy-rig container is unreachable during verification?▼

Rig validation and render are classified as UNPROVEN, never not applicable. The verdict becomes INCONCLUSIVE, no submission is emitted, and the report names the command that resolves each unproven item, such as docker start omarchy-rig.

Can I skip the rig checks to meet a submission deadline?▼

No. The skill declines to suppress checks because a skipped check becomes UNPROVEN and forces INCONCLUSIVE. It reports what is unproven rather than emitting a submission that carries no information.

What are the prerequisites for running the Omarchy submission lane?▼

You need a plugin directory with a manifest.json declaring entryPoints, a contributing-clanker checkout for the canonical gate lane, the omarchy-rig container for rig checks, and git, jq, and docker on PATH.