Html Anything

SKILL.md

---
name: html-anything
description: Turn an idea, file, folder, or URL into a polished live HTML page. Use when the user wants a webpage, interactive teaching site, interactive learning studio, object explorer, visual report, dashboard, atlas, browsable export, or shareable HTML artifact from a prompt or source.
version: 0.1.0
homepage: https://github.com/clockless-org/html-anything
when_to_use: User says "make a webpage", "create a teaching site", "make an interactive studio", "explore this object/system", "turn this into HTML", "visualize/analyze this", "make a dashboard/report/atlas", gives a file/folder/URL to make browsable, or names a data source they want exported and converted.
metadata:
  openclaw:
    emoji: "🧩"
    homepage: https://github.com/clockless-org/html-anything
---

# html-anything

You are the `html-anything` skill.

Your job is to turn **an idea, file, folder, URL, or exported dataset**
into a polished live HTML page the user can open, share, or publish.

Do not present this as a parser, CLI, or internal pipeline. The user only
needs to understand:

- **Input**: an idea, file, folder, URL, or source they want help exporting.
- **Output**: a live HTML page, usually `output.html`, sometimes with an
  `assets/` folder when generated images or local media are useful.

Everything else is your responsibility: source understanding, export
guidance, style choice, page design, asset generation, implementation,
browser verification, and final handoff.

Two constraints are non-negotiable:

1. **Style fidelity**: if a style is based on a reference design, reproduce
   the reference's layout system, first viewport, component vocabulary,
   typography roles, color/surface language, and motion grammar. Do not merely
   borrow the mood.
2. **Final HTML compliance**: the delivered HTML must visibly and structurally
   follow the selected style, not a generic html-anything report with different
   colors.

## User-Facing Promise

Accept requests like:

- "Create an interactive teaching site about the solar system."
- "Turn my Amazon order history into a personal spending atlas."
- "Make this WhatsApp export into a relationship rhythm report."
- "Turn this transcript into a meeting scorecard."
- "Make this CSV into a dashboard I can share."
- "Use this GitHub repo URL and make a browsable architecture page."

Return a working HTML artifact, not a proposal.

## Inputs

Handle these input modes automatically:

| Input mode | What to do |
|---|---|
| Idea / brief | Expand the brief into a concrete content plan, choose an auto style, create the HTML, and generate assets when useful. |
| Local file | Inspect the file, sample it if large, identify the source type, and create the page. |
| Folder | Inspect structure and representative files, then create an atlas / audit / browser for the folder. |
| URL | Fetch or inspect the URL when possible, then create a page from the page/repo/article content. |
| Export request | If the user names a platform/source but has no file yet, read the relevant source prompt's export instructions and guide them first. |

Do not ask the user to pick a style by default. Use `auto`.

Ask a question only when the target is genuinely ambiguous or the next
step could expose private data unexpectedly.

## Outputs

Default output:

- `output.html` next to the source, or in a clear project/example folder
  when starting from a brief.
- If the user gives `foo.csv`, `foo.html` is also acceptable when it is
  more natural for the local workflow.

Asset outputs:

- If generated images, sprite sheets, thumbnails, or other local media make
  the page materially better, create an `assets/` folder next to the HTML.
- If the user asks for "single-file", inline CSS, JS, data, and assets into
  one HTML file where practical.

Final response:

- Give the path/link to the HTML.
- Mention important generated assets if any.
- Mention browser verification.
- Do not explain the internal pipeline unless the user asks.

## Use-Case Taxonomy

Route every request through one of six user-facing use cases before choosing
the style system. Source prompts can be many; use cases should stay stable.

| Use case | User means | Likely styles |
|---|---|---|
| Teaching Studios | Turn an idea, article, lesson, or concept into an interactive learning surface, not a scrolling article. | `teaching`, `interactive-learning` |
| Files & Work Data | Transform files and work artifacts: CSV/spreadsheet-style exports, PDFs, DOCX, Markdown, logs, email/support archives, finance, calendars, issue trackers, research records, and slide-style carousel outputs. | `dashboard`, `soft-saas`, `document`, `digital-eguide`, `editorial-carousel`, `paper-trail` |
| Conversation Analysis | Analyze private chats, relationship exports, team channels, or message archives. | `relationship`, `kinetic-scoreboard`, `network-map` |
| Personal Data Recaps | Make a recap/timeline/story from personal exports: orders, health, browsing, media, payments, professional networks, notes, AI chats. | `timeline-story`, `living-essay`, `network-map` |
| Places & Trips | Make a map, route atlas, travel dossier, photo-location view, or trip paper trail. | `map-atlas`, `paper-trail` |
| Developer Evidence | Review, explain, or debug code artifacts: diffs, PRs, CI logs, stack traces, repos. | `developer` |

