agentleFS
timmo001timmo001/skills/home-assistant-lit-rendering/SKILL.md

home-assistant-lit-rendering

Skill2 starsChanged todayApache-2.0View on GitHub

Home Assistant Lit rendering extensions for HA components and context-aware picker callback shape. Use with lit-rendering only when editing or reviewing Lit render logic inside a Home Assistant frontend (home-assistant/frontend) checkout or a Home Assistant custom card or dashboard repository.

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep Home Assistant-specific rendering aligned with existing ha-* component patterns.

    line 12
  2. Distinctive:

    When adding editor tabs or controls, gate them by the same HA mode/capability checks used by the existing action path.

    line 13
  3. Very specific:

    Keep .sections and .getItems aligned to the same current-render source.

    line 17
  4. Very specific:

    When values come from Home Assistant context (hass, consumed i18n/config contexts), avoid introducing passthrough fields just to route …

    line 18
  5. Distinctive:

    Prefer existing Home Assistant references before introducing a new local rendering shape:

    line 19

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Home Assistant Lit Rendering

Use this skill together with lit-rendering when editing Lit code inside a Home Assistant frontend (home-assistant/frontend) checkout or a Home Assistant custom card or dashboard repository. Do not apply it to other projects. In custom cards and dashboards, the reference paths below are under vendor/home-assistant-frontend/ when that submodule is present.

  • Keep Home Assistant-specific rendering aligned with existing ha-* component patterns.
  • When adding editor tabs or controls, gate them by the same HA mode/capability checks used by the existing action path; do not expose UI for YAML, generated, read-only, or unsupported modes just because optional callbacks are present.
  • For ha-generic-picker, match repository callback shape:
    • .getItems=${this._getItems} when callback reads existing component state.
    • .getItems=${this._getItems(optionsOrSections)} when callback closes over render-local data.
  • Keep .sections and .getItems aligned to the same current-render source.
  • When values come from Home Assistant context (hass, consumed i18n/config contexts), avoid introducing passthrough fields just to route those values.
  • Prefer existing Home Assistant references before introducing a new local rendering shape:
    • src/components/ha-selector/ha-selector-select.ts
    • src/components/ha-target-picker.ts
    • src/components/ha-navigation-picker.ts

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.