/omd

name: omd
description: "Compatibility router for older `omd` invocations. Route existing UI work to omd:apply, autonomous greenfield work to omd:autopilot, and DESIGN.md-only setup or migration to omd:init. Use it only when the legacy skill name is invoked; it reads Core v2 or legacy context without writing DESIGN.md itself."

OmD compatibility router

`ROUTER_ONLY_NO_DESIGN_MD_WRITES`

This skill preserves old `omd` entrypoints while the active workflows live in `omd:apply`, `omd:autopilot`, and `omd:init`. It classifies the available design context, transfers the original request to one canonical workflow, and then stops. Do not duplicate a target workflow here.

Authority classification

Inspect these files without mutating them:

1. A valid adopted Core v2 package has a hash-bound `.omd/system/manifest.json` with `format: design-md-core`, `format_version: 2.0.0`, `profile: portable-core`, and `authority.canonical: system-graph`. Only after the target workflow validates the manifest, graph, projection, and exact bidirectional hashes is `.omd/system/graph.json` canonical. Root `DESIGN.md` remains its complete, vendor-neutral portable projection. 2. `profile: migration-candidate` is non-authoritative. Keep the source `DESIGN.md` named by its authority record canonical while the candidate is reviewed. Never use the candidate as a Bound System. 3. If the package is absent, stale, invalid, or hash-mismatched, use root `DESIGN.md` independently for the rules it actually expresses. It does not require sidecars, an OmD install, or this skill to be useful. Do not claim graph authority or a conformance level that has not been validated. 4. A legacy or unmarked root `DESIGN.md` remains a read-only compatibility input. If root `DESIGN.md` is absent, `.stitch/DESIGN.md` may be used only as the same read-only fallback. Apply declared rules, omit unknown values at the smallest boundary, and never silently rewrite or upgrade either file.

A stale binding invalidates graph authority, not the readable Markdown. Never promote reference observations, placeholders, or generic defaults into project facts.

Route once

• Existing UI, component, styling, motion, microcopy, design review, or other

bounded product work -> transfer the unchanged request and authority classification to `omd:apply`.

• Broad from-scratch product work, a new surface with delegated decisions, or

autonomous design-system-plus-implementation work -> transfer to `omd:autopilot`.

• DESIGN.md bootstrap, design-system-only creation, explicit migration,

refactor, or refresh without product implementation -> transfer to `omd:init`.

• If the user explicitly requests guided checkpoints, transfer to

`omd:harness`; do not convert that request into Autopilot.

Use the runtime's skill dispatch when available. Otherwise locate the selected skill in the active channel, read its `SKILL.md` completely, and follow it. Pass through the user's original brief, preferences, and known authority facts so the user is not asked to repeat them.

Write boundary

This compatibility shim may inspect and route only. It must not create, edit, copy, move, rename, delete, or project `DESIGN.md`; it must not edit `.omd/system`; and it must not run a writer or migration command itself. The selected canonical workflow owns every write, checkpoint, migration proof, and validation step.