`rhds-component-api-review` skill

[bennypowers]

Important

Agents working on this issue must read all comments and take them into account, and act according to consensus from discussions in the issue thread.

User story

As an engineer contributing a new element to RHDS, I want my component's public API reviewed against existing RHDS naming conventions, so that attribute names, events, and slots are consistent across the system.

Review custom element API design against RHDS conventions.

Goals

• Custom element authors get consistency feedback before shipping: "your attribute naming diverges from how similar RHDS elements do it"
• API surface (attributes, events, slots, CSS custom properties) follows RHDS naming conventions
• New elements are compared against existing RHDS elements for consistency, reducing API surprises for downstream developers

Non-goals

• Reviewing implementation internals (only the public API surface)
• Enforcing a rigid template; the review provides guidance, not hard rules

Implementation notes

Skill file: plugins/a11y/skills/rhds-component-api-review/SKILL.md

MCP tools and resources:

• cem://elements for discovering existing RHDS elements to compare against
• cem://element/{tagName}/attributes for existing attribute naming patterns
• cem://element/{tagName}/events for event naming conventions
• cem://element/{tagName}/slots for slot naming patterns
• cem://element/{tagName}/css/custom-properties for CSS property naming (--rh- prefix)

Review checks:

• Attribute naming conventions (e.g., variant not type)
• Event naming and payload patterns
• Slot naming and content model
• CSS custom property naming
• Comparison against similar existing RHDS elements

References:

• cem design-api skill in extensions/claude-code/skills/
• patternfly-elements staging/pfv6 branch for PF6 patterns

Open questions

• Target audience: RHDS element authors (internal) or consumers building custom elements on RHDS?

[bennypowers]

like #18 and #13, we might want to drop this, since its focused on building/maintaining RHDS, rather than downstream users.