html

어떤 스킬인가요?

Create or redesign self-contained single-file HTML artifacts with a visual direction shaped by the user's brief, project, and subject. Use when HTML is the deliverable for a report, explainer, landing page, presentation, tool, mixed artifact, or broad request. This is the collection's only implicit router. Route clear wireframe, prototype, mockup, plan, or diagram requests to the matching direct-invocation specialist when available. Do not use for ordinary application implementation when a standalone HTML file is not the deliverable.

설치 방법

프로젝트 폴더에서 아래 명령어를 실행하고, 설치할 에이전트를 선택하세요.

설치 명령을 직접 실행해야 적용됩니다. 지원 에이전트와 필요한 권한·라이선스는 제작자의 안내를 확인하세요.

스킬 원문 파일

interface:
  display_name: "HTML"
  short_description: "Implicit router for standalone HTML artifacts"
  default_prompt: "Use $html to choose the right Effective HTML workflow and create a self-contained artifact from this brief."

policy:
  allow_implicit_invocation: true

# Charts and data

Read this when the artifact contains quantitative charts, metrics, tables, or a data-driven story.

Start with the comparison the viewer needs to make. Select the chart from that question rather than from visual novelty:

- Change over time → line, area, or aligned small multiples.
- Ranked magnitude → ordered bars or a table with visual emphasis.
- Part to whole → stacked bars when the denominator is meaningful; avoid decorative slices.
- Distribution → histogram, dot plot, box plot, or density view.
- Relationship → scatter plot with meaningful scales and annotations.
- Flow → Sankey or network only when path magnitude is genuinely the point.

Use a table when exact values matter more than shape. A chart and a compact table can coexist when they serve different reading needs.

## Make the data honest

- Label units, time ranges, sources, and important filters.
- Use scales that support the intended comparison. Make truncation or nonlinearity explicit.
- Separate measured values, estimates, targets, and forecasts visually and in text.
- Do not invent data to make the artifact look complete. Mark missing or illustrative values plainly.
- Keep color categories consistent and distinguishable without relying on color alone.
- Treat status colors separately from the general palette.
- Give dense data room; contain horizontal overflow rather than compressing labels into illegibility.

## Interaction

Tooltips should add precision, not carry facts that the chart otherwise fails to communicate. Keep essential values and conclusions available without hover.

Filters, brushing, zooming, and linked views should answer real follow-up questions. Show active filters and provide a clear reset. Preserve an accessible summary or table for data that is otherwise available only through pointer interaction.

Use animation to explain change between states, not to make bars and lines perform on arrival.

# Creative direction

Read this when the user or project has not already supplied a complete visual direction.

Operate like a small design studio with range, not a template engine with a favorite costume. Every artifact should feel designed for this commission. A planning memo, systems map, product demo, and launch deck can all show equal care without sharing a palette, typeface, silhouette, or amount of drama.

## Find the direction inside the brief

Start with the subject's own world: its materials, tools, environments, notation, history, audience, and language. Pull one organizing idea from there. It might shape the grid, the behavior of a diagram, the rhythm of the type, the way information reveals itself, or the role of imagery.

Choose a register that fits:

- **Workmanlike:** quiet hierarchy, exact spacing, restrained color, direct language. Right for plans, internal briefs, operational reports, and many tools.
- **Editorial:** stronger composition, distinctive type, art-directed pacing, and one memorable visual move. Right for explainers, launches, research stories, and presentations that need to travel.
- **Expressive:** a more immersive visual or interactive idea whose execution is itself part of the message. Use rarely, when the subject truly benefits.

Do not confuse restraint with neglect or expression with a theatrical hero. Finish the chosen register properly.

## Make a short design plan

Before writing CSS, decide:

- The visual premise in one sentence.
- The hierarchy and organizing layout.
- The color roles and why they belong to the subject.
- The type roles and the voice each contributes.
- The density, edge treatment, and image or diagram language.
- The one place, if any, where motion or interaction carries meaning.

The number of colors, typefaces, columns, and components should follow the idea. Do not satisfy a quota.

## Avoid the template reflex

Common components are not a visual direction. Cards, pills, rounded rectangles, gradients, tiny uppercase labels, large numerals, and side rails may be useful, but each must express real structure. Do not use them merely because they make an unfinished page look designed.

