chore(skill): prefer reusing existing code for repo homogeneity - #2952
Conversation
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>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe add-on workflow guidance now requires prior-art searches, reuse of repository conventions, measurement of user-visible costs before adding complexity, and justification for retaining near-duplicate mechanisms. ChangesWorkflow guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR updates the repository’s hassio-addon-workflow skill guidance to explicitly prefer reusing existing repo mechanisms (e.g., .templates/ modules or established add-on patterns) to keep solutions consistent across the large add-on set.
Changes:
- Strengthens the standing rule to prioritize reuse/extension of existing patterns before introducing parallel mechanisms.
- Adds an explicit “prior art” search step before selecting a mechanism level in the planning phase.
- Adds a reuse-focused check to the “Simplify” step to reduce near-duplicate implementations across add-ons.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 19ce9cb499
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/hassio-addon-workflow/SKILL.md:
- Around line 28-35: Update the “Standing rule” in the workflow guidance so the
measurement prerequisite applies only to performance or resource optimizations
and their trade-offs. Preserve the existing preference for simple, reusable,
homogeneous solutions, while allowing complexity required for correctness,
security, compatibility, accessibility, or host-specific behavior without
requiring a real-host performance measurement.
- Around line 124-128: Update the reuse guidance in the relevant checklist
section to explicitly preserve documented isolation rules: do not fold
add-on-specific behavior into symlink-shared scripts or other protected
extension points such as 80-configuration.sh; instead, use a new numbered script
when references/traps.md requires it. Retain the existing reuse expectation for
ordinary near-duplicates and require justification only when intentionally
diverging from the documented boundary.
- Around line 81-87: Broaden the prior-art search guidance in the workflow
planning section to include all relevant YAML/YML files, Dockerfiles, and
Markdown references in addition to shell scripts and config.yaml. Update the
grep command and its surrounding wording so shared mechanisms such as workflow
templates and documented scripts are discoverable before ranking and selecting
an implementation.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 4ff2d095-d007-4a3c-b5ef-531f65c081ec
📒 Files selected for processing (1)
.claude/skills/hassio-addon-workflow/SKILL.md
- 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>
What changed
SKILL.mdalready demanded the simplest solution that works, but said nothing about where thatsolution should come from. A bespoke-but-simple mechanism in one add-on is still a second way to
solve a problem that 120+ add-ons share. Three edits, placed at the points where the choice is
actually made rather than only in the preamble:
.templates/module, an existingcont-init script, the pattern a sibling add-on uses), with the reason stated: one maintainer,
120+ add-ons, so a homogeneous repo beats a locally nicer bespoke design. Covers naming when
something new is genuinely needed (option names, script numbering, file layout).
handles it, the plan is "do what that one does"; not reusing an existing mechanism now requires
saying why.
something that already exists, and will the next add-on with this problem find one way to solve
it or two? Fold the near-duplicate in, or justify the divergence in the PR body.
Verification
file's existing ~100-column convention. Markdown only; no add-on, script, or CI path touched.
in future PRs, not in this one.
CHANGELOG.md/versionbump: no add-on directory is touched, so the add-on CI hard gatesdon't apply.
Rollback
Single-file, single-commit —
git revertrestores the previous wording exactly.🤖 Generated with Claude Code
Summary by CodeRabbit