| name | interactive-elements |
| description | Design useful interactive or visual blog elements for a specific article, demo, explainer, case study, or technical note. Use when the user asks for 인터랙티브 요소, interactive HTML, demo page, visual explanation, 3D/spatial interaction, diagrams, animations, or deciding whether interaction would clarify a blog post better than prose alone. |
Interactive Elements
Purpose
Decide whether a blog artifact needs an interactive expression layer, then design the smallest element that makes the idea easier to understand. Interaction is optional. Reject decorative interaction when prose, a static diagram, or a small table is clearer.
Use this skill after the article's main claim and reader value are clear. If the content is still weak, use $content-improvement first.
If the artifact is intended for external publication, interaction design must remain subordinate to $external-publication-review; do not let visual ambition bypass author, source, or public-risk readiness.
Decision Rule
Add interaction only when it helps the reader inspect, compare, simulate, navigate, or feel a transition that static prose cannot show as well.
Good fits:
- A before/after workflow that readers should scrub through.
- A layered system, pipeline, or feedback loop that benefits from spatial navigation.
- A tradeoff surface where readers compare scenarios or constraints.
- A code/demo result where live manipulation reveals the lesson.
- A timeline, decision tree, or artifact archive where exploration is the point.
Poor fits:
- Generic hero effects, decorative particles, gradient blobs, or interaction that only signals polish.
- Drafts whose claim, evidence, or public-safety boundary is not settled.
- Articles where the key value is personal judgment, concise explanation, or a linear argument.
- External-facing demos that rely on unreviewed private data, screenshots, filenames, prompts, logs, or customer-like examples.
Default to skip when the reader action is not obvious in one sentence, the article claim is still changing, or the data/model behind the interaction cannot be made public-safe.
Build Gate
Before recommending light interactive or full interactive, confirm:
- The article's main claim and target reader are stable enough to design around.
- The interaction has one primary reader action, not a collection of effects.
- All labels, states, sample data, media, filenames, URLs, and code-visible strings can be reviewed by
$public-risk-check.
- A static fallback would still communicate the core idea if JavaScript, canvas, 3D, or an external asset fails.
- The element can work on mobile without hover-only controls or text overlap.
Workflow
- Restate the article's core idea and what the reader should understand differently.
- Decide
no interaction, static visual, light interaction, or interactive article/demo.
- If interaction is useful, define the single reader action that matters: scrub, toggle, compare, filter, drag, zoom, run, annotate, or navigate.
- Specify the content model: inputs, states, labels, data, and failure/empty states.
- Specify implementation shape: HTML/CSS/JS, Canvas, SVG, Three.js, embedded demo, or generated image assets.
- Define fallback: static image/table/text summary, reduced-motion behavior, loading/error state, and no-JavaScript path when relevant.
- Define verification: desktop/mobile screenshots, no text overlap, keyboard or pointer behavior, touch behavior, asset loading, reduced-motion behavior, and graceful fallback.
- Mark anything that must be reviewed by
$public-risk-check before external release.
Verification Gate
For built artifacts, do not call the element ready until there is evidence for:
- desktop and mobile layout
- no text overlap or clipped controls
- keyboard access for meaningful controls, or a stated reason keyboard access does not apply
- pointer and touch behavior
- fallback/loading/error state
- reduced-motion handling for animation-heavy elements
$public-risk-check review of visible labels, sample data, media, filenames, URLs, comments, and bundled JSON
Output Contract
Return:
- Recommendation:
skip, static, light interactive, or full interactive.
- Rationale: why this improves comprehension.
- Element spec: reader action, states, content, labels, and constraints.
- Build notes: technology choice and any assets required.
- Fallback plan: how the article still works if the interaction fails or is disabled.
- Verification checklist: what must be tested before publication.
- Publication review notes: labels, data, screenshots, and interaction states that need risk review.
When creating actual frontend files, follow the surrounding project conventions, run the local checks available in the repo, and verify rendered output with screenshots when a browser workflow exists.
Boundaries
Do not use interaction to hide weak content. Do not force 3D unless the concept is spatial, layered, embodied, or navigable. Do not approve external publication from this skill. For public materials, ask $public-risk-check to review labels, example data, screenshots, and demo payloads before publication.