Vary more than color. A new palette on the same centered hero and card grid is still the same design. Reconsider composition, scale, density, typography, shape language, navigation, and interaction.

Use one decisive move rather than many unrelated flourishes. Let the rest of the page support it.

Typography should establish voice and hierarchy. One well-used family can outperform an arbitrary pairing; several roles are useful only when they remain coherent. Use system fonts when they suit the brief. Embed custom fonts only when their value justifies the file weight and their license permits it.

Color should be selected rather than inherited from habit. Neutrals are part of the palette. Status colors must remain semantically distinct from the decorative accent.

## Respect prior art

When the user names a style or supplies a reference, follow it faithfully, even if it resembles a convention you would not choose yourself. When a project has tokens and components, use them before inventing replacements.

Bundled guidance is for technique, not imitation. Never copy a previous artifact's palette, typography, or composition simply because it worked once.

# Diagrams, architecture, and sequences

Read this when relationships, flow, time, state, or structure are the main thing the artifact must explain.

## Choose the diagram before choosing the renderer

Name the question the viewer should be able to answer, then choose the visual grammar:

| Question | Useful grammar |
| --- | --- |
| What exists, and how is it connected? | Topology or system map |
| What happens over time? | Sequence, timeline, or request trace |
| What decisions or transformations occur? | Process flow |
| How can something change? | State diagram |
| What contains or owns what? | Hierarchy or nested boundary map |
| How do alternatives compare? | Matrix or aligned comparison |
| How much, how often, or how fast? | Quantitative chart; also read [`charts-and-data.md`](charts-and-data.md) |

Do not force several questions into one overloaded picture. Use coordinated views or selectable layers when the audience genuinely needs more than one.

## Choose the medium from the information

- **HTML and CSS:** strong for labeled regions, aligned comparisons, grids, timelines, and diagrams whose text needs to reflow.
- **SVG:** strong for crisp relational diagrams, custom paths, annotations, and interactive vector scenes.
- **Canvas:** strong for dense, frequently changing, or generative graphics where thousands of DOM nodes would be wasteful.
- **WebGL:** reserve for spatial, high-volume, or truly three-dimensional work that earns the added complexity.

Mix media when useful. A diagram can use semantic HTML controls and explanation around an SVG or Canvas stage.
Style SVG elements through CSS classes and the artifact's chosen tokens when practical so the scene remains coherent across states and themes.

## Make the structure legible

- Establish hierarchy with position, grouping, containment, scale, and whitespace before reaching for color.
- Keep labels readable at the default view. Do not rotate important prose or place text over busy paths.
- Route connectors around nodes and labels. Make direction unmistakable and distinguish different edge meanings.
- Use boundaries to communicate ownership, trust, deployment, or responsibility, not as decoration.
- Keep a stable overview while exposing detail on demand.
- For architecture, show the concepts the audience uses. File names and implementation classes belong only when the question is specifically about code structure.

Avoid the automatic architecture wallpaper of identical rounded boxes connected by arrows. Services, queues, actors, boundaries, stores, and transformations do not all need the same shape or visual weight.

## Sequence and interaction

Sequence should expose causality, not merely flash elements in order.

- Give steps durable labels and a visible current state.
- Let the viewer play, pause, restart, step, or choose a path when the sequence is more than a brief self-explanatory animation.
- Keep the full system understandable when animation is stopped.
- Use motion to trace requests, reveal transitions, or connect cause with effect. Respect `prefers-reduced-motion` with an immediate or step-based alternative.
- Use filtering and layer toggles when they reduce complexity without hiding necessary context.

If nodes expose details, make selection obvious. Floating panels must be dismissible and must reopen from the relevant node or control. Important information must remain reachable by keyboard.

## Pan and zoom only when needed

A clear diagram that fits should not become a map application. Add pan and zoom when the information space materially exceeds the viewport or close inspection is part of the task.

For an SVG stage:

- Transform one containing `<g>` rather than rewriting every node.
- Keep pointer, pan, and zoom math in a single coordinate system. Preserve the point under the cursor while zooming.
- Suppress click activation after a drag using a small movement threshold.
- Provide `grab` and `grabbing` feedback, a visible zoom level, and a reset control.
- Set useful minimum and maximum scales and ensure the initial fit is understandable.

