Agent skill

Omh Physical Device Readiness

by rlaope in rlaope/oh-my-hermes

[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…

MITAuto-check passed

Install Omh Physical Device Readiness

skills CLI
$ npx skills add rlaope/oh-my-hermes --skill omh-physical-device-readiness -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rlaope/oh-my-hermes omh-physical-device-readiness --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rlaope/oh-my-hermes.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/omh-physical-device-readiness .claude/skills/omh-physical-device-readiness && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
omh-physical-device-readiness
GitHub stars
3.2k
Token cost
~2.3k tokens
SKILL.md length
985 words
Files
1
Skills in repo
143
Repo updated
First seen
Licence
MIT

At a glance

[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…

  • The user says: physical-device-readiness
  • SKILL.md covers Why This Exists, Do Not Use When, Examples and Completion Checklist, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • Physical device readiness

What it does

Omh Physical Device Readiness is an agent skill from rlaope/oh-my-hermes. [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.

Its SKILL.md is about 2.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: All in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages. The licence is MIT.

When your agent uses it

  • The user says: physical-device-readiness
  • Physical device readiness
  • Device safety readiness
  • Physical device safety

Example prompts

  • “/omh-physical-device-readiness”

What it can do on your machine

Read from SKILL.md and the folder at commit 7cd0d02. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Omh Physical Device Readiness loads about 2.3k tokens when it runs. Until then it costs about 125 tokens; SKILL.md has 985 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~125
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rlaope/oh-my-hermes at commit 7cd0d02, republished under its MIT licence (© rlaope). 985 words, ~2,250 tokens.

Download SKILL.mdSave it as .claude/skills/omh-physical-device-readiness/SKILL.md (or your agent's skills folder).
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.

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 릴레이 안전`, `센서 릴레이 안전`
Show full SKILL.md (472 more words)Show less

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 card when prepared
  • device_safety_envelope/v1 with device, workspace, hazards, actuator classes, human/property risk, owner, authority, and stop condition
  • hazard_and_actuator_inventory/v1 separating motion, heat, pressure, electrical, relay, network, credential, and environmental risks
  • sensor_camera_gate_policy/v1 for camera/OCR, sensor telemetry, stale readings, manual inspection, and blocked/no-camera fallback
  • operator_approval_policy/v1 with explicit human authority, confirmation moment, disallowed autonomous actions, and emergency contact or stop owner
  • dry_run_and_simulation_policy/v1 for slicer/G-code dry-runs, command previews, mock relays, simulated robot paths, and no-hardware trial mode
  • emergency_stop_and_rollback_plan/v1 with stop command, power/network isolation, recovery boundary, and abort condition
  • device_trial_manifest/v1 only when real telemetry, camera capture id, dry-run output, command transcript, operator confirmation, or hardware observation is recorded

Safety rules:

  • A physical device readiness card is not device discovery, network pairing, credential validation, slicer output, G-code safety, camera inspection, sensor reading, relay actuation, robot movement, heat command, print start, emergency stop test, or successful hardware trial evidence unless observed device-trial evidence records it.
  • Do not claim connector, gateway, runtime, file generation, memory mutation, or host automation evidence from prepared guidance.

Runtime Evidence

Preferred harness for this skill: physical-device-readiness.

sh
omh runtime record --skill physical-device-readiness --harness physical-device-readiness --status started

Record observed delegation results; otherwise return not_available or not_observed. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.

  • Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes. Preserve workflow intent and stop conditions; verify before claiming completion. Reply in the user's own words and the host's own voice: its SOUL.md persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.

© rlaope, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/omh-physical-device-readiness of rlaope/oh-my-hermes.

Open the folder on GitHubat commit 7cd0d02

Compare with similar skills

Omh Physical Device Readiness next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Omh Physical Device Readiness compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Omh Physical Device Readiness this skillrlaope/oh-my-hermes3.2k—~2.3kAutomated safety check: PassMIT
Iot Anomaliesruvnet/ruflo74k—~210Automated safety check: PassMIT
Foundation Models On Deviceaffaan-m/ECC277k4 repos~2.1kAutomated safety check: PassMIT
Homelab Network Readinessaffaan-m/ECC277k1 repos~1.9kAutomated safety check: PassMIT
Iot Registerruvnet/ruflo74k—~263Automated safety check: PassMIT
Iot Fleetruvnet/ruflo74k—~210Automated safety check: PassMIT

Similar skills

  • Iot Anomalies

    ruvnet/ruflo

    Detect and classify telemetry anomalies on Cognitum Seed devices.

    74k GitHub stars~210 tokensUpdated yesterday
    Data & AnalyticsAuto-check passed
  • Apple FoundationModels framework for on-device LLM — text generation, guided generation with @Generable, tool calling, and snapshot streaming in iOS 26+.

    277k GitHub starsUsed in 4 repos~2.1k tokens
    AI & LLM EngineeringAuto-check passed
  • Readiness checklist for homelab VLAN segmentation, local DNS filtering (Pi-hole, AdGuard Home), and WireGuard-style remote access.

    277k GitHub starsUsed in 1 repo~1.9k tokens
    Backend & APIsAuto-check passed
  • Iot Register

    ruvnet/ruflo

    Register a Cognitum Seed device by endpoint and establish agent bridge

    74k GitHub stars~263 tokensUpdated yesterday
    Auto-check passed
  • Iot Fleet

    ruvnet/ruflo

    Create and manage Cognitum Seed device fleets with firmware policies

    74k GitHub stars~210 tokensUpdated yesterday
    Auto-check passed
  • Physical Address

    thedaviddias/Front-End-Checklist

    A skill your agent uses when auditing local business websites, e-commerce sites, or any site where a physical presence affects trust or local search visibility.

    74k GitHub stars~574 tokensUpdated 4 days ago
    Marketing & SEOAuto-check passed

More from rlaope/oh-my-hermes

All 143 skills in this repo
  • Omh Accessibility Audit

    rlaope/oh-my-hermes

    [omh] Screen-reader or keyboard accessibility gaps: prepare WCAG, keyboard, focus, screen-reader, target-size, and reflow evidence gates for UI surfaces.

    3.3k GitHub stars~2.8k tokensUpdated today
    Auto-check passed
  • Omh Agent Debug

    rlaope/oh-my-hermes

    [omh] Agent is stuck, looping, or drifting: capture a stuck, looping, drifting, or repeatedly failing agent run, diagnose the likely failure pattern, and prepare the smallest safe recovery action.

    3.3k GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Omh Agent Evaluation

    rlaope/oh-my-hermes

    [omh] Choosing between coding agents on evidence: compare executor or agent choices on reproducible tasks using quality, cost, time, tool, and evidence metrics.

    3.3k GitHub stars~2.1k tokensUpdated today
    Auto-check passed
  • Omh Agent Instructions

    rlaope/oh-my-hermes

    [omh] Agent instruction file for a repo -- AGENTS.md, CLAUDE.md, a Cursor rule: write or update what an agent cannot derive from the code, inside a marked region, with every command verified or…

    3.3k GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Omh Agent Ops Review

    rlaope/oh-my-hermes

    [omh] AI agent progress for managers: help managers inspect AI-agent progress, blockers, quality gates, and throughput levers.

    3.3k GitHub stars~1.9k tokensUpdated today
    Auto-check passed
  • Omh AI Slop Cleaner

    rlaope/oh-my-hermes

    [omh] Messy or AI-generated code to clean up: delete AI-generated slop, dead code, and duplication while observable behavior stays identical.

    3.3k GitHub stars~2.7k tokensUpdated today
    Auto-check passed

Questions about Omh Physical Device Readiness

What does Omh Physical Device Readiness do?

[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…. Omh Physical Device Readiness is an agent skill from rlaope/oh-my-hermes. [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.

When should I use Omh Physical Device Readiness?

Omh Physical Device Readiness fits situations like: the user says: physical-device-readiness; physical device readiness; device safety readiness; physical device safety.

How do I install Omh Physical Device Readiness in Claude Code?

Run `npx skills add rlaope/oh-my-hermes --skill omh-physical-device-readiness -a claude-code`. Or copy the skill folder (skills/omh-physical-device-readiness in rlaope/oh-my-hermes) into .claude/skills/omh-physical-device-readiness in your project. Claude Code loads it when a task matches its description.

How do I install Omh Physical Device Readiness in Codex?

Run `npx skills add rlaope/oh-my-hermes --skill omh-physical-device-readiness -a codex`. Or copy the skill folder (skills/omh-physical-device-readiness in rlaope/oh-my-hermes) into .agents/skills/omh-physical-device-readiness in your project. Codex loads it when a task matches its description.

Can I use Omh Physical Device Readiness in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rlaope/oh-my-hermes --skill omh-physical-device-readiness -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/omh-physical-device-readiness, .gemini/skills/omh-physical-device-readiness, .github/skills/omh-physical-device-readiness and .opencode/skills/omh-physical-device-readiness in your project.

What does Omh Physical Device Readiness need to run?

SKILL.md names no scripts, command-line tools or credentials: Omh Physical Device Readiness is instructions for the agent only.

Does Omh Physical Device Readiness access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Omh Physical Device Readiness safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Omh Physical Device Readiness use?

Omh Physical Device Readiness is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Omh Physical Device Readiness use?

About 2.3k tokens (SKILL.md is roughly 9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Omh Physical Device Readiness?

Skills that share tags, products or a category with Omh Physical Device Readiness: Iot Anomalies (ruvnet/ruflo, 74k stars), Foundation Models On Device (affaan-m/ECC, 277k stars), Homelab Network Readiness (affaan-m/ECC, 277k stars) and Iot Register (ruvnet/ruflo, 74k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Omh Physical Device Readiness?

rlaope (a GitHub user) maintains it in rlaope/oh-my-hermes, which has 3,243 GitHub stars. The repository holds 143 skills in this directory. The repository was last updated on October 10, 2026.

Source: rlaope/oh-my-hermes on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.