write-html-component-design

Write HTML component design records documenting element boundaries and rationale.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It captures the design rationale behind HTML custom elements that code and tests alone cannot explain, keeping component decisions documented and discoverable.

Core Features & Use Cases

  • Design Record Authoring: Produces compact HTML component design records covering element boundaries, ownership, anatomy, markup versus CSS, APIs, opt-outs, registration, and bundle cost.
  • Source-Grounded Rationale: Links to existing code, tests, exports, and package metadata instead of duplicating inventories or mechanics.
  • Use Case: When a maintainer asks why a chapter selection element is structured as a custom element, use this Skill to write a short record stating the boundary decision, the non-inferable rationale, and links to the relevant source.

Quick Start

Ask the assistant to write an HTML component design record for a specific component such as chapter selection.

Frequently Asked Questions about write-html-component-design

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

FAQPage Schema
How do I write an HTML component design record?

Explicitly request a design record for a specific component, providing its path or the smallest UI record location. The record states the element boundary, the rationale code cannot explain, and links to relevant source files.

What should an HTML component design document include?

It should state the element boundary and only the rationale or constraints that code and tests cannot explain. Ownership, anatomy, markup versus CSS, APIs, opt-outs, registration, or bundle cost appear only when they explain the decision.

When should I create a component design record?

Create one only on explicit request, when a design decision behind an HTML custom element needs documentation. The record stays a few paragraphs long and links to source rather than copying inventories or mechanics.

Does the design record cover React components too?

No, the record covers HTML custom elements only. A React contract or companion record is not added unless separately and explicitly requested.

Why link to source code instead of copying it into design docs?

Linking keeps the record compact and prevents documentation from drifting out of sync with implementation. Only alternatives or consequences that are material to the decision are included directly.