mirror of
https://github.com/alexbelgium/hassio-addons.git
synced 2026-08-23 05:13:32 +02:00
39da9cf9b5
* chore(skill): prefer reusing existing code for repo homogeneity The standing rule already demanded the simplest solution; it said nothing about where that solution should come from. A bespoke-but-simple mechanism in one add-on is still a second way to solve a problem 120+ add-ons share. - Standing rule: build out of what exists (.templates/ module, existing cont-init script, a sibling add-on's pattern), and match repo naming conventions when something new is genuinely needed. - Step 3 (Plan): search for prior art before ranking mechanism levels; not reusing an existing mechanism now requires stating why. - Step 5 (Simplify): reuse check alongside the existing ones — fold near-duplicates in, or justify the divergence in the PR body. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(skill): address Codex and CodeRabbit review feedback - Prior-art search: the --include='*.sh' --include='config.yaml' allowlist missed the repo's main mechanisms. `ARG MODULES=` lives in Dockerfiles and s6 v3 services are extensionless `run` files; searching for MODULES= found 6 files under the allowlist vs 129 (125 Dockerfiles) without it. Widened to --exclude-dir=.git and named the two file types explicitly. - Reuse vs isolation: "fold a near-duplicate into the existing mechanism" contradicted traps.md:125, which requires a new numbered script rather than editing scripts shared by symlink with the webtop add-ons. Added the carve-out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>