esphome
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.zipInstalls 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.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
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
!secretfor 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.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| esphome (this skill) | 0 | 17d | Review | Intermediate |
| windows-ui-automation | 17 | 8mo | Review | Advanced |
| linux-production-shell-scripts | 7 | 6mo | Review | Intermediate |
| cursor-prod-checklist | 4 | 10d | Review | Intermediate |
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.
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.
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".
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".
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".
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).