Omd

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.