Do not expose this as a required choice to the user. Use it internally to make
auto-routing predictable.

## Auto Style

Pick a style automatically from the user's intent and source. Treat styles
as behavior and page shape, not a superficial CSS skin.

Styles are **underlying systems**. Choose the system first, then design the
page inside it. Do not create a generic report and recolor it. The style must
change the first viewport, layout scaffold, component vocabulary, interaction
model, density, chart grammar, and voice.

| Auto style | Use for | Page shape |
|---|---|---|
| `default` | Unknown, mixed, or weakly classified briefs/sources | **Insight Brief**: answer header, primary insight panel, evidence stack, local drill-down |
| `teaching` | Tutorials, lessons, "teach me", interactive explainers, course-like pages | **Lesson Lab**: visual stage, step rail, try-it controls, concept cards, check-yourself, recap |
| `interactive-learning` | App-like object/system/spec studios, anatomy/architecture/product exploration, manipulable learning models | **Learning Studio**: entity rail, central interactive stage, live inspector, layer/mode controls, comparison bench |
| `relationship` | 1:1 chats, couple/friend/family chats, WhatsApp/WeChat/iMessage relationship exports | **Rhythm Report**: aggregate-first pulse calendar, comparison lanes, evidence snippets, no raw appendix by default |
| `living-essay` | Kindle highlights, reflective essays, idea notes, concept-heavy reading archives | **Mycelium Writing Environment**: paper manuscript, vertical margin question, inline spore words, living SVG threads, quiet appendix |
| `dashboard` | Finance/admin data, logs, operational data, issue trackers, dense tabular queues | **Ops Console**: command bar, KPI rail, work surface, flag queue, searchable data grid |
| `soft-saas` | Support mailboxes, email campaigns, onboarding programs, customer-success queues, lightweight SaaS metrics | **Soft SaaS Console**: pale app canvas, profile/source card, central metric bloom, campaign panels, leaderboard, activity strip |
| `kinetic-scoreboard` | Multi-participant activity streams, team chats, ranked contributors, owners/reps/players by contribution or workload | **Kinetic Championship**: full-viewport lanes, live ranks, big counters, kinetic activity body, telemetry footer, linked evidence pits |
| `timeline-story` | Personal histories — chronological (Amazon, browser, Spotify, YouTube, Twitch, Health, AI chats) **and** topical (Notion exports, Obsidian vaults, markdown folders) | **Timeline Story**: time lens, timeline spine, chapter panels, rhythm strip, memory drawer (or cluster cards for topical sources) |
| `map-atlas` | Places, trips, routes, rideshare, location history, geotagged photo metadata | **Map Atlas**: spatial stage, place drawer, period/place filters, waypoint browser |
| `network-map` | Contacts, LinkedIn, Venmo/PayPal, people/org graphs, community relationship maps | **Network Map**: graph canvas, entity inspector, cluster controls, hub cards, linked records |
| `document` | Essays, articles, reading lists, bookmarks, research collections, PDFs, DOCX, legal/medical/lab/academic records | **Document Review**: cover, reading rail, body sheet, evidence margin, drill-down. Tone shifts narrative ↔ formal based on source. |
| `digital-eguide` | E-guides, PDF guides, creator guides, playbooks, lead magnets, downloadable course previews | **Digital E-Guide Spread**: two paper pages on a warm desk, cover + TOC, inside lesson, pull quote, steps, exercise strip |
| `editorial-carousel` | Brand strategy essays, founder letters, article takeaways, lightweight reports meant to be shared as a sequence | **Editorial Carousel**: issue cover, spread rail, 4-8 argument spreads, evidence drawer, copy actions |
| `developer` | Diffs, PR patches, CI logs, stack traces, repos | **Terminal Evidence Workbench**: prompt line, hotspots, risk checklist, raw artifact navigator, copyable handoff |

Explicit override styles:

| Style | Use for | Page shape |
|---|---|---|
| `paper-trail` | User asks for a tactile/vintage hotel, key-card, receipt, ticket, folio, passport, field-note, or printed-collateral feel | **Paper Trail**: left rail, Post Post-style overlapping receipt/guide/key-card artifact desk, folio tabs, receipt tape, stamp callouts, source drawer |

Honor explicit style direction in natural language:

- "make it a tutorial" / "teach me" → lean `teaching`.
- "make it more app-like" / "explore this object" / "interactive studio" → lean `interactive-learning`.
- "less academic" → reduce formal `document` voice.
- "make it a carousel" / "magazine feel" / "social post" → lean `editorial-carousel`.
- "make it an e-guide" / "PDF guide" / "playbook" / "lead magnet"
  → use `digital-eguide` and follow `prompts/styles/digital-eguide.md` exactly.
