Ensures safe configuration and hardware control for ESPHome devices.

Install

mkdir -p .claude/skills/esphome && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18541" && unzip -o skill.zip -d .claude/skills/esphome && rm skill.zip

Installs to .claude/skills/esphome

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Applies safe ESPHome rules for YAML, lambdas, sensors, switches, relays, boot behavior, fail-safes, and validation.
115 charsno explicit “when” trigger
Intermediate

Key capabilities

  • Apply safe ESPHome rules for YAML configurations
  • Inspect existing YAML structure before making changes
  • Ensure failsafe defaults for relays and dangerous loads
  • Keep lambdas small, readable, and non-blocking
  • Validate configurations using esphome commands

How it works

The skill applies safety rules to ESPHome YAML, lambdas, sensors, and relays, emphasizing inspection of existing configurations and failsafe defaults. It guides towards small, readable lambdas and validates configurations using esphome commands.

Inputs & outputs

You give it
ESPHome YAML configuration or a request for ESPHome integration
You get back
A safe, maintainable ESPHome YAML configuration with validated behavior

When to use esphome

  • Configure safe relay boot behavior
  • Update sensor poll intervals
  • Review ESPHome YAML security

About this skill

Skill: esphome

Purpose

Apply safe, maintainable rules to ESPHome YAML, lambdas, sensors, switches, relays, and ESPHome integrations.

Safety First

ESPHome often controls real hardware. Bugs are not just failed unit tests with extra plastic smell.

Be careful with:

  • relays;
  • heaters;
  • boilers;
  • pumps;
  • locks;
  • gates;
  • fans;
  • mains-connected devices;
  • battery charging;
  • high-current loads.

Use failsafe defaults where appropriate.

Inspect First

Before changing ESPHome config, inspect:

  • existing YAML structure;
  • substitutions;
  • packages/includes;
  • board type;
  • framework;
  • pins/GPIO usage;
  • IDs;
  • secrets references;
  • boot behavior;
  • reconnect behavior;
  • existing lambdas;
  • Home Assistant entities linked to the node.

Do not invent pins, wiring, voltage/current limits, or board behavior.

YAML Rules

  • Preserve existing IDs unless explicitly changing them.
  • Avoid duplicate entity IDs.
  • Use !secret for sensitive values.
  • Avoid hardcoded Wi-Fi credentials.
  • Keep YAML structure valid.
  • Prefer substitutions/packages for repeated configuration when already used.
  • Avoid excessive update intervals.
  • Consider flash wear.
  • Keep lambdas small and readable.
  • Avoid blocking lambdas.

Boot and Failsafe Behavior

Consider:

  • relay default state;
  • restore mode;
  • boot priority;
  • Wi-Fi loss;
  • API/MQTT reconnect;
  • safe state after reboot;
  • sensor unavailable states;
  • brownouts.

For relays controlling dangerous loads, default-off is usually safer unless project requirements prove otherwise.

Lambdas

  • Keep lambdas short.
  • Avoid hidden state unless necessary and documented.
  • Avoid blocking delays.
  • Handle NaN/unavailable values.
  • Prefer named IDs and clear calculations.
  • Move complex logic into custom components only when justified.

Validation

Prefer:

esphome config <file.yaml>
esphome compile <file.yaml>

Only run commands that are available and appropriate for the project.

Report exact commands and results.

Shared Cross-Ecosystem Style

Apply the shared engineering style from:

  • ../../engineering/05_design_principles.md
  • ../../engineering/06_responsibility_model.md
  • ../../engineering/07_complexity_budget.md
  • ../../engineering/12_naming_bible.md

Language-specific idioms control syntax and ecosystem details, but they must not weaken the core rules: small cohesive units, explicit boundaries, honest validation, no dumping grounds, and no fake placeholders.

When not to use it

  • When inventing pins, wiring, voltage/current limits, or board behavior
  • When using excessive update intervals that may cause flash wear
  • When creating blocking lambdas or hidden state without documentation

Limitations

  • Requires careful handling of real hardware, especially high-current loads
  • Discourages inventing pins, wiring, or board behavior
  • Emphasizes failsafe defaults and boot behavior considerations

How it compares

This skill provides a structured approach to ESPHome configuration with a strong emphasis on safety, maintainability, and validation, which is more reliable than ad-hoc configuration that might overlook critical hardware considerations.

Compared to similar skills

esphome side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
esphome (this skill)017dReviewIntermediate
windows-ui-automation178moReviewAdvanced
linux-production-shell-scripts76moReviewIntermediate
cursor-prod-checklist410dReviewIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

windows-ui-automation

martinholovsky

Expert in Windows UI Automation (UIA) and Win32 APIs for desktop automation. Specializes in accessible, secure automation of Windows applications including element discovery, input simulation, and process interaction. HIGH-RISK skill requiring strict security controls for system access.

17126

linux-production-shell-scripts

davila7

This skill should be used when the user asks to "create bash scripts", "automate Linux tasks", "monitor system resources", "backup files", "manage users", or "write production shell scripts". It provides ready-to-use shell script templates for system administration.

746

cursor-prod-checklist

jeremylongshore

Execute production readiness checklist for Cursor IDE setup. Triggers on "cursor production", "cursor ready", "cursor checklist", "optimize cursor setup". Use when working with cursor prod checklist functionality. Trigger with phrases like "cursor prod checklist", "cursor checklist", "cursor".

434

openevidence-prod-checklist

jeremylongshore

Production readiness checklist for OpenEvidence clinical AI deployments. Use when preparing for production launch, conducting pre-deployment reviews, or auditing OpenEvidence integration for compliance. Trigger with phrases like "openevidence production", "openevidence go-live", "openevidence checklist", "deploy openevidence", "openevidence readiness".

13

posthog-enterprise-rbac

jeremylongshore

Configure PostHog enterprise SSO, role-based access control, and organization management. Use when implementing SSO integration, configuring role-based permissions, or setting up organization-level controls for PostHog. Trigger with phrases like "posthog SSO", "posthog RBAC", "posthog enterprise", "posthog roles", "posthog permissions", "posthog SAML".

13

prowler-provider

prowler-cloud

Creates new Prowler cloud providers or adds services to existing providers. Trigger: When extending Prowler SDK provider architecture (adding a new provider or a new service to an existing provider).

13

Search skills

Search the agent skills registry