From 39da9cf9b59b3f38d5740d5f6c91b844460aad5a Mon Sep 17 00:00:00 2001 From: Alexandre <44178713+alexbelgium@users.noreply.github.com> Date: Mon, 10 Aug 2026 15:10:36 +0200 Subject: [PATCH] chore(skill): prefer reusing existing code for repo homogeneity (#2952) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * 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 * 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 --------- Co-authored-by: Claude Opus 5 --- .claude/skills/hassio-addon-workflow/SKILL.md | 28 +++++++++++++++---- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/.claude/skills/hassio-addon-workflow/SKILL.md b/.claude/skills/hassio-addon-workflow/SKILL.md index cbd5d97c7e..9b288648cc 100644 --- a/.claude/skills/hassio-addon-workflow/SKILL.md +++ b/.claude/skills/hassio-addon-workflow/SKILL.md @@ -25,9 +25,14 @@ Triage first, then one of two paths: Escalate mid-flight if a light task grows — touches a default, needs a new script or service, or reveals a deeper problem. -**Standing rule:** ship the simplest solution that works. Complexity is bought only by a -**measurement** showing a concrete, user-visible cost on a real host — never by reasoning about -hypothetical performance. +**Standing rule:** ship the simplest solution that works, and build it out of what already +exists — a `.templates/` module, an existing cont-init script, the pattern a sibling add-on +already uses for the same problem. 120+ add-ons are maintained by one person: a homogeneous repo +where every add-on solves a problem the same way is worth more than a locally nicer bespoke +design. Prefer reusing or extending over adding a parallel implementation, and when you must add +something new, spell it the way the rest of the repo spells it (naming, option names, script +numbering, file layout). Complexity is bought only by a **measurement** showing a concrete, +user-visible cost on a real host — never by reasoning about hypothetical performance. **Repo layout.** `alexbelgium/hassio-addons`; each add-on is a top-level directory. This skill is checked in at `.claude/skills/hassio-addon-workflow/` (canonical copy). Set the skill root once, @@ -73,7 +78,14 @@ before it costs a full analysis pass. Measurement methodology, gotchas, and real ## 3. Plan — choose the mechanism level, then Codex reviews it (full loop) -Rank mechanisms, pick the lowest (simplest) one that solves it, and state the choice in the plan: +Look for prior art first: grep `.templates/` and the other add-ons for something that already +solves this (`grep -rl "" --exclude-dir=.git .` — search everything, not just +`*.sh`: the mechanism may live in a `Dockerfile`'s `ARG MODULES=` or an extensionless s6 `run` +file). If an add-on already handles it, the plan is "do what that one does" — say so, and say why +the existing mechanism can't be reused if you're not reusing it. + +Then rank mechanisms, pick the lowest (simplest) one that solves it, and state the choice in the +plan: 1. A config value — an option, a schema constraint, an existing env var. 2. An existing knob the base image already reads (`MAX_RES`, `DRINODE`, `SELKIES_*`). @@ -110,7 +122,13 @@ not just the happy path. Before requesting review, check: did the diff stay at the ladder level chosen in step 3? Can this be solved by deleting instead of adding? Is the fix bigger than what it fixes? How does it fail in -three years? Case studies of what happens when this check is skipped: `references/simplify.md`. +three years? And on reuse: does any hunk reimplement something `.templates/`, another script in +this add-on, or a sibling add-on already does — and if a future add-on hits this same problem, +will it find one way to solve it or two? Fold a near-duplicate into the existing mechanism, or +justify the divergence in the PR body — but never at the cost of an isolation rule +`references/traps.md` documents: scripts shared by symlink with the webtop add-ons take a new +numbered script, not an edit. Case studies of what happens when this check is skipped: +`references/simplify.md`. ## 6. Codex attacks the code (full loop only)