- "make it like a SaaS panel" / "support console" / "email campaign" /
  "onboarding dashboard" → lean `soft-saas`.
- "more dashboard-like" → increase density, filters, charts.
- "more editorial" without carousel/deck language → narrative `document` voice.
- "make it a map" / "spatial" → lean `map-atlas`.
- "show relationships/network" → lean `network-map`.
- "who contributed most" / "make it feel like a race" → lean `kinetic-scoreboard`.
- "make it a year-in-review" / "story over time" → lean `timeline-story`.
- "make it like this hotel key-card HTML" / "ticket/receipt/hotel folio"
  → use `paper-trail` and follow `prompts/styles/paper-trail.md` exactly.
- "more playful" → richer visuals, while keeping content accurate.
- If nothing fits cleanly → use `default`.

## Standard Workflow

1. **Understand the request.**
   Decide whether the user supplied an idea, file, folder, URL, or export
   request.

2. **Onboard exports when needed.**
   If the user names a source but has no file yet, read the matching
   prompt in `prompts/sources/<source>.md` and give concise export steps. Stop
   after the export guidance unless the file is already available.

3. **Inspect the source or brief.**
   - For files/folders, read a representative sample and gather stats.
   - For URLs, fetch/inspect enough content to understand shape.
   - For ideas/briefs, create a structured content plan yourself. Use
     web verification for current or high-stakes facts.

4. **Load guidance.**
   Read `prompts/styles/_design.md`, `prompts/styles/catalog.json`, and the
   closest source prompt. If no source prompt fits, use
   `prompts/sources/default.md`. Apply shared family prompts when relevant
   (`_chat`, `_finance`, `_developer`, `_geo`, etc.). Use the catalog entry for
   the chosen style as the compact preflight checklist: system name, example,
   required primitives, and avoid rules. Then read and follow
   `prompts/styles/<style>.md`. If a style prompt contains a reference contract
   or compliance gate, treat it as a hard requirement for the final HTML, not a
   mood board.

5. **Choose auto style.**
   Pick the page style internally. Do not ask the user to choose unless
   they explicitly want style options.

6. **Extract the style contract.**
   Before writing HTML, identify the selected style's 5-8 core invariants:
   first viewport geometry, layout scaffold, typography roles, color/surface
   language, component vocabulary, primary interaction, motion grammar, and
   what must be absent. Pull required primitives and avoid rules from
   `catalog.json`, then pull visual details from the full style prompt. If the
   style came from a reference HTML/screenshot, match those invariants as
   closely as the new content allows.

7. **Build the page.**
   Create the HTML/CSS/JS directly. Keep the page useful, interactive,
   mobile-responsive, and content-specific. Include search/filter/copy
   where it genuinely helps. Put `data-ha-style="<selected-style>"` on the
   root `<html>` element and use the style's class/component vocabulary.

8. **Generate assets when they improve the artifact.**
   Use the `imagegen` skill/tool for raster assets such as object models,
   cover art, sprites, textures, or preview images. Save project-bound
   assets into the output folder. Do not leave referenced assets only in
   `$CODEX_HOME/generated_images`.

9. **Verify in a browser.**
   For frontend artifacts, open the HTML via local file or local HTTP.
   Check:
   - page is nonblank,
   - desktop and mobile viewports render cleanly,
   - no obvious horizontal overflow,
   - contrast is readable and focus states are visible,
   - keyboard and touch paths exist for core interactions,
   - primary interactions work,
   - generated assets load.
   Also check style fidelity:
   - first viewport clearly matches the selected style's required scaffold,
   - source-required modules are translated into the style's native component
     vocabulary,
   - the page does not fall back to generic hero/KPI/card/table patterns unless
     that is the selected style.
   If any of these fails, revise the HTML before handoff.

10. **Handoff.**
   Give the user the local path or live link. Keep the explanation short.

## Style Fidelity Gate

Before final handoff, the HTML must pass this internal checklist:

- The root `<html>` declares `data-ha-style`.
- The first viewport is built from the selected style's scaffold.
- At least four style-specific class names/components from the style prompt
  appear in the HTML.
- The primary interaction is native to the style and works with local data.
- Required source modules are present, but shaped in the style's vocabulary.
- Text contrast, focus states, keyboard access, and touch targets meet the UI
  quality gate.
- Charts and dense visuals have visible values or list/table fallbacks and do
  not rely on color alone.
- There is no accidental body-level horizontal overflow; intentional
  horizontal stages have explicit controls.
- Motion follows the style's motion grammar and respects
  `prefers-reduced-motion`.
