본문으로 건너뛰기
cccskills
무료GitHub에 공개

compile

Test compile ESPHome firmware for all devices using Docker and fix any YAML or configuration errors until every device compiles successfully. Use when the user says "/compile", "test compile", "compile check", "build test", "check builds", "verify compile", or wants to make sure all devices compile before committing.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol스타 1,120(GitHub 1,120 + cccskills 0)
연동 도구Docker

실행 점수 미검증

설치 방법 보기

포함된 파일(1)

  • SKILL.md3.6 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Test Compile - Build All Devices

Compile ESPHome firmware for every device in the repo using Docker. If a build fails, diagnose the error, fix the source YAML, and re-compile until all devices pass.

Device Slugs

guition-esp32-p4-jc1060p470
guition-esp32-p4-jc4880p443
guition-esp32-s3-4848s040

Workflow

Run all commands from the active repository worktree. Resolve its root once and use that path for Docker mounts; do not use a fixed machine-specific checkout path:

REPO_ROOT="$(git rev-parse --show-toplevel)"

1. Resolve the ESPHome Version

Use the ESPHome version pinned by the repository in .github/esphome.env. This is the same version used by CI and release builds; do not hard-code an older version in this skill.

ESPHOME_VERSION="$(sed -n 's/^ESPHOME_VERSION=//p' .github/esphome.env)"
test -n "$ESPHOME_VERSION"
ESPHOME_IMAGE="ghcr.io/esphome/esphome:${ESPHOME_VERSION}"

Keep these variables in the shell session used for the compile commands.

2. Compile Each Device

Run one Docker compile per device. Use builds/<slug>.factory.yaml, the same entry point CI uses, so the test matches what a release build would do.

docker run --rm \
  -v "$REPO_ROOT:/config" \
  "$ESPHOME_IMAGE" \
  compile /config/builds/<slug>.factory.yaml

Run devices sequentially because each compile is resource-intensive. Use a 10-minute timeout or block window when available so compiles are not treated as stalled too early. If a compile backgrounds, poll the terminal output until it finishes and read the result.

If the pinned image is missing, pull it first:

docker pull "$ESPHOME_IMAGE"

3. Interpret Results

  • Success: output ends with Successfully compiled program or INFO Successfully compiled program.
  • Failure: inspect ERROR lines and the file/line references around them.

Common failure categories:

  • YAML syntax errors, including indentation and missing keys
  • Missing !include targets or wrong relative paths
  • Unknown component or platform
  • Undefined substitution variables
  • Type mismatches, such as a string where an integer is expected
  • Missing packages: keys

4. Fix and Retry on Failure

When a device fails:

  1. Read the full error output carefully.
  2. Identify the failing file and line from the error message.
  3. Open and read that file to understand context.
  4. Fix the root cause in source YAML.
  5. Re-run the same Docker compile command for that device.
  6. Repeat until it succeeds, then move to the next device.

Do not skip a device or mark it as known broken. Every listed device must compile.

Fixes should target files under common/, devices/, or components/ when possible, not the builds/*.yaml wrappers because those are thin entry points.

5. Web UI Asset Note

The factory YAML bundles www.js via js_include. If the referenced JavaScript file is missing, compile will fail. Run this first when web UI assets may be out of date:

python3 scripts/build.py

6. Report

After all devices pass, summarize:

Compile results:
  guition-esp32-p4-jc1060p470  OK
  guition-esp32-p4-jc4880p443  OK
  guition-esp32-s3-4848s040    OK

Fixes applied:
  - <file>: <what was wrong and what was changed>

If no fixes were needed, show only the passing results.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Clean up completed Git branches and worktrees for this repository both locally and on GitHub. Use when the user asks to remove complete, completed, merged, stale, finished, or done branches, delete merged GitHub branches, tidy local worktrees, prune completed PR branches, or clean up branches and worktrees after pull requests have merged.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

Clean up local branch worktree folders for this repository after their branches or pull requests have merged to main. Use when the user asks to remove merged branch folders, tidy local worktrees, clean old feature branch directories, prune merged PR worktrees, or clean up local development folders without impacting main.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

Review EspControl repository changes specifically for missing, stale, excessive, or misplaced documentation. Use when the user asks for a documentation coverage review, asks whether a feature or behavior change is concisely documented, invokes $docs-review, or explicitly wants docs checked as a secondary pass during a pull request, branch, or local diff review.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

Provide an expert codebase review for this repository. Use when the user says "Expert Review" or "/expert-review", asks for an expert review, wants refactoring or codebase improvement recommendations, wants consistency and quality assessed, or asks how to reduce duplication, improve component use, preserve the end-user experience, and keep upgrades cleanly migratable.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

Reimagine this repository from first principles using the current product and user experience as the target. Use when the user says "/expert-reset", asks how the project should be rebuilt if starting again, wants bold architecture or component-structure recommendations, or wants a research-only reset plan unconstrained by current implementation details.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

Flash EspControl display firmware from this repository using ESPHome. Use when the user invokes /flash-displays with no extra display name, or asks to flash, reflash, update, or upload firmware to all known displays in sequence, or to a specific display such as 7inch, 7-inch P4, 10inch, 10-inch V1, 10-inch V2, 10-inch V3, P4-86, 4.3-inch P4, 4-inch P4, or S3, over an explicitly supplied OTA target or USB.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

jtenniswood/espcontrol1.1천2026년 10월 26일 업데이트

jtenniswood의 스킬 모두 보기

이 스킬의 문제 신고