/omd-autopilot

name: omd-autopilot
description: "One-prompt autonomous product design and implementation. Use automatically for broad greenfield UI requests such as 'from scratch', '새 제품/화면을 알아서 만들어줘', or requests that delegate DESIGN.md creation. It decides whether to reuse, establish, refresh, or skip a project design system; asks at most one consequential question batch; then builds and verifies the real surface. Use omd:harness instead only when the user explicitly asks for guided checkpoints."

omd:autopilot

Use this skill for an ordinary natural-language request to create a new product surface without requiring the user to name a skill, choose a reference, or set up the guided harness.

This is a separate workflow from `omd:harness`. Never claim to have approved or bypassed its mandatory checkpoints.

Ownership

The current main host agent is the only implementation owner. Specialists are read-only advisers. They may write only inside the current run's advisory folders and must never edit `DESIGN.md` or product files.

State machine

1. `DETECT` — inspect the repository, real consumer route, stack, existing `DESIGN.md`, preferences, components, states, assets and protected behavior. When `OMD_AUTHORITY_CONTROLLER_RUN_DIR` is present, use that exact relative path as the one run directory; do not derive or substitute a slug. Create the run-scoped `task.md` while retaining the exact user-prompt bytes verbatim (extra clearly labelled code observations may follow, but may never be presented as user authority), then run `autopilot-mission.cjs <project-root> <run-dir> bootstrap`. This freezes the initial product tree and mission budgets before any product write. 2. `AUTHORITY_GATE` — run `scripts/design-council-prime.cjs` in the run scope. Freeze its decision ledger before any product write. 3. `BOUNDED_COUNCIL` — dispatch no more than three evidence-required, read-only lanes. Do not dispatch a lane for a settled decision. A generic authorized greenfield mission uses only the design-system and interaction lanes; locale/copy or explicit external-evidence needs may add one relevant third lane. After the authority handoff reaches `PROPOSE_PLAN`, run `autopilot-council-plan.cjs <project-root> <run-dir>`, dispatch exactly the listed roles exactly once and in parallel (in bounded external-controller mode, execute those same lanes inline per the budget section instead of spawning advisers), then collect each result once and run `autopilot-council-reconcile.cjs <project-root> <run-dir>`. The reconciled receipt is mandatory and never grants product-write authority. Every lane must write the exact JSON shape declared in `plan.json`. Never send a follow-up, retry, or reformat request for a malformed/missing adviser result; fail the council honestly and preserve implementation time instead. 4. `CONSEQUENTIAL_INTERVIEW` — ask zero or one batch. Ask only unresolved product-authority decisions that materially change acceptance or the design system. A sufficiently authorized prompt proceeds without a question. Never create, infer, or edit `council-intake.answers.json` on the user's behalf; that file may contain only an actual user response relayed verbatim after the controller has entered `CONSEQUENTIAL_INTERVIEW`. **Unattended mode** (`--unattended` in the prompt, or `.omd/config.json` `"unattended": true`): there is no user to answer, so each question takes its first (recommended) option and the choice is recorded in `loop-trace.json` → `autoSelected[]` as `{question, chosen, alternatives}` so the decision is auditable afterwards. Options that delete or overwrite files that existed before the mission are never auto-selected — the mission fails that requirement honestly instead. `council-intake.answers.json` is still never written: auto-selection is a trace entry, not a user answer. 5. `DESIGN_SYSTEM_DISPOSITION` — resolve exactly one of `reuse`, `establish`, `refresh`, or `surface-local-only`. A missing exact brand source is blocked. After the council handoff reaches `PROPOSE_PLAN`, run the installed `design-system-plan.cjs <project-root> <run-dir>` helper. Its `design-system-decision.json` receipt is mandatory before any product write. 6. `SYSTEM_PROOF` — for `establish` or `refresh`, use the contract in `references/design-system-contract.md`. The design-system architect may propose; the main agent writes only run-scoped graph/provenance/coverage drafts. New generation, synthesis, refresh, and refactor are single-write Core v2: never emit legacy frontmatter or 13/15/16-section layouts. After the `design-system-decision.json` receipt grants `establish`/`refresh` authority, inspect the environment before preparing a review. When `OMD_AUTHORITY_CONTROLLER_RECEIPT` is present, the main agent is explicitly not the project owner: it must not run either approval helper, pass a `--reviewer`, assert `--authority-transition-approved`, calculate a hash, or choose a second output name. Author the three drafts once, with every interactive component declaring all seven state-applicability entries and every non-interactive component declaring only a reason (non-interactive error/success display variants do not require a focus-visible state).

Before spending the single activation, validate the drafts with the controller's provider-free dry-check. It may be run any number of times and never counts against the activation budget:

   node $OMD_AUTHORITY_CONTROLLER_EXECUTABLE --dry-check . $OMD_AUTHORITY_CONTROLLER_RUN_DIR

The dry-check compiles the drafts into a scratch package and verifies that every evidence path referenced by `provenance.json` and `coverage.json` (for example `council/<lane>/result.json`) exists as a real file at the project root. Fix every reported issue and rerun the dry-check until it prints `"st