---
name: "seminar-html-deck-distinct-ui"
description: "Preferred/default skill for new premium Japanese HTML seminar materials. Use this whenever the user says HTMLでスライドを作って, HTMLスライドを作って, HTML資料を作って, seminar資料, 勉強会資料, 講義ページ, community lecture pages, or 前回みたいなHTML資料. Create these with the user's successful Urachika seminar structure, high-quality generated images, fact-checking, self-refinement, browser QA, and deploy readiness, while making the visible UI clearly original. Use this before seminar-html-deck for new work, especially when the user says 前回と同じクオリティ, 前回みたいな構成, 見た目を変えたい, パクリ感を避けたい, 似せたくない, 別デザイン, オリジナルUI, 温かみ, リッチ感, or wants the current Warm Studio/default distinct visual direction."
---

# Seminar HTML Deck: Distinct UI

Use this skill to create a high-quality Japanese HTML seminar document that preserves the strong lecture structure and image-rich teaching style of the user's successful HTML material, while making the visible page design clearly different.

This skill is for situations where the user wants:

- the same seminar usefulness and structure
- the same high-quality image-generation effort
- the same practical lecture flow, QA, and deploy readiness
- a different visual identity so the output cannot be mistaken for a copied look

## Relationship To `seminar-html-deck`

`seminar-html-deck` is the legacy/base quality and structure skill.

This skill is the preferred default for new seminar HTML work:

- keep the lecture architecture
- keep image quality standards
- keep beginner-friendly visual explanations
- change the page's design language deliberately

Use `seminar-html-deck` only when the user explicitly asks to keep the earlier visual style or when repairing an existing old-style page.

Do not treat "distinct UI" as permission to lower clarity. The page should still be seminar-ready.

## Compose With Other Skills

When available, compose this skill with:

- `frontend-design` for production-grade UI, responsive layout, and visual QA.
- `imagegen` for major bitmap illustrations. Keep the generated images strong and educational.
- `openai-docs` when the topic involves current OpenAI products, model names, API behavior, or image capabilities.

If image generation is unavailable, create the image plan and prompts, but clearly state that final visual quality depends on generating the bitmap assets.

## Reference Files

Read the relevant references before implementing:

- `references/design_separation_strategy.md`: how to preserve structure while avoiding look-alike design.
- `references/ui_theme_directions.md`: selectable visual directions that are intentionally different.
- `references/warm_studio_final_pattern.md`: the accepted final pattern from the offline-AI sample; use this as the strongest default when the user wants rich, warm, and original.
- `references/image_policy.md`: what to keep and what to change about image generation.
- `references/lecture_architecture.md`: reusable seminar structure.
- `references/implementation_qa.md`: QA and similarity checks.

## Default Output

Produce a static HTML seminar document:

- `index.html`
- `assets/` containing generated images
- optional `artifacts/screenshots/` for desktop/mobile QA screenshots

Use a single-file HTML/CSS/JS page plus image assets unless the user explicitly asks for a full app.

## Core Rule

Separate "teaching structure" from "visual identity".

Keep:

- section flow
- `要点まとめ`
- large generated explainer images
- comparison tables
- tabbed demo sections
- worksheet/copyable prompt blocks
- fact-check and safe wording sections
- homework/action steps
- dark or high-emphasis conclusion concept
- browser QA and deploy readiness

Change:

- background treatment
- color palette
- typography scale and heading treatment
- navigation style
- card shape and density
- section dividers
- table styling
- tab styling and placement treatment
- conclusion block styling
- image frames and captions
- decorative accents

## Workflow

### 1. Understand The Seminar

Extract:

- audience
- outcome
- core thesis
- source notes/transcript/URLs
- seminar length
- tone
- whether the user has a preferred visual direction

If the user gave enough context, start. Do not block on questions.

### 2. Choose A Distinct UI Direction

Before coding, choose one visual direction from `references/ui_theme_directions.md`, or create a new one.

State it briefly in your own working notes or update:

`Visual direction: Warm Studio Playbook`

Then use that direction consistently.

The user's currently approved default is Warm Studio Playbook: bright warm first view, graphite/teal/gold palette, large rich chapter-number chips, left chapter rail, and large generated illustrations placed inside the body rather than squeezed into the first viewport.

Avoid defaulting to the older warm paper/grid/rust-orange card aesthetic when the user asked for differentiation. Also avoid making the page too dark, hard, or command-center-like unless the user specifically asks for that.

### 3. Build The Lecture Narrative

Use `references/lecture_architecture.md`.

The default arc:

1. hero with thesis
2. `要点まとめ`
3. current pain or misconception
4. comparison/positioning
5. concrete target or audience
6. practical demo menu
7. delivery structure
8. worksheet/action block
9. fact-check/safe wording
10. homework
11. conclusion
12. sources

This structure can remain similar across seminars because structure is not the copyright risk; the visible design should carry the originality.

### 4. Plan Images

Use `references/image_policy.md`.

Important: the user said the hand-drawn/educational image feel may remain. Do not overcorrect by banning warm illustrated diagrams.

Do not change image quality downward. Still generate:

- hero/executive visual
- concept comparison visual
- workflow or map visual
- demo overview visual
- tab-specific/detail visuals when the content changes

The difference should come mainly from the page UI and image framing, not from removing the friendly image quality.

### 5. Implement The HTML

Use a distinct design language. Examples:

- asymmetrical editorial layout
- warm studio playbook with bright premium first view
- crisp white/graphite interface with a bright accent
- modular workshop board
- product-manual style panels
- magazine-course layout
- command-center strategy page

Use icons, not one-kanji badges.

Use Japanese labels instead of unclear English labels like `TL;DR`.

### 6. Fact-Check And Safer Claims

Browse when information may have changed:

- AI product names/features
- model names
- pricing/plans
- legal/compliance or policy claims
- deployment behavior

Prefer official sources. Add a concise source footer when factual claims matter.

For monetization claims, avoid guarantees and use safe wording.

### 7. Self-Refine For Distinctiveness

Before final delivery, compare the design against previous/reference material:

- Does the first viewport feel like a new brand?
- Is the first viewport bright and easy to read unless the chosen theme intentionally needs dark mode?
- Is the background clearly different?
- Are headings treated differently?
- Are chapter numbers large enough to read at a glance?
- Are cards/tables/tabs visually different?
- Does the color palette avoid the previous dominant palette?
- Are images framed and placed differently enough?
- Would a viewer say "same structure, different design"?

If not, redesign before delivery.

### 8. Browser QA

Always verify:

- desktop screenshot
- mobile screenshot
- no JS/page errors
- all images load with nonzero natural dimensions
- tabs/buttons/copy/worksheet work
- no text overflow or overlapping UI
- design remains distinct on mobile

If Playwright's bundled browser is unavailable on Windows, use the installed Edge executable.

### 9. Deliver Clearly

Final response should include:

- output file path
- screenshot path if generated
- live URL if deployed
- chosen UI direction
- verification performed

Keep it concise.

## Anti-Patterns

Avoid:

- copying the previous page's background, color, and card treatment
- making only tiny color changes and calling it new
- warm cream paper + subtle grid + rust accent as the default
- same sticky TOC visual treatment unless redesigned
- one-kanji badges
- placeholder visuals
- low-quality generated images
- reducing image effort just to avoid similarity
- generic landing pages with no seminar utility

## Suggested Output Folder

`generated/html_lecture/<topic-slug>/`

## Evaluation Prompts

See `evals/evals.json` for realistic prompts that should trigger this skill.