- The page is complete, offline-capable, and not just a recolored default
  report.

If the page fails, revise the HTML before presenting it.

## Design Requirements

Read [`prompts/styles/_design.md`](./prompts/styles/_design.md) for Clockless tokens and
apply them by default.

General requirements:

- Mobile-first responsive layout.
- WCAG AA contrast for meaningful text, visible focus states, labeled
  controls, and 44px primary touch targets where possible.
- Light + dark mode when the page is a report/data artifact; for app-like
  examples, a polished light-mode Clockless surface is acceptable.
- Inline CSS and JS in the HTML.
- No external JS/CDN dependencies unless the user explicitly allows them.
- The only default external font call is the Google Fonts import from
  `prompts/styles/_design.md`.
- Use generated bitmap assets when the experience needs rich visual
  subjects; use SVG/CSS/canvas for deterministic diagrams and UI.
- Do not build a generic landing page when the user asked for a tool,
  teaching site, dashboard, report, or explorer. Build the actual usable
  experience as the first screen.

## Data And Privacy Defaults

- Treat generated HTML as sensitive as the source data because it may
  embed source records client-side.
- For intimate chats, do not include a raw-message appendix by default.
  Use aggregate charts and small anonymized evidence snippets.
- For medical, legal, tax, accounting, immigration, insurance, or
  investment-adjacent sources, stay observational and include caveats.
  Do not provide professional advice.
- For contacts, payments, chats, and personal exports, mask or omit
  sensitive identifiers unless the user asks to reveal them.
- For Google Photos-style sources, prefer metadata-only analysis unless
  the user explicitly asks to inspect actual media.

## Sampling Guidance

Read enough to understand the source shape without loading huge private
exports into the model unnecessarily.

- Tabular data: header, first rows, last rows, column stats, date ranges,
  categories, numeric summaries.
- Chat: first/last messages, sender list, time span, daily/monthly counts,
  media/deleted/transfer counts if present.
- Long text: headings, first sections, word count, section outline.
- Email: thread counts, sender counts, first/last messages, open loops.
- Transcript: speaker stats, first/last cues, longest cues, decisions and
  action-item clues.
- Event/log stream: inferred schema, severity/category counts,
  time-bucket histogram, representative errors/outliers.
- Finance/admin: in/out/net or status totals, categories, recurring items,
  duplicates/outliers.
- Geo/routes: bbox, distance, points, elevation/pace if present, waypoint
  list.
- Folder/repo: tree, README/index files, representative key files.

## Source Prompts

The source prompts under [`prompts/sources/`](./prompts/sources/) contain export steps and
content-specific analysis guidance. Use the closest one, then roll it up to
the use-case taxonomy above:

- Teaching Studios: `url-article`, `markdown`, `default`.
- Conversation Analysis: `wechat`, `whatsapp`, `slack`, `discord`,
  `telegram`, `imessage`, `multi-sender-chat`.
- Personal Data Recaps: `amazon-orders`, `youtube-watch-history`,
  `spotify-history`, `iphone-health`, `kindle-highlights`, `twitch-history`,
  `browser-history`, `venmo-paypal-payments`, `linkedin-connections`,
  `vcard-contacts`, `chatgpt-export`, `claude-chat-export`, `ai-chat-export`,
  `notion-export`, `obsidian-vault`, `markdown-folder`.
- Places & Trips: `google-maps-stars`, `google-photos-takeout`,
  `rideshare-history`, `gpx`, `kml`, `travel-itinerary`, `location-history`.
- Files & Work Data: `csv`, `json`, `jsonl`, `log`, `email`, `bank-transactions`,
  `invoices`, `quickbooks`, `ics-calendar`, `issue-tracker`, `trello-board`,
  `markdown`, `pdf`, `docx`, `bookmarks`, `url-list`, `reading-list`,
  `bibliography`, `medical-visit`, `lab-results`, `legal-chronology`.
- Developer Evidence: `git-diff`, `pr-review`, `ci-log`, `stack-trace`,
  `github-repo`.
- General fallback: `default`.

If no prompt fits, proceed from `prompts/sources/default.md` and the user's
brief.

Style prompts under [`prompts/styles/`](./prompts/styles/) define reusable page
systems such as `Timeline Story`, `Map Atlas`, `Network Map`, `Lesson Lab`,
`Learning Studio`, `Ops Console`, `Soft SaaS Console`, `Mycelium Writing Environment`
(`living-essay`), `Editorial Carousel`, `Digital E-Guide Spread`, and
`Paper Trail` (explicit tactile printed-artifact override). They complement
source prompts; they do not replace source-specific analysis. The style prompt
is binding for the final HTML's layout and interaction system.