/omh-physical-device-readiness

name: "omh-physical-device-readiness"
description: "[omh] Agent control of a robot, 3D printer, or IoT relay: gate robots, 3D printers, IoT relays, sensors, and lab hardware before trials; use external-connector-readiness for provider or connector adoption and toolbelt-readiness for missing control tools. Use when the user says: physical-device-readiness, physical device readiness, device safety readiness, physical device safety, hardware safety gate, 3d printer readiness, 3D printer safety, snapmaker printer safety."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, operations]
    category: operations
    phase: device-readiness
    role: operator
    quality_tier: workflow-surface-gated

Physical Device Readiness

This is a Hermes-native `physical-device-readiness` workflow skill.

Why This Exists

`physical-device-readiness` exists so Hermes users can ask for this workflow in chat and get a structured, checkable answer instead of an improvised one.

Do Not Use When

• The request is already handled by a narrower explicit skill with stronger evidence.
• The user asks OMH to secretly run external platforms, connectors, schedulers, file exports, or runtime agents.
• The only safe answer is to ask for missing authority, credentials, target, or observed evidence first.

Examples

Good example:

• Prompt: physical-device-readiness check Snapmaker printer safety with camera gate, slicer dry-run, heat command approval, and emergency-stop evidence before printing.
• Expected behavior: Produce `prepare_physical_device_readiness` with required context, wrapper actions, and not-evidence boundaries.
• Why: The prompt names a real workflow surface that Hermes can orchestrate without hiding execution.

Bad example:

• Prompt: physical-device-readiness start the printer, heat the bed, flip relays, and claim the robot is safe without observed operator approval or device telemetry.
• Expected behavior: Report the missing observed evidence or authority instead of claiming the external step happened.
• Why: Prepared OMH guidance is not platform, runtime, connector, file, memory, or delivery evidence.

Completion Checklist

• Device scope, actuator and hazard classes, sensor/camera gates, operator approval, dry-run policy, emergency stop, and stop condition are explicit.
• Physical actions, heat commands, relay toggles, robot movement, print starts, camera inspections, and telemetry readings are marked observed, missing, risky, or not_observed.
• Route external APIs or provider setup to external-connector-readiness, terminal commands to command-operator, safety concerns to security-safety-review, visual/camera checks to visual-qa, and missing tools to toolbelt-readiness.
• Do not claim device movement, heat, print, relay, robot, camera, sensor, or emergency-stop success without observed device-trial evidence.

Recovery Notes

• If the device, workspace, actuator, or authority is unclear, keep readiness blocked until the missing safety context is named.
• If the user asks to execute commands, move hardware, heat a bed/nozzle, flip a relay, or start a print, route to command-operator or connector-operator and require observed operator approval before any execution claim.
• If camera or telemetry evidence is required but unavailable, route to visual-qa or toolbelt-readiness and keep the physical device readiness card prepared_not_observed.

Workflow Lane

• Current lane: **Automation and status** (`achievements`, `workspace-audit`, `production-audit`, `live-incident-response`, `automation-blueprint`, `github-event-ops`, `github-issue-intake`, `buzz`, `+39 more`) - schedules, status, health, and ops review.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use before preparing or adopting a workflow that could move, heat, print, actuate, unlock, or otherwise affect physical devices so safety envelope, sensor/camera gates, dry-run policy, operator approval, emergency stop, and observation requirements are explicit.

Strong routing signals: `physical-device-readiness`, `physical device readiness`, `device safety readiness`, `physical device safety`, `hardware safety gate`, `3d printer readiness`, `3D printer safety`, `snapmaker printer safety`, `snapmaker readiness`, `moonraker klipper safety`, `camera-gated print start`, `camera gate`, `heat command approval`, `iot relay safety`, `sensor relay safety`, `robotics safety`, `robot control readiness`, `vla robot readiness`, `mushroom cultivation relay safety`, `raspberry pi relay safety`, `물리 장비 안전`, `하드웨어 안전`, `3d 프린터 안전`, `프린터 안전`, `로봇 제어 준비`, `iot 릴레이 안전`, `센서 릴레이 안전`

Catalog Metadata

Category: `operations` Phase: `device-readiness` Hermes role: `operator` Quality tier: `workflow-surface-gated` Reasoning demand: `light`

Quality bar:

• Name the user-facing workflow objective, required context, next action, and stop condition.
• Separate prepared guidance from observed platform, runtime, connector, file, memory, or delivery evidence.
• Expose missing tools, credentials, targets, or observations as user-visible gaps.

Handoff policy:

Keep this as Hermes-facing orchestration guidance first. Prepare executor, connector, gateway, or host-runtime handoff only when the user accepts that next step and observed evidence can be recorded.

Required inputs:

• user request
• target context
• delivery or status expectation
• known missing evidence

Expected outputs:

• physical_device_readiness_card/v1
• device_safety_envelope/v1
• hazard_and_actuator_inventory/v1
• sensor_camera_gate_policy/v1
• operator_approval_policy/v1
• dry_run_and_simulation_policy/v1
• emergency_stop_and_rollback_plan/v1
• device_trial_manifest/v1 when observed
• next action
• prepared-vs-observed boundary

Artifact expectations:

• physical_device_readiness_card/v1 metadata-only wrapper c