---
name: "seminar-html-deck"
description: "Legacy/base version for the user's premium Japanese HTML seminar materials. Use only when the user explicitly asks to keep, reproduce, repair, or update the earlier warm paper/editorial visual style, or when maintaining an existing page originally built with this skill. Do not use this for new requests like HTMLでスライドを作って, HTMLスライドを作って, HTML資料を作って, seminar資料, 勉強会資料, 講義ページ, 前回みたいなHTML資料, or requests for the same quality as the previous Urachika HTML; prefer seminar-html-deck-distinct-ui instead. This legacy skill preserves the original structure, generated-image standard, fact-checking, self-refinement, visual QA, and deploy readiness."
---

# Seminar HTML Deck

Use this skill to turn a user's seminar topic, rough notes, transcript, or teaching outline into a polished Japanese HTML document that feels like a high-quality lecture page: readable, visually rich, practical, and suitable for community sharing.

This is now the legacy/base skill. For most new seminar pages, use `seminar-html-deck-distinct-ui` first because it preserves the quality while avoiding visual sameness. Use this skill only when the user explicitly wants the earlier warm paper/editorial look, or when repairing/updating a page already made in that older visual system.

This skill exists because the user liked the Urachika HTML material built for "AIをオフラインで教えてマネタイズする". Preserve that level of quality, not a minimal webpage.

## Compose With Other Skills

When available, compose this skill with:

- `frontend-design` for production-grade layout, responsive UI, polished HTML/CSS, and visual QA.
- `imagegen` for bitmap illustrations. Images are central to this skill; do not treat them as optional decoration.
- `openai-docs` when the topic involves current OpenAI products, model names, API behavior, or image generation capabilities.

If image generation is unavailable, continue with a clean image plan and prompts, but clearly tell the user that final visual quality is blocked until images are generated.

## Reference Files

Read the relevant references before implementing:

- `references/current_exemplar.md`: what worked in the Urachika deck and what the user corrected.
- `references/lecture_architecture.md`: narrative structure and required sections.
- `references/visual_style_reference.md`: visual language, layout system, and interaction patterns.
- `references/image_generation_playbook.md`: image strategy, prompts, and quality gates.
- `references/implementation_qa.md`: build, browser checks, self-refine, and delivery checklist.

## Default Output

Produce a static HTML seminar document:

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

Prefer a single-file HTML/CSS/JS page plus image assets. Do not create a full app unless the user asks for routing, persistent state, authentication, or complex backend behavior.

If the user asks to deploy, Vercel is a good default for public/unlisted sharing. For community-only sharing without strict auth, deploy the static directory and provide the production URL.

## Workflow

### 1. Understand The Seminar

Extract or ask only what is necessary:

- audience: who will watch/read this
- outcome: what action they should take after the seminar
- core thesis: the one thing the page should make obvious
- source material: notes, transcript, previous docs, URLs, screenshots
- time length: 30/60/90 minutes, if relevant
- tone: practical, encouraging, premium, beginner-friendly, founder-like, etc.

If the user gave enough context, do not stop for questions. Start drafting.

### 2. Build A Teaching Narrative

Before writing HTML, shape the material into a lecture flow:

1. audience pain or current misconception
2. simple thesis
3. why the old/default path is hard
4. why the proposed path is easier or more realistic
5. concrete examples and demos
6. practical action plan
7. warnings/fact-check/safe wording
8. final homework or next step

The page should help the lecturer speak. It should not be a decorative article that leaves the action vague.

### 3. Create A Visual Plan Before Coding

Plan the images first enough to know where the page's visual energy will come from.

Minimum image expectations for a full seminar page:

- 1 hero/executive visual
- 1 concept comparison visual
- 1 workflow/map visual
- 1 demo/menu visual
- 3-5 supporting visuals for tabbed or section-specific examples when the section changes content

Generate real bitmap images for major visuals. SVG fallbacks are acceptable for accessibility or emergency fallback, but never let a simple line placeholder be the visible final state.

### 4. Implement The HTML

Use the Urachika editorial HTML lecture pattern:

- cream paper background with subtle grid/texture
- centered readable shell, not full-width chaos
- sticky progress bar and horizontal table of contents
- bold Japanese headings with section numbers
- `要点まとめ` instead of confusing labels like `TL;DR`
- cards, comparison tables, note bands, dark conclusion block
- interactive tab sections where useful
- worksheet or copyable prompt/output block when the seminar needs action
- sources/fact-check footer

Use icons, not one-kanji badges. The user specifically disliked cards where "難", "近", "空", "壁" were shown as one-letter badges. Replace those with small illustration/icon badges.

### 5. Make Images Large Enough

Every generated image should have enough physical space to be useful:

- Section-defining images should usually span the full content width.
- If a two-column layout makes the image too small, switch to a one-column layout.
- If tabs are above a large image and the content changes below it, repeat the tabs near the content as well.
- On mobile, avoid layouts that make an important image unreadably tiny; consider stacking, cropping carefully, or adding a secondary close-up image.

### 6. Fact-Check And Safer Claims

Use web browsing or official docs for facts that may change:

- AI product names and capabilities
- model names
- pricing
- legal/compliance claims
- platform limits
- deployment behavior
- current screenshots or UI behavior

Prefer official sources. Add a footer with sources when factual claims matter.

For money-making or business claims, use safe wording:

- avoid "誰でも稼げる"
- avoid guaranteed revenue
- say "狙える", "十分あり得る", "相手や内容次第", "実績で単価を上げる"
- separate examples from promises

### 7. Self-Refine Before Delivery

Do a pass as if the user will present this today:

- Is the first viewport clear enough?
- Does each section answer "so what?"
- Are important ideas visible without reading every paragraph?
- Are images meaningful rather than decorative?
- Are all tabs/buttons usable?
- Are there any placeholder-looking visuals?
- Are terms beginner-friendly?
- Are claims safely worded?
- Would a community member understand what to do next?

### 8. Verify In Browser

Always perform a browser QA loop when building or modifying the HTML:

- open the local file or local dev server
- check desktop and mobile screenshots
- verify JS errors are zero
- verify all images load and have nonzero natural dimensions
- click every tab/button/copy interaction
- check text overflow and weird wrapping
- inspect the actual rendered page, not only the code

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

### 9. Deliver Clearly

Final response should include:

- output file path
- screenshot path if generated
- live URL if deployed
- short list of what changed
- verification performed

Keep the response concise unless the user asks for a detailed handoff.

## Important Anti-Patterns

Avoid these:

- plain Markdown-looking pages
- generic SaaS landing pages
- huge marketing hero without teaching substance
- small, low-quality, placeholder images
- visible simple SVG line drawings where a generated illustration was expected
- one-kanji badge labels
- tabs that require scrolling far away from the content they affect
- tables that are the only explanation of an important concept
- unsupported current-tool claims
- dark, blurry, stock-like images
- decorative images that do not teach

## Naming

Suggested output folder pattern:

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

Suggested screenshot pattern:

`artifacts/screenshots/<topic-slug>-desktop.png`

`artifacts/screenshots/<topic-slug>-mobile.png`

## Evaluation Prompts

See `evals/evals.json` for realistic prompts that should trigger this skill. Use them when improving the skill later.
