document-integration-docs

Run the skill with the integration domain, for example /document-integration-docs lock. It inventories Core triggers, conditions, and actions, then creates or updates the integration page and one split page per feature following the developer examples template.

Each split page is named source/_triggers, source/_conditions, or source/_actions followed by domain.key.markdown, using exact Core keys. Pages must follow the developer examples template section-for-section with two concrete automation examples.

Yes, Core is treated as the source of truth. The skill inspects conditions.yaml, services.yaml, triggers.yaml, strings.json, and frontend translations to verify keys, target domains, and UI labels rather than trusting issue text.

Categories not implemented in Core are simply not documented, and no split pages are created for them. The integration page then uses only the applicable individual include lines instead of the combined triggers_conditions_actions include.

UI wording rules require dropping the domain prefix so labels match what users see, such as writing Turn on light instead of Light: Turn on light. Labels are taken from Core strings.json to stay consistent with the frontend.