## Verify the picture

Inspect the default overview, every interactive state, and any sequence endpoints. Check that connectors do not cross labels, arrows terminate cleanly, text remains legible, panels do not cover critical content, and narrow-screen behavior has an intentional fallback.

# Documents and presentations

Read this for reports, briefs, plans, explainers, comparisons, and slide-like artifacts.

## Documents

Design around the reader's decision or understanding, not around a generic page outline. The opening should orient quickly: what this is, why it matters, and what deserves attention. Follow with evidence, structure, and detail in the order the reader needs them.

- Keep prose measures readable and let tables, timelines, code, and diagrams use wider regions.
- Use headings, labels, numbering, dividers, and callouts only when they express genuine hierarchy or sequence.
- For plans, stay close to the user's language and ambition. Clarify ownership, order, dependencies, risks, and completion conditions without inventing a larger program.
- For reports, distinguish observation, interpretation, recommendation, and uncertainty.
- For comparisons, keep like-for-like attributes aligned so the eye can compare without remembering.
- For print-oriented work, add sensible print styles and avoid interactions that hide essential content.

Most operational documents want a workmanlike register. They still deserve intentional typography, spacing, and color, but rarely need a giant hero or ornamental dashboard furniture.

## Presentations

A presentation is paced, not merely paginated. Give each screen one job and one dominant idea.

- Establish a visual rhythm across slides, then break it only for emphasis.
- Keep essential information visible without hover.
- If the file behaves like a deck, support keyboard navigation, clear progress, and direct slide links when practical.
- Use builds and transitions to control explanation order, not to decorate every change.
- Ensure a useful narrow-screen or scrolling fallback when the fixed stage cannot fit.

When a request blends a document and a deck, prefer the reading mode the audience will actually use rather than building two half-working experiences.

# Interfaces and tools

Read this for editors, calculators, control panels, and other broad HTML artifacts people operate rather than read straight through. Use `html-prototype` for a styled mockup or a bounded product flow when that skill is available.

Lead with the current state and the next useful action. Organize the interface around the user's task, not the shape of the underlying data model.

- Make controls look actionable and label them with the result they produce.
- Show feedback close to the action: pending, success, empty, validation, and error states should all be designed.
- Preserve state visibly. Selected filters, active modes, changed values, and unsaved work should never be mysteries.
- Put summaries before detail when scanning matters, while keeping the path to the underlying evidence obvious.
- Use status color for status, independently from the artifact's decorative accent.
- Keep forms keyboard-friendly, labels explicit, targets comfortably sized, and destructive actions difficult to trigger accidentally.
- Prefer a few strong regions over a uniform grid of interchangeable cards.

Implement the important path when behavior is part of the request. A convincing static shell with dead controls is worse than a simpler interface whose important path works end to end.

On narrow screens, preserve the primary task. Reflow secondary panels, turn dense toolbars into deliberate controls, and contain wide data rather than shrinking it until it is illegible.

---
name: html
description: Create or redesign self-contained single-file HTML artifacts with a visual direction shaped by the user's brief, project, and subject. Use when HTML is the deliverable for a report, explainer, landing page, presentation, tool, mixed artifact, or broad request. This is the collection's only implicit router. Route clear wireframe, prototype, mockup, plan, or diagram requests to the matching direct-invocation specialist when available. Do not use for ordinary application implementation when a standalone HTML file is not the deliverable.
---

# HTML

Build one self-contained HTML file that makes the subject clearer, easier to use, or easier to understand. The standard is consistent care, not a consistent look. Do not reproduce a house palette, typography stack, card system, or layout from prior runs.

## Route the request first

Use the narrowest skill that owns the main review question:

- Read and compose [`design-artifact`](../design-artifact/SKILL.md) with the
  chosen workflow when palette, type, composition, theming, or overall visual
  register remain open. It provides creative direction; it does not replace the
  specialist that owns fidelity, structure, or behavior.
