review-html-component-design

Reviews HTML component design proposals for boundaries, APIs, opt-outs, and bundle cost.

931|91|Updated Aug 13, 2025
One-click install
npx skills add https://github.com/videojs/v10 --skill review-html-component-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: review-html-component-design
Source: https://github.com/videojs/v10/tree/main/.agents/skills/review-html-component-design
Command: npx skills add https://github.com/videojs/v10 --skill review-html-component-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Designing reusable HTML components without a structured review process leads to weak primitive boundaries, bloated APIs, missing opt-outs, and unexpected bundle cost. This Skill provides a repeatable checklist for evaluating component design proposals before they ship.

Core Features & Use Cases

  • Boundary and Ownership Review: Traces data flow across core logic, DOM behavior, and the element, checking lifecycle and cleanup.
  • API and Anatomy Audit: Evaluates light-DOM anatomy, element and CSS APIs, and flags complex selectors like :has() as signs of weak primitive boundaries.
  • Opt-Out and Bundle Verification: Exercises omission, replacement, styling, behavior, and registration opt-outs while weighing API complexity against bundle cost and tree-shaking.
  • Use Case: When reviewing a proposal for a new chapter-menu element in a media player UI, use this Skill to produce prioritized findings on boundaries, accessibility, lifecycle, and bundle impact.

Quick Start

Ask the assistant to review your HTML component design proposal using the review-html-component-design skill and report findings by severity.

Frequently Asked Questions about review-html-component-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review an HTML component design proposal?

Review an HTML component design by tracing ownership and data flow across core, DOM behavior, and the element, then auditing the light-DOM anatomy, element and CSS APIs, and opt-out paths. Report findings by severity with the smallest suggested change.

What makes a good reusable web component primitive?

A good primitive has clear ownership boundaries, a minimal element and CSS API where every addition has a consumer, and leaves visual structure to CSS. Descendant selectors and :has() introduced by composition often signal a weak boundary or missing data-* hooks.

How do I check bundle cost when adding a new component API?

Weigh API complexity against bundle cost by verifying side-effect boundaries and tree-shaking behavior in package metadata and exports. Consult webpack tree-shaking guidance when local precedent is insufficient.

When should a component be split into separate elements?

Split a component when its surface spans independent features that could be separate elements or controllers. First ask whether the proposal is a reusable primitive or an app/skin composition before adding any element or part.

What accessibility checks apply to custom element design?

Check interaction patterns against the WAI-ARIA APG and verify accessibility constraints during the review. Also exercise behavior and registration opt-outs to confirm the element degrades correctly.