- Read and follow [`html-wireframe`](../html-wireframe/SKILL.md) when structure, information hierarchy, navigation, or task flow is still unsettled. It should remain visibly low fidelity and may compare two or three layout directions.
- Read and follow [`html-prototype`](../html-prototype/SKILL.md) when the user needs a polished mockup or a working interactive flow. A mockup is the static fidelity mode inside that skill.
- Read and follow [`html-plan`](../html-plan/SKILL.md) when the artifact is primarily a plan, roadmap, implementation sequence, or rollout document whose source commitments must remain easy to verify.
- Read and follow [`html-diagram`](../html-diagram/SKILL.md) when relationships, sequence, topology, state, hierarchy, or system behavior are the main content.
- Continue with `html` for reports, explainers, presentations, landing pages, data stories, tools, and mixed artifacts that do not have a clearer owner.

These sibling links are the nesting mechanism when the collection is installed together. If a specialized skill is unavailable, continue here and load the closest reference below. Do not make the user install another skill before completing the request.

## Read the room before designing

Inspect the user's request and any material they supplied. When working in a repository, look for its design language in `AGENTS.md`, `CLAUDE.md`, design-system documentation, tokens, existing components, and nearby artifacts.

Authority runs in this order:

1. The user's explicit visual and functional instructions.
2. The project's established design system and conventions.
3. The subject matter, audience, and purpose of this artifact.
4. Your own design judgment.

Before coding, settle five things in working notes:

- **Audience and job:** who will use this, and what should they understand or do?
- **Form:** document, presentation, interface, diagram, or data visualization.
- **Register:** quiet and workmanlike, polished and editorial, or intentionally expressive.
- **Fidelity:** whether to preserve the user's structure and wording or synthesize more freely.
- **Interaction:** what benefits from exploration, sequencing, filtering, or motion, if anything.

If the project already answers the visual questions, follow it. Otherwise read
and compose [`design-artifact`](../design-artifact/SKILL.md) when it is
available. If the collection was installed without that sibling skill, read
[`references/creative-direction.md`](references/creative-direction.md) before
choosing the palette, type, composition, or motion.

## Load only the guidance the artifact needs

- For reports, briefs, plans, explainers, and decks, read [`references/documents-and-presentations.md`](references/documents-and-presentations.md).
- For interfaces, calculators, and other tools that remain in this broad skill, read [`references/interfaces.md`](references/interfaces.md).
- For architecture, process, sequence, state, hierarchy, or concept diagrams, read [`references/diagrams.md`](references/diagrams.md).
- For quantitative charts, tables, metrics, or data stories, read [`references/charts-and-data.md`](references/charts-and-data.md).

Requests can span forms. Read every reference that materially applies, then give the artifact one coherent direction.

## Build contract

- Produce one `.html` file with its essential CSS and JavaScript inline. It should work when opened directly, without a build step. Do not require a network connection unless the user permits external dependencies.
- Use real content. Do not fill prominent space with placeholder copy, decorative statistics, or controls that do nothing.
- Let content determine structure. A sequence should read in order; a comparison should make differences easy to scan; an interface should expose state and actions; a diagram should make relationships legible.
- Use semantic HTML, responsive layout, accessible contrast, visible keyboard focus, and reduced-motion handling. Make interactive elements work with a keyboard.
- Keep the page body free of accidental horizontal overflow. Put intentionally broad content in a contained scrolling or pannable region.
- Define a small set of CSS tokens for the chosen direction and use them consistently. Tokens are an implementation tool, not a predetermined palette.
- Treat motion as explanation or feedback. If removing an animation loses no meaning or useful feedback, remove it.
- Follow the user's or project's theme policy. When none exists, give durable utility artifacts considered light and dark themes if that improves their use. A deliberate single-theme concept is valid.

## Finish the work

Write the file to the requested location, or choose a clear filename in the current workspace. When browser tooling is available, open it and inspect a wide and narrow viewport. Exercise its controls, check the console, and fix clipping, overlap, illegible text, broken states, and accidental overflow.

Before delivery, run one originality check: if the subject were swapped for a neighboring topic, would the same visual concept still make just as much sense? If yes, the direction is too generic; revise the composition, type, color, imagery, or interaction so it belongs to this subject.

Return the absolute path and a short description of the artifact's visual and interaction choices.