{"id":"0c73e97d-218b-4380-88d0-866820e16b28","entityType":"agent","slug":"clawhub-kelvin-clockless-html-anything","name":"Html Anything","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kelvin-clockless-html-anything","canonicalPath":"/agent/clawhub-kelvin-clockless-html-anything","generatedAt":"2026-10-11T07:35:59.158Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":null},"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,... Skill: Html Anything Owner: kelvin-clockless Summary: 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,... Tags: latest:0.1.0 Version history: v0.1.0 | 2026-05-12T02:46:35.988Z | auto Initial release of html-anything. - Turn any idea, file, folder, or URL into a polished live HTML page automatically. - Supports","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17fzwpvft6nje88a8gvp47xq586jd7y:html-anything","sourceUrl":"https://clawhub.ai/kelvin-clockless/html-anything","homepage":"https://clawhub.ai/kelvin-clockless/skills/html-anything","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kelvin-clockless/html-anything","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kelvin-clockless/skills/html-anything","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"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,..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":null},"stars":null,"forks":null,"downloads":1152,"packageName":null,"latestVersion":"0.1.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:05:00.847Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T05:05:00.862Z","lastCrawledAt":"2026-10-11T05:05:00.847Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T05:05:00.847Z","lastVerifiedAt":null,"highlights":[{"version":"0.1.0","createdAt":"2026-05-12T02:46:35.988Z","changelog":"Initial release of html-anything. - Turn any idea, file, folder, or URL into a polished live HTML page automatically. - Supports interactive teaching sites, dashboards, atlases, visual reports, object explorers, and more. - Handles a wide variety of input modes (briefs, files, folders, URLs, or data exports) with auto style and output selection. - Ensures strict fidelity to reference designs and delivers browser-verified, shareable HTML artifacts. - Automatically chooses layout, style, and assets based on use-case taxonomy—no user style selection needed.","fileCount":94,"zipByteSize":296392}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17fzwpvft6nje88a8gvp47xq586jd7y:html-anything","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T07:35:59.154Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kelvin-clockless-html-anything/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":null},"readme":"Skill: Html Anything\n\nOwner: kelvin-clockless\n\nSummary: 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,...\n\nTags: latest:0.1.0\n\nVersion history:\n\nv0.1.0 | 2026-05-12T02:46:35.988Z | auto\n\nInitial release of html-anything.\n\n- Turn any idea, file, folder, or URL into a polished live HTML page automatically.\n- Supports interactive teaching sites, dashboards, atlases, visual reports, object explorers, and more.\n- Handles a wide variety of input modes (briefs, files, folders, URLs, or data exports) with auto style and output selection.\n- Ensures strict fidelity to reference designs and delivers browser-verified, shareable HTML artifacts.\n- Automatically chooses layout, style, and assets based on use-case taxonomy—no user style selection needed.\n\nArchive index:\n\nArchive v0.1.0: 94 files, 296392 bytes\n\nFiles: prompts/sources/_ai_chat_export.md (10808b), prompts/sources/_chat.md (8184b), prompts/sources/_developer.md (5801b), prompts/sources/_document.md (3281b), prompts/sources/_event_stream.md (10382b), prompts/sources/_finance.md (13025b), prompts/sources/_geo.md (12859b), prompts/sources/_knowledge_base.md (9633b), prompts/sources/_planning.md (12548b), prompts/sources/_research.md (13309b), prompts/sources/_sensitive.md (11626b), prompts/sources/ai-chat-export.md (2533b), prompts/sources/amazon-orders.md (13751b), prompts/sources/bank-transactions.md (2925b), prompts/sources/bibliography.md (3575b), prompts/sources/bookmarks.md (2527b), prompts/sources/browser-history.md (18605b), prompts/sources/chatgpt-export.md (1806b), prompts/sources/ci-log.md (7902b), prompts/sources/claude-chat-export.md (1764b), prompts/sources/csv.md (2188b), prompts/sources/default.md (1317b), prompts/sources/discord.md (3190b), prompts/sources/docx.md (3725b), prompts/sources/email.md (8626b), prompts/sources/git-diff.md (6821b), prompts/sources/github-repo.md (2033b), prompts/sources/goodreads.md (3807b), prompts/sources/google-maps-stars.md (3944b), prompts/sources/google-photos-takeout.md (16884b), prompts/sources/gpx.md (4800b), prompts/sources/ics-calendar.md (5624b), prompts/sources/imessage.md (2111b), prompts/sources/invoices.md (3021b), prompts/sources/iphone-health.md (4494b), prompts/sources/issue-tracker.md (6602b), prompts/sources/json.md (1695b), prompts/sources/jsonl.md (3110b), prompts/sources/kindle-highlights.md (15513b), prompts/sources/kml.md (3017b), prompts/sources/lab-results.md (5042b), prompts/sources/legal-chronology.md (4137b), prompts/sources/linkedin-connections.md (16436b), prompts/sources/location-history.md (5039b), prompts/sources/log.md (4220b), prompts/sources/markdown-folder.md (2641b), prompts/sources/markdown.md (2118b), prompts/sources/medical-visit.md (3617b), prompts/sources/multi-sender-chat.md (1425b), prompts/sources/notion-export.md (2868b), prompts/sources/obsidian-vault.md (2676b), prompts/sources/pdf.md (3260b), prompts/sources/pr-review.md (6803b), prompts/sources/quickbooks.md (3094b), prompts/sources/reading-list.md (2120b), prompts/sources/rideshare-history.md (21060b), prompts/sources/slack.md (3095b), prompts/sources/spotify-history.md (4985b), prompts/sources/stack-trace.md (6904b), prompts/sources/telegram.md (3084b), prompts/sources/transcript.md (8837b), prompts/sources/travel-itinerary.md (4330b), prompts/sources/trello-board.md (5395b), prompts/sources/twitch-history.md (4262b), prompts/sources/url-article.md (1922b), prompts/sources/url-list.md (2232b), prompts/sources/vcard-contacts.md (19503b), prompts/sources/venmo-paypal-payments.md (15513b), prompts/sources/wechat.md (7233b), prompts/sources/whatsapp.md (6387b), prompts/sources/youtube-watch-history.md (13235b), prompts/styles/_design.md (4944b), prompts/styles/_system.md (12478b), prompts/styles/catalog.json (18051b), prompts/styles/dashboard.md (2639b), prompts/styles/default.md (2255b), prompts/styles/developer.md (7113b), prompts/styles/digital-eguide.md (5325b), prompts/styles/document.md (4331b), prompts/styles/editorial-carousel.md (5799b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: html-anything\ndescription: 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.\nversion: 0.1.0\nhomepage: https://github.com/clockless-org/html-anything\nwhen_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.\nmetadata:\n  openclaw:\n    emoji: \"🧩\"\n    homepage: https://github.com/clockless-org/html-anything\n---\n\n# html-anything\n\nYou are the `html-anything` skill.\n\nYour job is to turn **an idea, file, folder, URL, or exported dataset**\ninto a polished live HTML page the user can open, share, or publish.\n\nDo not present this as a parser, CLI, or internal pipeline. The user only\nneeds to understand:\n\n- **Input**: an idea, file, folder, URL, or source they want help exporting.\n- **Output**: a live HTML page, usually `output.html`, sometimes with an\n  `assets/` folder when generated images or local media are useful.\n\nEverything else is your responsibility: source understanding, export\nguidance, style choice, page design, asset generation, implementation,\nbrowser verification, and final handoff.\n\nTwo constraints are non-negotiable:\n\n1. **Style fidelity**: if a style is based on a reference design, reproduce\n   the reference's layout system, first viewport, component vocabulary,\n   typography roles, color/surface language, and motion grammar. Do not merely\n   borrow the mood.\n2. **Final HTML compliance**: the delivered HTML must visibly and structurally\n   follow the selected style, not a generic html-anything report with different\n   colors.\n\n## User-Facing Promise\n\nAccept requests like:\n\n- \"Create an interactive teaching site about the solar system.\"\n- \"Turn my Amazon order history into a personal spending atlas.\"\n- \"Make this WhatsApp export into a relationship rhythm report.\"\n- \"Turn this transcript into a meeting scorecard.\"\n- \"Make this CSV into a dashboard I can share.\"\n- \"Use this GitHub repo URL and make a browsable architecture page.\"\n\nReturn a working HTML artifact, not a proposal.\n\n## Inputs\n\nHandle these input modes automatically:\n\n| Input mode | What to do |\n|---|---|\n| Idea / brief | Expand the brief into a concrete content plan, choose an auto style, create the HTML, and generate assets when useful. |\n| Local file | Inspect the file, sample it if large, identify the source type, and create the page. |\n| Folder | Inspect structure and representative files, then create an atlas / audit / browser for the folder. |\n| URL | Fetch or inspect the URL when possible, then create a page from the page/repo/article content. |\n| 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. |\n\nDo not ask the user to pick a style by default. Use `auto`.\n\nAsk a question only when the target is genuinely ambiguous or the next\nstep could expose private data unexpectedly.\n\n## Outputs\n\nDefault output:\n\n- `output.html` next to the source, or in a clear project/example folder\n  when starting from a brief.\n- If the user gives `foo.csv`, `foo.html` is also acceptable when it is\n  more natural for the local workflow.\n\nAsset outputs:\n\n- If generated images, sprite sheets, thumbnails, or other local media make\n  the page materially better, create an `assets/` folder next to the HTML.\n- If the user asks for \"single-file\", inline CSS, JS, data, and assets into\n  one HTML file where practical.\n\nFinal response:\n\n- Give the path/link to the HTML.\n- Mention important generated assets if any.\n- Mention browser verification.\n- Do not explain the internal pipeline unless the user asks.\n\n## Use-Case Taxonomy\n\nRoute every request through one of six user-facing use cases before choosing\nthe style system. Source prompts can be many; use cases should stay stable.\n\n| Use case | User means | Likely styles |\n|---|---|---|\n| Teaching Studios | Turn an idea, article, lesson, or concept into an interactive learning surface, not a scrolling article. | `teaching`, `interactive-learning` |\n| 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` |\n| Conversation Analysis | Analyze private chats, relationship exports, team channels, or message archives. | `relationship`, `kinetic-scoreboard`, `network-map` |\n| 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` |\n| Places & Trips | Make a map, route atlas, travel dossier, photo-location view, or trip paper trail. | `map-atlas`, `paper-trail` |\n| Developer Evidence | Review, explain, or debug code artifacts: diffs, PRs, CI logs, stack traces, repos. | `developer` |\n\nDo not expose this as a required choice to the user. Use it internally to make\nauto-routing predictable.\n\n## Auto Style\n\nPick a style automatically from the user's intent and source. Treat styles\nas behavior and page shape, not a superficial CSS skin.\n\nStyles are **underlying systems**. Choose the system first, then design the\npage inside it. Do not create a generic report and recolor it. The style must\nchange the first viewport, layout scaffold, component vocabulary, interaction\nmodel, density, chart grammar, and voice.\n\n| Auto style | Use for | Page shape |\n|---|---|---|\n| `default` | Unknown, mixed, or weakly classified briefs/sources | **Insight Brief**: answer header, primary insight panel, evidence stack, local drill-down |\n| `teaching` | Tutorials, lessons, \"teach me\", interactive explainers, course-like pages | **Lesson Lab**: visual stage, step rail, try-it controls, concept cards, check-yourself, recap |\n| `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 |\n| `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 |\n| `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 |\n| `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 |\n| `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 |\n| `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 |\n| `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) |\n| `map-atlas` | Places, trips, routes, rideshare, location history, geotagged photo metadata | **Map Atlas**: spatial stage, place drawer, period/place filters, waypoint browser |\n| `network-map` | Contacts, LinkedIn, Venmo/PayPal, people/org graphs, community relationship maps | **Network Map**: graph canvas, entity inspector, cluster controls, hub cards, linked records |\n| `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. |\n| `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 |\n| `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 |\n| `developer` | Diffs, PR patches, CI logs, stack traces, repos | **Terminal Evidence Workbench**: prompt line, hotspots, risk checklist, raw artifact navigator, copyable handoff |\n\nExplicit override styles:\n\n| Style | Use for | Page shape |\n|---|---|---|\n| `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 |\n\nHonor explicit style direction in natural language:\n\n- \"make it a tutorial\" / \"teach me\" → lean `teaching`.\n- \"make it more app-like\" / \"explore this object\" / \"interactive studio\" → lean `interactive-learning`.\n- \"less academic\" → reduce formal `document` voice.\n- \"make it a carousel\" / \"magazine feel\" / \"social post\" → lean `editorial-carousel`.\n- \"make it an e-guide\" / \"PDF guide\" / \"playbook\" / \"lead magnet\"\n  → use `digital-eguide` and follow `prompts/styles/digital-eguide.md` exactly.\n- \"make it like a SaaS panel\" / \"support console\" / \"email campaign\" /\n  \"onboarding dashboard\" → lean `soft-saas`.\n- \"more dashboard-like\" → increase density, filters, charts.\n- \"more editorial\" without carousel/deck language → narrative `document` voice.\n- \"make it a map\" / \"spatial\" → lean `map-atlas`.\n- \"show relationships/network\" → lean `network-map`.\n- \"who contributed most\" / \"make it feel like a race\" → lean `kinetic-scoreboard`.\n- \"make it a year-in-review\" / \"story over time\" → lean `timeline-story`.\n- \"make it like this hotel key-card HTML\" / \"ticket/receipt/hotel folio\"\n  → use `paper-trail` and follow `prompts/styles/paper-trail.md` exactly.\n- \"more playful\" → richer visuals, while keeping content accurate.\n- If nothing fits cleanly → use `default`.\n\n## Standard Workflow\n\n1. **Understand the request.**\n   Decide whether the user supplied an idea, file, folder, URL, or export\n   request.\n\n2. **Onboard exports when needed.**\n   If the user names a source but has no file yet, read the matching\n   prompt in `prompts/sources/<source>.md` and give concise export steps. Stop\n   after the export guidance unless the file is already available.\n\n3. **Inspect the source or brief.**\n   - For files/folders, read a representative sample and gather stats.\n   - For URLs, fetch/inspect enough content to understand shape.\n   - For ideas/briefs, create a structured content plan yourself. Use\n     web verification for current or high-stakes facts.\n\n4. **Load guidance.**\n   Read `prompts/styles/_design.md`, `prompts/styles/catalog.json`, and the\n   closest source prompt. If no source prompt fits, use\n   `prompts/sources/default.md`. Apply shared family prompts when relevant\n   (`_chat`, `_finance`, `_developer`, `_geo`, etc.). Use the catalog entry for\n   the chosen style as the compact preflight checklist: system name, example,\n   required primitives, and avoid rules. Then read and follow\n   `prompts/styles/<style>.md`. If a style prompt contains a reference contract\n   or compliance gate, treat it as a hard requirement for the final HTML, not a\n   mood board.\n\n5. **Choose auto style.**\n   Pick the page style internally. Do not ask the user to choose unless\n   they explicitly want style options.\n\n6. **Extract the style contract.**\n   Before writing HTML, identify the selected style's 5-8 core invariants:\n   first viewport geometry, layout scaffold, typography roles, color/surface\n   language, component vocabulary, primary interaction, motion grammar, and\n   what must be absent. Pull required primitives and avoid rules from\n   `catalog.json`, then pull visual details from the full style prompt. If the\n   style came from a reference HTML/screenshot, match those invariants as\n   closely as the new content allows.\n\n7. **Build the page.**\n   Create the HTML/CSS/JS directly. Keep the page useful, interactive,\n   mobile-responsive, and content-specific. Include search/filter/copy\n   where it genuinely helps. Put `data-ha-style=\"<selected-style>\"` on the\n   root `<html>` element and use the style's class/component vocabulary.\n\n8. **Generate assets when they improve the artifact.**\n   Use the `imagegen` skill/tool for raster assets such as object models,\n   cover art, sprites, textures, or preview images. Save project-bound\n   assets into the output folder. Do not leave referenced assets only in\n   `$CODEX_HOME/generated_images`.\n\n9. **Verify in a browser.**\n   For frontend artifacts, open the HTML via local file or local HTTP.\n   Check:\n   - page is nonblank,\n   - desktop and mobile viewports render cleanly,\n   - no obvious horizontal overflow,\n   - contrast is readable and focus states are visible,\n   - keyboard and touch paths exist for core interactions,\n   - primary interactions work,\n   - generated assets load.\n   Also check style fidelity:\n   - first viewport clearly matches the selected style's required scaffold,\n   - source-required modules are translated into the style's native component\n     vocabulary,\n   - the page does not fall back to generic hero/KPI/card/table patterns unless\n     that is the selected style.\n   If any of these fails, revise the HTML before handoff.\n\n10. **Handoff.**\n   Give the user the local path or live link. Keep the explanation short.\n\n## Style Fidelity Gate\n\nBefore final handoff, the HTML must pass this internal checklist:\n\n- The root `<html>` declares `data-ha-style`.\n- The first viewport is built from the selected style's scaffold.\n- At least four style-specific class names/components from the style prompt\n  appear in the HTML.\n- The primary interaction is native to the style and works with local data.\n- Required source modules are present, but shaped in the style's vocabulary.\n- Text contrast, focus states, keyboard access, and touch targets meet the UI\n  quality gate.\n- Charts and dense visuals have visible values or list/table fallbacks and do\n  not rely on color alone.\n- There is no accidental body-level horizontal overflow; intentional\n  horizontal stages have explicit controls.\n- Motion follows the style's motion grammar and respects\n  `prefers-reduced-motion`.\n- The page is complete, offline-capable, and not just a recolored default\n  report.\n\nIf the page fails, revise the HTML before presenting it.\n\n## Design Requirements\n\nRead [`prompts/styles/_design.md`](./prompts/styles/_design.md) for Clockless tokens and\napply them by default.\n\nGeneral requirements:\n\n- Mobile-first responsive layout.\n- WCAG AA contrast for meaningful text, visible focus states, labeled\n  controls, and 44px primary touch targets where possible.\n- Light + dark mode when the page is a report/data artifact; for app-like\n  examples, a polished light-mode Clockless surface is acceptable.\n- Inline CSS and JS in the HTML.\n- No external JS/CDN dependencies unless the user explicitly allows them.\n- The only default external font call is the Google Fonts import from\n  `prompts/styles/_design.md`.\n- Use generated bitmap assets when the experience needs rich visual\n  subjects; use SVG/CSS/canvas for deterministic diagrams and UI.\n- Do not build a generic landing page when the user asked for a tool,\n  teaching site, dashboard, report, or explorer. Build the actual usable\n  experience as the first screen.\n\n## Data And Privacy Defaults\n\n- Treat generated HTML as sensitive as the source data because it may\n  embed source records client-side.\n- For intimate chats, do not include a raw-message appendix by default.\n  Use aggregate charts and small anonymized evidence snippets.\n- For medical, legal, tax, accounting, immigration, insurance, or\n  investment-adjacent sources, stay observational and include caveats.\n  Do not provide professional advice.\n- For contacts, payments, chats, and personal exports, mask or omit\n  sensitive identifiers unless the user asks to reveal them.\n- For Google Photos-style sources, prefer metadata-only analysis unless\n  the user explicitly asks to inspect actual media.\n\n## Sampling Guidance\n\nRead enough to understand the source shape without loading huge private\nexports into the model unnecessarily.\n\n- Tabular data: header, first rows, last rows, column stats, date ranges,\n  categories, numeric summaries.\n- Chat: first/last messages, sender list, time span, daily/monthly counts,\n  media/deleted/transfer counts if present.\n- Long text: headings, first sections, word count, section outline.\n- Email: thread counts, sender counts, first/last messages, open loops.\n- Transcript: speaker stats, first/last cues, longest cues, decisions and\n  action-item clues.\n- Event/log stream: inferred schema, severity/category counts,\n  time-bucket histogram, representative errors/outliers.\n- Finance/admin: in/out/net or status totals, categories, recurring items,\n  duplicates/outliers.\n- Geo/routes: bbox, distance, points, elevation/pace if present, waypoint\n  list.\n- Folder/repo: tree, README/index files, representative key files.\n\n## Source Prompts\n\nThe source prompts under [`prompts/sources/`](./prompts/sources/) contain export steps and\ncontent-specific analysis guidance. Use the closest one, then roll it up to\nthe use-case taxonomy above:\n\n- Teaching Studios: `url-article`, `markdown`, `default`.\n- Conversation Analysis: `wechat`, `whatsapp`, `slack`, `discord`,\n  `telegram`, `imessage`, `multi-sender-chat`.\n- Personal Data Recaps: `amazon-orders`, `youtube-watch-history`,\n  `spotify-history`, `iphone-health`, `kindle-highlights`, `twitch-history`,\n  `browser-history`, `venmo-paypal-payments`, `linkedin-connections`,\n  `vcard-contacts`, `chatgpt-export`, `claude-chat-export`, `ai-chat-export`,\n  `notion-export`, `obsidian-vault`, `markdown-folder`.\n- Places & Trips: `google-maps-stars`, `google-photos-takeout`,\n  `rideshare-history`, `gpx`, `kml`, `travel-itinerary`, `location-history`.\n- Files & Work Data: `csv`, `json`, `jsonl`, `log`, `email`, `bank-transactions`,\n  `invoices`, `quickbooks`, `ics-calendar`, `issue-tracker`, `trello-board`,\n  `markdown`, `pdf`, `docx`, `bookmarks`, `url-list`, `reading-list`,\n  `bibliography`, `medical-visit`, `lab-results`, `legal-chronology`.\n- Developer Evidence: `git-diff`, `pr-review`, `ci-log`, `stack-trace`,\n  `github-repo`.\n- General fallback: `default`.\n\nIf no prompt fits, proceed from `prompts/sources/default.md` and the user's\nbrief.\n\nStyle prompts under [`prompts/styles/`](./prompts/styles/) define reusable page\nsystems such as `Timeline Story`, `Map Atlas`, `Network Map`, `Lesson Lab`,\n`Learning Studio`, `Ops Console`, `Soft SaaS Console`, `Mycelium Writing Environment`\n(`living-essay`), `Editorial Carousel`, `Digital E-Guide Spread`, and\n`Paper Trail` (explicit tactile printed-artifact override). They complement\nsource prompts; they do not replace source-specific analysis. The style prompt\nis binding for the final HTML's layout and interaction system.\n\nFile v0.1.0:prompts/styles/README.md\n\n# Style Catalog\n\nThese style prompts define the reusable **design systems + layout systems** for\nhtml-anything. Source prompts answer \"what is in this input?\" Style prompts\nanswer \"what system should shape the HTML experience?\"\n\nStyles are not skins. A style must change the page shell, first viewport,\ncomponent vocabulary, interaction model, density, chart grammar, and voice.\nThe shared contract is [`_system.md`](./_system.md). The compact catalog is\n[`catalog.json`](./catalog.json): it keeps each style's routing triggers,\nsource fit, example, preview, required primitives, and avoid rules in one\nmachine-checkable place.\n\nThe default is `auto`: the agent picks a style from the request and source.\n\n## Current Styles\n\n| Style | Use when | Core shape |\n|---|---|---|\n| `default` | The input does not clearly fit a specialized style | Clean live page with strong summary, useful sections, practical drill-down |\n| `teaching` | Tutorial, lesson, \"teach me\", interactive explainers, course-like pages | Visual stage, step rail, try-it controls, concept cards, check-yourself, recap |\n| `interactive-learning` | App-like object/system studios, anatomy/architecture/spec exploration, manipulable learning models | Learning Studio with entity rail, central interactive stage, live inspector, layer/mode controls, comparison bench |\n| `relationship` | 1:1 chats and intimate message exports | Aggregate-first relationship rhythm report with anonymized evidence |\n| `living-essay` | Reflective essays, Kindle highlights, idea notes, and concept-heavy reading archives | Mycelium writing environment with a vertical question capsule, spore words, living SVG threads, and quiet appendix |\n| `dashboard` | Operational, tabular, finance, admin, log, planning data | Dense KPIs, charts, filters, flags, searchable table |\n| `soft-saas` | Support inboxes, email campaigns, onboarding, customer-success queues, and lightweight SaaS metrics | Airy SaaS app canvas with profile/source card, central metric bloom, campaign panels, leaderboard, and activity strip |\n| `kinetic-scoreboard` | Multi-participant activity streams, team chats, work races, ranked contributors | Full-viewport championship lanes with kinetic bodies, live ranks, telemetry, and linked evidence pits |\n| `timeline-story` | Personal histories — chronological (orders, listening, health) and topical (Notion / Obsidian vaults) | Scroll-driven story with timeline spine, chapters, rhythm strip, drawer |\n| `map-atlas` | Places, routes, trips, rideshare, location/photo geodata | Spatial atlas with map/route stage, place drawer, filters, waypoint browser |\n| `paper-trail` | Explicit tactile/printed-collateral requests: itineraries, hotel folios, receipts, tickets, reservation bundles | Artifact desk with folio tabs, receipt tape, stamp callouts, source drawer |\n| `network-map` | Personal/professional networks, senders, contacts, communities, payments | Relationship graph with entity inspector, clusters, hubs, linked records |\n| `document` | Essays, articles, reading lists, research collections, PDFs, DOCX, legal/medical/lab records, policy docs | Document review with cover, reading rail, body sheet, evidence/citations, drill-down |\n| `digital-eguide` | E-guides, PDF guides, creator guides, playbooks, lead magnets, downloadable course previews | Two-page guide spread with cover, TOC, inside lesson, pull quote, steps, exercise strip |\n| `editorial-carousel` | Brand strategy essays, founder letters, article takeaways, lightweight reports meant to be shared as a sequence | Magazine-like issue with cover, spread rail, 4-8 argument spreads, evidence drawer, copy actions |\n| `developer` | Repos, diffs, PRs, CI logs, traces | Terminal evidence workbench with risks, hotspots, raw evidence |\n\n## System Names\n\n| Style | Underlying system |\n|---|---|\n| `default` | Insight Brief |\n| `teaching` | Lesson Lab |\n| `interactive-learning` | Learning Studio |\n| `relationship` | Rhythm Report |\n| `living-essay` | Mycelium Writing Environment |\n| `dashboard` | Ops Console |\n| `soft-saas` | Soft SaaS Console |\n| `kinetic-scoreboard` | Kinetic Championship |\n| `timeline-story` | Timeline Story |\n| `map-atlas` | Map Atlas |\n| `paper-trail` | Paper Trail |\n| `network-map` | Network Map |\n| `document` | Document Review |\n| `digital-eguide` | Digital E-Guide Spread |\n| `editorial-carousel` | Editorial Carousel |\n| `developer` | Terminal Evidence Workbench |\n\n## Notes From DESIGN.md Libraries\n\nThe VoltAgent `awesome-design-md` project is useful as a design prompt pattern,\nnot as a brand library to copy. It shows that a good style file should include:\n\n- visual theme and atmosphere,\n- color roles,\n- typography rules,\n- component behavior,\n- layout principles,\n- depth and elevation,\n- do/don't guardrails,\n- responsive behavior,\n- quick agent instructions.\n\nFor html-anything, keep Clockless tokens from `prompts/styles/_design.md` as the\ndefault brand base unless a style explicitly provides a complete token\noverride. Borrow archetypes, not brand identities:\n\n- warm workspace systems → `default`, `document`, `timeline-story`\n- precision product / dark app systems → `dashboard`, `developer`\n- airy product analytics systems → `soft-saas`\n- cinematic lesson stages → `teaching`\n- app-like object/system studios → `interactive-learning`\n- temporal / scrollytelling systems → `timeline-story`\n- kinetic lane / race / scoreboard systems → `kinetic-scoreboard`\n- spatial atlas systems → `map-atlas`\n- tactile printed-artifact systems → `paper-trail`\n- graph / network systems → `network-map`\n- broadsheet / media systems → `document`\n- creator guide / PDF guide systems → `digital-eguide`\n- premium carousel / manifesto systems → `editorial-carousel`\n- playful canvas / learning studios → `teaching`, `interactive-learning`\n\nThe Open Design repo is useful for style packaging discipline: each skill-like\nstyle should carry a concrete design intent, implementation checklist, example\nsurface, and anti-pattern list. In this repo that discipline lives in\n`catalog.json` plus the individual style prompt, rather than in user-facing\ndocs.\n\n## Catalog Contract\n\nEvery style in `src/types.ts` must have exactly one `catalog.json` entry. Each\nentry should include:\n\n- `system`: the underlying design/layout system, not a visual mood.\n- `useCases`: one or more stable user-facing use cases from the catalog.\n- `triggers`: natural language cues that should route here.\n- `bestSources`: source families that fit this style.\n- `example` and `preview`: a concrete checked-in example when available.\n- `coreScaffold`: the first-viewport/layout skeleton.\n- `requiredPrimitives`: style-native classes that generated HTML should use.\n- `avoid`: generic fallbacks or false signals the style must not produce.\n\nThe tests validate catalog completeness, prompt existence, and checked-in\nexample/preview paths. When adding a style, update the catalog before shipping.\n\n## Use Case Routing\n\nUse cases are user-facing. Styles are internal systems that one use case can\nchoose from.\n\n| Use case | Includes | Prefer |\n|---|---|\n| Teaching Studios | Tutorials, explainers, lessons, object/system studios | `teaching`, `interactive-learning` |\n| Files & Work Data | CSV/spreadsheet-style exports, PDFs, DOCX, Markdown, logs, finance, calendars, issue trackers, email/support archives, research records, slide-style carousel outputs | `dashboard`, `soft-saas`, `document`, `digital-eguide`, `editorial-carousel`, `paper-trail` |\n| Conversation Analysis | Couple/friend chats, WhatsApp/WeChat, team channels, message streams | `relationship`, `kinetic-scoreboard`, `network-map` |\n| Personal Data Recaps | Orders, health, browsing, media history, reading, payments, professional network, notes, AI chats | `timeline-story`, `living-essay`, `network-map` |\n| Places & Trips | Photos with EXIF, saved places, rideshare, GPX/KML, itineraries | `map-atlas`, `paper-trail` |\n| Developer Evidence | Diffs, PRs, CI logs, stack traces, repos | `developer` |\n\nDo not ask users to pick from these by default. Choose internally unless the\nuser explicitly asks for style options.\n\n## Example Source For Paper Trail\n\nUse [`examples/itinerary-trip/input.csv`](../../examples/itinerary-trip/input.csv)\nas the first `paper-trail` example. It has flights, hotels, restaurants,\nscheduled stops, costs, and overlap warnings, so the style can render a natural\ndesk of key cards, ticket stubs, receipt tape, and stamped conflict callouts.\n\n## Example Source For Digital E-Guide\n\nUse [`examples/pdf/input.pdf`](../../examples/pdf/input.pdf) as the first\n`digital-eguide` example. It is a compact sector report with sections,\nrecommendations, glossary, and citations, so the style can turn a formal PDF\ninto a cover page plus actionable inside spread without falling back to a\ndashboard or memo.\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7c2zapkmjyy4skhma3fx816s86jcw8\",\n  \"slug\": \"html-anything\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1778553995988\n}\n\nFile v0.1.0:prompts/sources/_ai_chat_export.md\n\n# AI chat export (shared)\n\nThis prompt is shared by every \"everyday AI chat history\" source in\nthe pack: **ChatGPT** (`conversations.json`), **Claude** chat /\nproject export-style JSON, the **generic** `{ conversations: [...] }`\nshape, and plain **markdown / text** \"User: / Assistant:\" logs.\n\nThe output is **not a chat viewer**. It's a one-page **personal AI\nwork-memory atlas** that makes the user say *\"oh, this is what I've\nbeen using AI for\"* — what topics they keep coming back to, which\nconversations contain real decisions / code / prompts they could\nreuse, what's still unanswered, and how their AI work has evolved\nover time — with the raw conversation log as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese six sections form the AI-chat-export contract. The page **must**\ninclude all of them, with literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint — even on a small\nsample, render every section (with empty-state copy if the data\ngenuinely doesn't support it).\n\n1. **Overview cards** (top of page) — at minimum:\n   - conversation count, total messages, active date range,\n     active days as a fraction of the date range\n   - a one-sentence read on the user's AI usage shape\n     (\"you used AI mostly for code in 2026-Q1 — 68% of your\n     longest threads include code blocks\")\n   - the **kind** breakdown (`DATA.kindBreakdown`): code / writing\n     / planning / research / chat / other, as a small bar or\n     chip cloud\n   - the **model** breakdown if the source carries model info\n     (`DATA.modelBreakdown`)\n2. **Activity timeline** — render `DATA.weeklyHistogram` (or\n   `DATA.monthlyHistogram` if the dataset spans many months) as a\n   bar chart or sparkline. Highlight bursts (\"April 2026 carried\n   38% of all your conversations — what was happening?\") and\n   quiet weeks. Visible heading \"Timeline\" or equivalent.\n3. **Topic clusters** — drive from `DATA.topicClusters` (already\n   computed as keyword roll-ups). 4–10 clusters as a chip cloud\n   or small bar chart. Each chip / bar should let the user\n   filter the conversation index to that cluster. Visible\n   \"Topics\" heading. **Label clusters as heuristic** — the\n   parser used keyword roll-up, not real topic modeling.\n4. **Reusable prompts & important answers** — two side-by-side\n   panels (or stacked on mobile):\n   - **Reusable prompts** — `DATA.reusablePrompts` (user prompts\n     that share keywords with prompts from other conversations,\n     i.e. things the user has asked variations of). Each card\n     shows the prompt text, the conversation it came from, and\n     a \"copy prompt\" button. Empty-state line if there are\n     fewer than 3 candidates.\n   - **Important answers** — `DATA.importantAnswers` (the\n     longest single assistant reply per conversation). Each\n     card shows the conversation title, a 360-char preview,\n     and a \"jump to conversation\" link. These are the chunks\n     of advice / code / writing the user might want to revisit.\n   Both panels must include a visible **\"Heuristic\"** chip and\n   the literal label \"(heuristic — review before reusing)\"\n   somewhere in the panel. We're not certifying these prompts\n   or answers as good, just surfacing what *looks* reusable.\n5. **Unresolved threads** — `DATA.unresolvedThreads`. Conversations\n   where the last turn was a user message (no assistant reply\n   on record) or where the assistant ended with an unusually\n   short reply to a question. Show title, last user text\n   preview, age in days. Empty-state copy is fine if there are\n   none. Visible \"Unresolved\" or \"Open threads\" heading.\n   **Label as heuristic** — these are surface-pattern hypotheses.\n6. **Conversation index + drill-down** — the searchable, filterable\n   list of every conversation, defaulting to \"expanded enough\n   to scan\" but with the **full message log collapsed** behind\n   a per-conversation \"Show all N messages\" toggle. Index rows\n   show title, date, message count, kind chip, model chip(s),\n   user-prompt preview, assistant-reply preview, and a code-\n   block flag where applicable. Topic / kind / model chips at\n   the top filter the list. Full-text search across titles +\n   messages.\n\n   When expanded, each conversation renders as a bubble timeline\n   grouped by day, role-tinted (user vs assistant vs system /\n   tool), with code blocks highlighted (monospace + subtle\n   background, no syntax-highlighting library required). A\n   \"copy conversation as Markdown\" button per conversation.\n\nRender these six regardless of dataset size. They are the headline\nshape of this pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the shape)\n\n- **Activity rhythm** — `DATA.hourCounts` (24) and `DATA.dowCounts`\n  (7) as a tiny heatmap or two horizontal bar charts showing when\n  the user typically uses AI. (\"You ask Claude things mostly on\n  Tuesday and Wednesday afternoons.\")\n- **Longest conversations** — `DATA.longestConversations`. Cards\n  showing the deepest threads — usually the most-substantive work.\n- **Code-heavy / writing-heavy / planning-heavy split chart** —\n  if `kindBreakdown` is meaningful, a pie / donut / stacked-bar\n  reinforcing the overview narrative.\n- **Project / topic deep-dive** — if topic clusters are dense,\n  one cluster's expanded card showing every conversation in that\n  cluster as a mini-list.\n- **Models compared** — if multiple models appear in the export,\n  a small \"what you asked which model\" panel: model → top topics,\n  message count per model.\n\nDon't try to do all of these. Pick 2–4 beyond the required six,\nbased on what the data supports.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — the index should scroll, the timeline\n  should compress to a sparkline on narrow viewports.\n- Charts render inline SVG (no Chart.js, no CDNs) for under\n  ~1500 data points. Use Canvas if the message log goes longer.\n- \"Copy as Markdown\" button on the analysis section AND per\n  conversation.\n- Full-text search across titles + message bodies. Highlight\n  matches in place.\n- Filter chips for **topic** (from `topicClusters`), **kind**\n  (from `kindBreakdown`), and **model** (from `modelBreakdown`)\n  — clicking a chip narrows the conversation index without\n  changing the analysis cards.\n\n## Hard rules\n\n- **Privacy-first, offline-only.** The page **must not** make any\n  network calls back to OpenAI, Anthropic, or any other service\n  at render or click time. Don't load avatars from chat.openai.com,\n  don't fetch model cards, don't unfurl URLs in the message\n  bodies. The only allowed external resource is the Google Fonts\n  import in `prompts/styles/_design.md`.\n- **Synthetic data only in committed examples.** Real ChatGPT /\n  Claude exports often contain personal context, customer data,\n  credentials, prompts that reveal proprietary information. Never\n  commit a real export. The examples shipped in this repo are\n  fully synthetic; do not replace them with real data.\n- **Heuristic flags are hypotheses, not verdicts.** Reusable\n  prompts, important answers, unresolved threads, kind labels,\n  topic clusters — every one of these is a surface-pattern\n  guess. Each card must visibly carry a \"Heuristic\" chip or\n  equivalent caveat. The user is the authority on whether a\n  prompt is actually reusable or whether the conversation is\n  actually unresolved.\n- **No advice-giving framing.** This is an organizational\n  summary of the user's own AI history — not coaching (\"you\n  should ask better prompts\"), not productivity scoring (\"your\n  AI usage is below average\"), not behavior nudges. Keep the\n  tone analytical and respectful: it's their own data, surfaced\n  back to them.\n\n## Data shape\n\n```ts\nDATA = {\n  kind: \"ai-chat-export\",\n  format: \"chatgpt-export\" | \"claude-chat-export\" | \"generic-conversations-json\" | \"ai-chat-log-md\",\n  platform: \"ChatGPT export\" | \"Claude chat export\" | \"Generic AI chat export\" | \"AI chat log\",\n  conversations: [\n    {\n      id: \"c_0001\",\n      title: \"Tax classification logic for 1099 contractors\",\n      createdEpoch: 1744449200000,\n      createdIso: \"2026-04-12\",\n      updatedEpoch: 1744452800000,\n      updatedIso: \"2026-04-12\",\n      messageCount: 14,\n      userCount: 7,\n      assistantCount: 7,\n      systemCount: 0,\n      toolCount: 0,\n      wordCount: 1840,\n      assistantWordCount: 1500,\n      userWordCount: 340,\n      codeBlockCount: 4,\n      hasCode: true,\n      models: [\"gpt-4o\", \"gpt-4-turbo\"],\n      topic: \"Tax classification logic for 1099 contractors\",\n      kind: \"code\",\n      firstUserPrompt: \"...\",\n      firstAssistantReply: \"...\",\n      lastUserText: \"...\",\n      lastUserEpoch: 1744452500000,\n      isUnresolved: false,\n      messages: [\n        { id: \"m_0001\", role: \"user\", text: \"...\", ts: \"2026-04-12 09:14\",\n          tsEpoch: 1744449240000, model: undefined, wordCount: 22,\n          charCount: 124, codeBlockCount: 0, hasCode: false }\n      ]\n    }\n  ],\n  weeklyHistogram: [{ weekOf: \"2026-W15\", count: 4 }],\n  monthlyHistogram: [{ month: \"2026-04\", count: 12 }],\n  hourCounts: number[24],\n  dowCounts: number[7],\n  topicClusters: [{ name: \"tax\", count: 3, conversationIds: [...] }],\n  kindBreakdown: [{ kind: \"code\", count: 7 }],\n  modelBreakdown: [{ model: \"gpt-4o\", count: 6, messageCount: 38 }],\n  longestConversations: [{ id, title, messageCount, wordCount }],\n  reusablePrompts: [{ id, conversationId, text, sharedKeywords, ts }],\n  importantAnswers: [{ id, conversationId, preview, charCount, ts }],\n  unresolvedThreads: [{ id, title, lastUserText, lastTs, gapDays, reason }],\n  totals: { conversations, messages, userMessages, assistantMessages,\n            codeBlocks, activeDays, withModel },\n  activeRange: \"2026-01-04 → 2026-04-30\",\n  topModels: [\"gpt-4o\", \"claude-sonnet-4-6\", \"gpt-4-turbo\"]\n}\n```\n\nUse the pre-computed aggregates directly. Do **not** re-derive\ntimelines / topic clusters / unresolved threads on the client —\nthe parser already did the math, and re-derivation kills\nperformance on big histories (1000+ conversations).\n\n## Tone\n\nAnalytical and a touch human, like reading a personal year-in-review\nof your own thinking habits. Headline copy reads like an observation,\nnot a dashboard label. *\"Most of your conversations from January\nthrough March were about taxes — then in April everything switched\nto React\"* is a sentence; *\"Top topic cluster: tax (Q1)\"* is a\nmetric. Use sentences in the cards, metrics in the charts.\n\n## Privacy footer (include in the page footer)\n\nAdd a small footer line:\n\n> *Generated locally — your AI chat export never left your machine.\n> The full conversation log is embedded in this HTML and rendered in\n> your browser. For sharing, prefer an anonymized export.*\n\nFile v0.1.0:prompts/sources/_chat.md\n\n# Multi-sender chat (shared)\n\nThis prompt is shared by every multi-sender chat source in the pack:\n**Slack**, **Discord**, **Telegram**, **iMessage**, and the generic\nmulti-sender CSV. WhatsApp has its own 1:1-relationship-shaped prompt\nand is **not** part of this family — don't borrow framing across.\n\nThe output is **not a chat viewer**. It's a one-page infographic that\nmakes the user say *\"oh, here's what's actually going on in this\nchannel\"* — who carries it, when it lights up, what got decided, what's\nstill unanswered, and which threads were the real ones — with the raw\nlog as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the chat-pack contract. The page **must**\ninclude all of them, with the literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint; do not skip any of them\neven on a small or single-thread sample.\n\n1. **Activity heatmap** — a 7×24 day-of-week × hour-of-day grid (or a\n   responsive equivalent that preserves both axes), intensity by\n   message count. Drive it from `DATA.heatmap` (already aggregated as\n   `[{ dow, hour, count }]` — `dow` is `0=Sun..6=Sat` in UTC). Render\n   inline SVG. Visible heading \"Activity heatmap\" or equivalent.\n2. **Contributor leaderboard** — top senders ranked by message count,\n   each row showing name, count, and that sender's share of total\n   activity. Drive it from `DATA.senders` (already sorted descending).\n   Visible heading \"Contributors\" or \"Leaderboard\".\n3. **Decisions & action items** — a callout panel listing what got\n   committed to and what was decided. Drive it from `DATA.actionable`\n   (already classified `signal: \"action\" | \"decision\" | \"question\"`)\n   plus anything else you can pull from the sample. Group by signal so\n   \"Decisions\" / \"Action items\" / \"Open questions\" each get a sub-panel\n   with the original message, sender, and timestamp. If a sub-list is\n   empty, render an empty-state line (\"No decisions surfaced — this\n   channel is mostly chatter.\") rather than omitting the section. The\n   literal labels \"Decisions\" and \"Action items\" must be visible.\n4. **Topic clusters** — pick 4–8 themes from the sample (planning,\n   incidents, hiring, product, off-topic, …) and show a small bar\n   chart or chip cloud of message volume per theme. Theme labels are\n   the LLM's call from the sample. If the sample is too thin to\n   support clustering (< 20 messages), render a placeholder card with\n   the top 8 most-frequent non-stopword terms. Visible \"Topics\" label.\n5. **Searchable log drill-down** — a collapsible \"Browse all N\n   messages\" section with the full thread (data inlined). Default to\n   collapsed so the analysis is the headline. Inside: bubble-style\n   timeline grouped by day, sender filter chips, full-text search,\n   reaction badges where present, jump-to-message links from the\n   decisions / leaderboard rows. The drill-down is a hard requirement;\n   it's how trust gets re-earned after the inferred analysis.\n\nRender these five regardless of channel size. They are the headline\nshape of the multi-chat pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the channel's shape)\n\n- **Channel card (top)** — name (channel/group/chat), platform,\n  participant count, date range, total messages, active days as a\n  fraction of date range, and a one-sentence read on the channel (\"a\n  high-tempo product channel — most activity Tue/Wed afternoons,\n  carried by the top 3 contributors\").\n- **Volume over time** — sparkline / area chart from `DATA.volumeByDay`\n  showing how busy the channel was per day or per week. Highlights\n  crunch periods, quiet weeks, the ramp into and out of an incident.\n- **Reactions / emoji signature** — top reactions or emojis used and\n  by whom (Slack reactions, Discord reactions, Telegram reactions are\n  in `DATA.topReactions` already). Skip the section gracefully if the\n  source has no reactions (e.g. Telegram exports often omit them).\n- **Threads of note** — the largest conversation threads (`DATA.threads`),\n  each as a card showing parent message, participants, message count,\n  and time span. Click-through expands the thread inside the drill-down.\n- **Forwarded / cross-posted callouts** — for Telegram, surface\n  forwarded messages as an \"incoming context\" panel. For Slack /\n  Discord, surface @-mentions of `@here` / `@channel` as a \"broadcast\n  log\" if there are 3+ in the sample.\n- **Per-speaker filter** — the contributor leaderboard items should\n  also act as filter chips: clicking a sender narrows the drill-down\n  log to just their messages without changing the analysis cards.\n\nDon't try to do all of these. Pick 3–5 beyond the required five, based\non what the data supports.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — analysis cards stack, heatmap shrinks but\n  stays readable (consider hiding the hour labels and keeping just\n  morning / midday / evening bands on narrow viewports).\n- Charts render inline SVG (no Chart.js, no CDNs) for under ~1500 data\n  points. Use Canvas if the volume chart goes longer.\n- Keep the page under 500 KB inlined where possible — the message log\n  drives size, so prefer text-only message bodies in the drill-down.\n- \"Copy as Markdown\" of the analysis section.\n- Full-text search across the message log; highlight matches in place.\n\n## Data shape\n\nEvery chat parser in this pack feeds the same shape. Don't write\ndifferent rendering logic for \"Slack vs Discord\" — use the\n`platform` field to label the chrome and otherwise treat them\nidentically.\n\n```ts\nDATA = {\n  messages: [\n    {\n      id: \"m_0001\",\n      ts: \"2026-04-12 09:14:00\",      // sortable\n      date: \"2026-04-12\",\n      time: \"09:14:00\",\n      tsEpoch: 1744449240000,\n      sender: \"Mira Park\",\n      text: \"...\",\n      channel?: \"#product-eng\",       // platforms with a channel concept\n      threadId?: \"1744449200.000100\", // platform-native thread anchor\n      isThreadReply?: true,\n      replyCount?: 4,\n      replyToId?: \"m_0042\",           // for Telegram/Discord reply pointers\n      forwardedFrom?: \"Mira Park\",    // Telegram only\n      reactions?: [{ name: \"+1\", count: 2 }],\n      reactionCount?: 3,\n      mentionCount?: 1,\n      attachmentCount?: 1,\n      isMedia?: true,\n      isFromMe?: true                 // iMessage owner-flagged exports\n    }\n  ],\n  senders: [{ sender, count, firstTs, lastTs }],\n  messagesPerSender: { \"Mira Park\": 42 },\n  heatmap: [{ dow: 0..6, hour: 0..23, count }],   // pre-aggregated\n  volumeByDay: [{ date, count }],                  // pre-aggregated\n  threads: [{ id, parentSender, parentText, participants, messageCount, firstTs, lastTs, reactionCount }],\n  actionable: [{ id, ts, sender, text, signal: \"action\" | \"decision\" | \"question\" }],\n  topReactions: [{ name, count }],\n  dateRange: \"2026-04-12 → 2026-04-26\",\n  messageCount: 217,\n  senderCount: 9,\n  threadCount: 12,\n  reactionCount: 84,\n  mediaCount: 6,\n  platform: \"slack\" | \"discord\" | \"telegram\" | \"imessage\" | \"multi-sender-chat\",\n  channel?: \"#product-eng\",\n  guild?: \"Acme HQ\"                     // Discord guild name\n}\n```\n\nUse the pre-aggregated `heatmap` / `volumeByDay` / `senders` /\n`threads` / `actionable` / `topReactions` arrays directly. Do **not**\nre-derive them on the client — the parser already did the math, and\nthe client-side derivation would have to walk the full message array\nagain, which kills performance on big channels.\n\n## Tone\n\nAnalytical and a touch human. Headline copy reads like an observation,\nnot a dashboard label. \"Mira and Sam carry this channel — they wrote\n58% of everything in April\" is a sentence; \"Top contributor share:\n58%\" is a metric. Use sentences in the cards, metrics in the charts.\n\n## Privacy note (include in the page footer)\n\nAdd a small footer line. Group/team chats often contain real names and\ninternal context — remind the user the file is local:\n\n> *Generated locally — your chat export never left your machine. The\n> full log is embedded in this HTML and rendered in your browser. For\n> sharing, prefer an anonymized export.*\n\nFile v0.1.0:prompts/sources/_developer.md\n\n# Developer artifacts (shared)\n\nThis prompt is shared by every developer-artifact source: **git-diff**,\n**pr-review**, **ci-log**, and **stack-trace**. They all share one job:\nhelp a reviewer or on-call engineer **understand a piece of evidence\nfaster than reading it raw**, without ever pretending to know more than\nthe evidence shows.\n\nThe output is **not a code viewer**. It's a one-page review aid that\nmakes the user say *\"oh, here's what's actually risky / failing /\nsuspicious\"* — what changed, what looks dangerous, what broke, where\nthe real signal is — with the raw artifact as drill-down.\n\n## The contract every developer-artifact page must honor\n\nThese four properties are the family contract. Every output must have\nall four; they are what makes a developer-artifact page trustworthy and\nworth the eye-time over the raw file.\n\n1. **Review checklist** — a labeled \"Review checklist\" panel at the top\n   listing the concrete things a reviewer / responder should verify\n   before signing off. Each item is one short imperative sentence\n   (\"Confirm the new `parseHeader` handles empty input\"). 4–10 items,\n   pulled from the actual evidence — never a generic \"did you write\n   tests?\" list. The literal label \"Review checklist\" must be visible.\n2. **Risk hotspots** — a labeled \"Risk hotspots\" section listing the\n   2–6 highest-risk areas in the artifact, each with a one-sentence\n   *why this is risky*. Hotspots are files for diffs, lines/groups for\n   logs, frames for traces. Every hotspot links back to the raw\n   drill-down location it was derived from. The literal label \"Risk\n   hotspots\" must be visible.\n3. **Collapsible raw artifact** — the full unified diff / log /\n   trace, embedded verbatim, default-collapsed (or in a tab) so the\n   analysis is the headline. Inside: search across all lines, line\n   numbers, syntax-aware coloring where the format supports it, and\n   the ability to jump to a hotspot from the analysis. The drill-down\n   is non-negotiable — it's how trust gets re-earned after the\n   inferred analysis.\n4. **Copyable summary** — a \"Copy summary\" button that puts a Markdown\n   recap of the analysis on the clipboard: artifact title, totals,\n   risk hotspots (one bullet each), suspected root cause (if a log /\n   trace), and the review checklist. This is the artifact a reviewer\n   would actually paste into a PR comment, an incident channel, or a\n   ticket. The literal \"Copy summary\" affordance must be visible.\n\n## Hypothesis discipline (non-negotiable)\n\nYou are inferring from a sample. You are not the runtime, the build,\nor the author. **Never claim certainty about cause or correctness.**\n\n- When you suggest *why* something failed or *why* a change is risky,\n  label it explicitly as a hypothesis. Use a visible \"Hypothesis\"\n  chip / badge / prefix on the rendered text — e.g. a small pill\n  before the sentence. Never hide the hypothesis status in body\n  copy alone.\n- Phrase hypotheses with hedged language: \"likely\", \"appears to\",\n  \"may\", \"suspect that\". Do **not** write \"this caused\" / \"this\n  broke\" / \"this is wrong\" as bare assertions.\n- When evidence is thin (one stack frame, one CI line, a hunk you\n  can't fully see) say so. \"The visible frames don't show the call\n  site — the cause may be outside this trace.\"\n- If two competing explanations both fit the evidence, list both as\n  separate hypotheses with what would distinguish them. Do not pick\n  one and call it the answer.\n\nThe point is: a reviewer should be able to disagree with your read\nwithout having to argue with the framing. Say what you saw, then say\nwhat you suspect, and keep those two layers separate.\n\n## Always include\n\n- Terminal CLI dark mode only. Use the developer style's token override:\n  black background, terminal green foreground, amber warnings, red errors,\n  square corners, 1px borders, no shadows.\n- Mobile-first responsive — terminal panes stack, raw drill-down becomes a\n  single-column scroll on narrow viewports, and long code/log lines wrap only\n  where doing so will not destroy evidence readability.\n- Charts/visuals render as inline SVG or ASCII-style bars (no Chart.js, no\n  CDNs). Prefer `[|||||.....]`, hunk strips, ledgers, and directory rollups\n  over glossy charts.\n- Monospace (`var(--font-mono)`) for every visible character: body text,\n  headings, code, file path, line number, hash, frame, and log line.\n- Diff coloring: additions in `var(--green)`, deletions in `var(--red)`,\n  context in `var(--fg-2)`. CI log errors in `var(--red)`, warnings in\n  `var(--yellow)`. Keep panels black; do not paint the whole panel red.\n- Full-text search across the raw artifact — terminal prompt style field\n  (`grep@raw:~$`) that filters or highlights matching lines.\n- Page total under ~500 KB inlined where possible. The raw artifact drives\n  size, so render it once (do not duplicate raw text into multiple panels).\n- A footer line that the analysis is best-effort and a hypothesis, not a\n  verdict.\n\n## Tone\n\nOperator-grade. Direct, specific, hedged where it should be hedged.\nUse terminal labels naturally (`[ERR]`, `[WARN]`, `[OK]`, `[HYP]`, `exit=1`,\n`scan --risk`, `grep`) without turning the report into parody.\n\"The `auth/session.ts` change removes the expiry check entirely;\nworth confirming the test added below covers the long-lived-session\ncase\" is a sentence; \"Risk: high\" alone is not. Use sentences in the\nhotspot panes; metrics in the totals row.\n\n## Privacy / safety note (include in the page footer)\n\nAdd a small footer line:\n\n> *[LOCAL] Generated locally — your diff / log / trace never left your\n> machine. The full artifact is embedded in this HTML and rendered in your\n> browser. The analysis above is a hypothesis from a sample, not a verdict;\n> verify against the runtime before acting on it.*\n\nFile v0.1.0:prompts/sources/_document.md\n\n# shared — long-document guidance\n\nUsed by `markdown.md`, `pdf.md`, and `docx.md`. The shape is the same:\nsomething a person could reasonably read in 5–60 minutes, organised in\nsections, where the user wants both *insight first* and *the original\ntext on tap*.\n\nTreat the document as evidence. The page should answer **\"what does\nthis document actually say?\"** before it answers **\"what does it\nlook like?\"**.\n\n## Above the fold (insight-first cards)\n\nAlways include:\n\n- **Executive TL;DR** — 3 one-sentence observations the LLM extracts\n  by reading the opening, headings, and middle sample. Concrete, not\n  vague. (\"The 4-tier pricing collapses to 2 + Enterprise\" beats \"the\n  document discusses pricing.\")\n- **Reading-time meta** — `wordCount`, `readingMinutes`, page or\n  heading count. Small, in the eyebrow.\n- **Pulled quotes** — 2–4 quote-worthy lines the LLM picks from the\n  body. Set as serif callouts.\n- **Key terms / entities / dates** — names, dates, decisions, dollar\n  amounts the LLM saw in the sample. Render as chips or a small grid.\n  Only include items the LLM is confident about; don't hallucinate.\n\nWhen the document has clear analytical structure (claims-with-evidence,\nrecommendations, decisions), surface it as **claim cards**: short\nheadline + 1–2 sentence supporting line + a \"where in the doc\" jump\nlink. This is the highest-leverage card type — it converts a long doc\ninto something a busy reader can act on without reading the whole\nthing.\n\n## Section navigation\n\nIf `headingCount > 5`, render a left-rail TOC on desktop with one-line\nsection descriptions the LLM writes. Mobile: collapse to a \"Jump to\"\ndropdown at the top.\n\nFor documents with explicit page structure (PDF), prefer\n*section + page* labels (\"§3 Operator Software · p.6\") so the user can\ncite back into the original.\n\n## Reading mode\n\nTwo reading modes, switchable by a top-right toggle:\n\n- **5-minute version** — TL;DR + quotes + claim cards + section\n  summaries. The LLM writes the section summaries from the sample.\n- **Full reading mode** — render the entire document body\n  client-side from the inlined `DATA`. Markdown for `.md` / `.docx`\n  (use a tiny inline parser, ~80 lines for headings, paragraphs,\n  lists, blockquotes, code, bold, italic, links). For PDFs, render\n  page text blocks with a page divider between them.\n\nDefault to **5-minute version** when `wordCount > 1500` or `pageCount\n> 4`. Default to full reading otherwise.\n\n## Always include\n\n- Cmd-F-style search that highlights matches across the body and\n  scrolls the first hit into view.\n- Print-friendly stylesheet (the user may want a clean printout of the\n  insight view).\n- \"Copy as Markdown\" of the document body (`DATA.markdown` for docx,\n  `DATA.text` for pdf, `DATA.markdown` for markdown).\n- A small \"How I read this\" footer line that names the model and\n  states \"the sample was analyzed; the full text is rendered\n  client-side from inlined data.\"\n\n## Tone\n\nMatch the document. Strategy / research deck → confident sans, tighter\ntype, brand-orange accent on numbers. Personal essay → serif body,\ngenerous leading, warm dark mode. Internal memo → neutral, table-led,\nmono for IDs and dates. The Clockless tokens cover both registers;\nonly the typographic choice shifts.\n\nFile v0.1.0:prompts/sources/_event_stream.md\n\n# Event stream (shared)\n\nThis prompt is shared by every event-stream source: **JSONL / NDJSON\napplication events**, **web/server access logs**, **error logs**,\n**syslog**, and **generic timestamped event lines**. The parser already\nnormalized them into the same shape — don't write different rendering\nlogic per source. Use the `format` field to label the chrome.\n\nThe output is **not a log viewer**. It's an operations-shaped\ninfographic that makes the user say *\"oh, here's what's actually\nhappening in this stream\"* — when traffic spiked, what's failing, who\nor what is dominant, and which events look unusual — with the raw\nevents as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the event-stream contract. The page **must**\ninclude all of them, with the literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint; do not skip any of\nthem even on a small or single-source stream.\n\n1. **Volume over time** — a histogram of event counts per time bucket\n   (per-minute, per-5-minute, per-hour, or per-day depending on the\n   stream's duration). Drive it from `DATA.timeBuckets` (already\n   aggregated as `[{ bucket, label, count, errorCount }]`). Render\n   inline SVG. Stack or color-code by severity if the stream has\n   levels. Visible heading \"Volume over time\" or equivalent.\n2. **Severity / category breakdown** — a labeled \"Severity\" or\n   \"Levels\" panel showing counts per severity (`error`, `warn`,\n   `info`, `debug`, `trace`) and/or per category (HTTP status class,\n   event type, logger). Drive it from `DATA.severityCounts` and\n   `DATA.categoryCounts`. Render as filter chips that toggle the\n   drill-down table. If a level is empty, render an empty-state row\n   (\"No errors in this window.\") rather than omitting it. The literal\n   labels \"Severity\" / \"Levels\" / \"Categories\" or equivalent must be\n   visible.\n3. **Outliers / anomalies** — a labeled \"Outliers\" or \"Anomalies\"\n   panel with 4–8 cards calling out unusual events: error bursts,\n   slow requests, rare status codes, top error messages, IPs with\n   abnormally high request counts, schema outliers (records with\n   unusual key combinations), value spikes. Drive it from\n   `DATA.outliers` (already classified `kind: \"burst\" | \"slow\" |\n   \"rare\" | \"top-error\" | \"top-source\" | \"schema\"`) plus anything\n   else you can pull from the sample. If the sample is too thin to\n   support anomaly detection, render a placeholder card (\"Stream is\n   small enough that nothing stands out as unusual.\"). The literal\n   label \"Outliers\" or \"Anomalies\" must be visible.\n4. **Top sources / endpoints / messages** — a labeled \"Top\" panel\n   with a leaderboard of the dominant value in the stream — top\n   endpoints for an access log, top error messages for an error log,\n   top event types for application events. Drive it from\n   `DATA.topMessages` / `DATA.topSources` (already sorted descending).\n   Each row shows the value, count, and share. Visible heading \"Top\"\n   or \"Leaderboard\".\n5. **Searchable event table drill-down** — a collapsible \"Browse all\n   N events\" section with the full stream (data inlined). Default to\n   collapsed so the analysis is the headline. Inside: a virtualized\n   or paginated table (the stream can be tens of thousands of rows),\n   severity filter chips, full-text search across the message field,\n   timestamp + severity + message + source columns at minimum, click\n   a row to expand the full structured fields. Highlight error rows\n   in the brand error color (`var(--red)`). The drill-down is a hard\n   requirement; it's how trust gets re-earned after the inferred\n   analysis.\n\nRender these five regardless of stream size. They are the headline\nshape of the event-stream pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the stream's shape)\n\n- **Stream card (top)** — format (`jsonl` / `ndjson` / `access-log`\n  / `error-log` / `syslog` / `app-log`), event count, time range, error\n  rate, distinct sources, and a one-sentence read on the stream\n  (\"19,420 events over 2.5 hours — error rate jumped from 0.3% to\n  4.1% around 14:20 UTC and recovered by 14:45\").\n- **Error timeline** — separate sparkline of error-only events to\n  surface incident windows that the all-events histogram hides.\n- **Top errors** — error-level events grouped by normalized message\n  (drop trailing IDs, hex hashes, request-ids), each with count and\n  first/last seen timestamp.\n- **Status code donut** — for access logs, share of 2xx / 3xx / 4xx\n  / 5xx. One glance = \"92% success, 3.2% server errors\".\n- **Latency distribution** — for access logs that capture\n  `response_time` / `duration_ms`, p50 / p95 / p99 + a histogram. If\n  no latency is present, skip the section.\n- **Top endpoints** — for access logs, paths ranked by hit count;\n  badge ones with elevated error rate.\n- **Top IPs / users** — leaderboard of source IPs or `user_id`\n  fields; badge ones with abnormally high counts as potential abuse.\n- **Schema panel** — for JSONL/NDJSON, a small panel listing inferred\n  fields with their type and fill rate (`level: string · 100%`,\n  `user_id: string · 87%`, `error_code: string · 4.2%`). Click a\n  field to filter the table by non-null values of that field.\n- **User-agent / referrer summary** — for access logs, top user\n  agents and referrers as small chip clouds.\n- **Burst markers** — pin 3–6 spikes in the histogram (top 1% of\n  buckets by count or error count). Each pin is one sentence\n  (\"error spike at 14:23 — 47 events in one minute, mostly\n  `payment_failed`\").\n- **Filter combos** — let users combine severity filter + search +\n  time-range brush on the histogram. The drill-down table reflects\n  all three.\n\nDon't try to do all of these. Pick 3–6 beyond the required five,\nbased on what the data supports.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — analysis cards stack, histogram shrinks\n  but stays readable, severity chips wrap, table becomes horizontally\n  scrollable.\n- Charts render inline SVG (no Chart.js, no CDNs) for under ~2000\n  data points. Use Canvas for bigger streams (some access logs run\n  10K+ buckets when binned per minute over a week).\n- Keep the page under ~1 MB inlined where possible — event streams\n  can be hundreds of thousands of rows. The table renders from\n  `DATA.events` only — do not duplicate event text in the analysis\n  section.\n- \"Copy as Markdown\" of the analysis section (so users can paste an\n  incident summary into a postmortem doc).\n- Full-text search across the event message + source; highlight\n  matches in place.\n- A virtualized or windowed table for the drill-down — naïvely\n  rendering 50K `<tr>` elements freezes the browser. Either render a\n  fixed window (e.g. 200 rows) with a \"load more\" button, or\n  implement an absolutely-positioned scroll-virtualization pattern.\n\n## Data shape\n\nEvery event-stream parser feeds the same shape. Treat it generically.\n\n```ts\nDATA = {\n  events: [\n    {\n      id: \"e_000001\",\n      ts: \"2026-04-12 09:14:00\",         // sortable\n      date: \"2026-04-12\",\n      time: \"09:14:00\",\n      tsEpoch: 1744449240000,\n      severity: \"error\" | \"warn\" | \"info\" | \"debug\" | \"trace\" | null,\n      category: \"auth\" | \"GET 200\" | \"payment\" | null,  // free-form\n      source: \"api-edge-01\" | \"192.0.2.42\" | \"auth-service\" | null,\n      message: \"...\",                    // human-readable summary\n      fields?: { user_id: \"u_42\", request_id: \"...\", duration_ms: 312 },\n      raw: \"...\"                         // original line, for drill-down\n    }\n  ],\n  timeBuckets: [\n    { bucket: \"2026-04-12T09:14\", label: \"09:14\", count: 142, errorCount: 3 }\n  ],\n  severityCounts: { error: 312, warn: 41, info: 18420, debug: 0 },\n  categoryCounts: [{ category: \"GET 200\", count: 14820 }, ...],\n  topMessages: [{ message: \"request completed\", count: 12410, share: 64.0 }, ...],\n  topSources: [{ source: \"192.0.2.42\", count: 1182, share: 6.1 }, ...],\n  topErrors: [{ message: \"DB connection refused\", count: 47, firstTs, lastTs }, ...],\n  outliers: [\n    { kind: \"burst\", label: \"Error spike 14:23\", detail: \"47 events in 1 min\", ts },\n    { kind: \"slow\", label: \"Slow GET /reports\", detail: \"p99 = 4.7s vs 220ms median\", ts },\n    { kind: \"rare\", label: \"503 from /checkout\", detail: \"first occurrence in 24h\", ts },\n    { kind: \"top-error\", label: \"DB connection refused\", detail: \"47×\", ts },\n    { kind: \"top-source\", label: \"192.0.2.42\", detail: \"6.1% of all events\", ts: null },\n    { kind: \"schema\", label: \"Field user_id missing\", detail: \"in 12.8% of events\", ts: null }\n  ],\n  schema?: [                                 // jsonl / ndjson only\n    { field: \"user_id\", type: \"string\", fillPct: 87.4, examples: [\"u_42\", \"u_7c1\"] },\n    ...\n  ],\n  format: \"jsonl\" | \"ndjson\" | \"access-log\" | \"error-log\" | \"syslog\" | \"app-log\",\n  timeRange: \"2026-04-12 09:14:00 → 2026-04-12 11:42:18\",\n  durationLabel: \"2h 28m\",\n  eventCount: 19420,\n  errorCount: 312,\n  errorRate: 1.61,                            // percent\n  bucketSize: \"1m\" | \"5m\" | \"15m\" | \"1h\" | \"1d\",\n  sourceCount: 14,\n  meta: { sourceFile, sizeBytes, ... }\n}\n```\n\nUse the pre-aggregated `timeBuckets` / `severityCounts` /\n`categoryCounts` / `topMessages` / `topSources` / `topErrors` /\n`outliers` arrays directly. Do **not** re-derive them on the client —\nthe parser already did the math, and walking the full event array\nfor analysis kills performance on big streams.\n\n## Tone\n\nOperations / SRE register. Headlines read like an incident write-up,\nnot a dashboard caption. \"Error rate jumped from 0.3% to 4.1% between\n14:20 and 14:45 UTC, almost all from `payment_failed`\" is a sentence;\n\"Errors: 312, Error rate: 1.61%\" is a metric. Use sentences in the\ncards, metrics in the charts. Mono numerics. Tight, technical. The\npage should look like a developer / ops tool — but a well-designed\none.\n\n## Privacy note (include in the page footer)\n\nAdd a small footer line. Application logs and access logs often\ncontain real user IDs, IP addresses, request bodies, and internal\nhostnames — remind the user the file is local:\n\n> *Generated locally — your event stream never left your machine. The\n> full log is embedded in this HTML and rendered in your browser. For\n> sharing, prefer an anonymized export.*\n\nFile v0.1.0:prompts/sources/_finance.md\n\n# Finance / admin (shared)\n\nThis prompt is shared by every finance/admin source: **bank\ntransaction CSVs**, **invoice and receipt exports**, and\n**QuickBooks / Xero-style accounting reports**. The parser already\nclassified the file and pre-computed cashflow rollups, category\ntotals, recurring vendor detection, and duplicate / anomaly cards,\nso don't re-derive them on the client. Use the `format` and\n`subtype` fields to label the chrome.\n\nThe output is **not a bookkeeping replacement**. It's an analytical\nsnapshot that makes the user say *\"oh, here's where my money is\nactually going\"* — what's recurring, what's anomalous, who hasn't\npaid yet, and which categories are eating the budget — with the raw\ntransactions / invoices as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the finance contract. The page **must**\ninclude all of them, with the literal section labels visible in the\nrendered DOM. This is a hard constraint; do not skip any of them\neven on a small file.\n\n1. **Headline summary card** — total inflow, total outflow, net\n   change, period covered, transaction count. Drive it from\n   `DATA.summary`. Format like *\"$48,210 in · $52,840 out · −$4,630\n   net · 87 transactions over Jan 2026\"*. Visible heading \"Summary\"\n   or \"Overview\". For invoice files, swap to *\"$72,400 invoiced ·\n   $44,800 paid · $27,600 outstanding · 38 invoices, 12 customers\"*.\n2. **Category / account breakdown** — labeled \"Categories\" or\n   \"Accounts\" panel: a horizontal bar chart (or donut) of spending /\n   revenue per category, sorted descending, capped at top 8 + \"other\".\n   Drive it from `DATA.categoryTotals` (already aggregated as\n   `[{ category, inflow, outflow, net, count, share }]`). Render as\n   inline SVG. Each row also shows count and share. The literal\n   label \"Categories\" / \"Accounts\" / \"Spend by category\" must be\n   visible.\n3. **Recurring items panel** — labeled \"Recurring\" panel listing\n   auto-detected recurring vendors / charges (subscriptions, rent,\n   payroll, utility bills, recurring invoices). Drive it from\n   `DATA.recurring` (already classified as\n   `[{ name, cadence, avgAmount, count, lastSeen, nextExpected }]`).\n   Show vendor, monthly/weekly/quarterly cadence, average amount,\n   count, last seen date, next expected. Empty state: \"No recurring\n   patterns detected in this file.\" The literal label \"Recurring\"\n   must be visible.\n4. **Anomalies & duplicates callouts** — labeled \"Anomalies\" or\n   \"Flags\" panel with 3–8 cards. Drive from `DATA.flags` (already\n   classified `kind: \"duplicate\" | \"outlier-amount\" | \"rare-vendor\"\n   | \"first-time-vendor\" | \"round-trip\" | \"missing-category\" |\n   \"overdue\" | \"negative-balance\"`). Each card has a one-sentence\n   explanation and a link to the underlying row. Empty state:\n   \"Nothing flagged in this file.\" The literal label \"Anomalies\" or\n   \"Flags\" must be visible.\n5. **Searchable transactions table drill-down** — collapsible\n   \"Browse all N transactions\" (or \"Browse all N invoices\") section\n   with the full file inlined client-side. Default to collapsed so\n   the analysis is the headline. Inside: a virtualized or paginated\n   table (transaction files can run to thousands of rows), category\n   filter chips, full-text search across description / memo / vendor,\n   date / amount / merchant / category columns at minimum, click a\n   row to expand the full original record. Highlight flagged rows\n   (duplicates, outliers, overdue) with a small badge. The drill-\n   down is a hard requirement; it is how trust gets re-earned after\n   the inferred analysis.\n\nRender these five regardless of file size. They are the headline\nshape of the finance pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the file's shape)\n\n- **Cashflow timeline** — line/area chart of inflow vs outflow per\n  day or per week (depending on duration), plus a running balance\n  line if the parser produced one. Use `DATA.timeline`. Surface the\n  spike days as labelled markers (\"Apr 15: payroll cycle, $12,400\n  out\").\n- **Top vendors / customers leaderboard** — for bank files: top 10\n  payees by total outflow + top 5 sources by total inflow. For\n  invoice files: top customers by invoiced + top customers by\n  outstanding balance. From `DATA.topVendors` /\n  `DATA.topCustomers`.\n- **Aging buckets (invoices only)** — 0–30 / 31–60 / 61–90 / 90+\n  days outstanding, total amount per bucket, count per bucket. Drive\n  from `DATA.aging`. Render as a stacked bar with one row per\n  bucket, plus a \"show overdue invoices\" filter that drives the\n  drill-down table.\n- **Status mix (invoices only)** — donut of paid / partially paid /\n  outstanding / overdue, showing both count and amount.\n- **Account / class roll-up (QuickBooks reports only)** — collapsible\n  tree of parent accounts → child accounts with subtotals. Drive\n  from `DATA.accountTree` if present.\n- **Period-over-period delta** — if the file spans ≥2 months, a\n  small \"this month vs last month\" panel highlighting the categories\n  with the biggest swing.\n- **Merchant search chips** — quick filter chips for the top 6\n  recurring vendors, click one to filter the drill-down table.\n- **Inflow vs outflow split** — small donut: % of activity going\n  out vs coming in.\n- **Subscriptions watch (bank only)** — sub-section of the\n  recurring panel: only show entries the parser tagged as\n  `subscription` (small recurring amounts to known SaaS vendors).\n  Useful for \"what am I still paying for?\".\n- **Invoice scorecard (invoices only)** — paid % of total invoiced,\n  average days to pay (when both `issued_date` and `paid_date`\n  exist), median days outstanding for unpaid invoices.\n\nDon't try to do all of these. Pick 3–5 beyond the required five,\nbased on the file's actual shape (`subtype`, `hasBalance`,\n`spansMultipleMonths`, etc.).\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — analysis cards stack, charts shrink but\n  stay readable, category chips wrap, drill-down table becomes\n  horizontally scrollable.\n- Charts render inline SVG (no Chart.js, no CDNs) for under ~2000\n  data points. Use Canvas for bigger files.\n- Currency formatted with the symbol the parser detected\n  (`DATA.summary.currencySymbol`, default `$`). Use grouping\n  separators (`$12,840.50`). Negative amounts in the brand error\n  color (`var(--red)`) with a leading minus, never red parentheses.\n- Tabular numerics (`font-variant-numeric: tabular-nums`) for every\n  amount and date column.\n- \"Copy as Markdown\" of the analysis section so users can paste a\n  monthly review summary into a doc.\n- Full-text search across description / memo / vendor / customer /\n  invoice number; highlight matches in place.\n- A virtualized or windowed table for the drill-down — naïvely\n  rendering 5K `<tr>` elements freezes mobile browsers. Either render\n  a fixed window (e.g. 200 rows) with a \"load more\" button, or\n  implement an absolutely-positioned scroll-virtualization pattern.\n\n## Data shape\n\nEvery finance parser feeds the same shape. Treat it generically.\n\n```ts\nDATA = {\n  format: \"bank-transactions\" | \"invoices\" | \"quickbooks-report\",\n  subtype: \"bank\" | \"credit-card\" | \"invoices\" | \"receipts\" | \"quickbooks-gl\" | \"quickbooks-pl\" | \"xero-report\",\n  rows: [\n    {\n      id: \"tx_000001\",\n      date: \"2026-01-04\",\n      amount: -42.99,                      // signed: negative = outflow, positive = inflow\n      currency: \"USD\",\n      description: \"STRIPE TRANSFER\",\n      merchant: \"Stripe\" | null,           // normalized vendor when extractable\n      category: \"Software\" | null,\n      memo: \"monthly fee\" | null,\n      account: \"Checking 4421\" | null,\n      balance: 12840.50 | null,            // running balance if file had one\n      status: \"paid\" | \"outstanding\" | \"overdue\" | null,   // invoices\n      dueDate: \"2026-02-04\" | null,        // invoices\n      issuedDate: \"2026-01-04\" | null,     // invoices\n      customer: \"Northwind Co.\" | null,    // invoices\n      invoiceNumber: \"INV-1042\" | null,    // invoices\n      flags: [\"duplicate\"] | [],\n      raw: { ... }                         // original CSV row, for drill-down\n    }\n  ],\n  summary: {\n    rowCount: 87,\n    inflow: 48210.00,\n    outflow: 52840.00,\n    net: -4630.00,\n    currencySymbol: \"$\",\n    currencyCode: \"USD\",\n    period: \"2026-01-04 → 2026-01-31\",\n    durationLabel: \"27 days\",\n    distinctMerchants: 34,\n    distinctCategories: 12,\n    // invoices-only:\n    invoiced?: 72400.00,\n    paid?: 44800.00,\n    outstanding?: 27600.00,\n    overdue?: 8400.00,\n    invoiceCount?: 38,\n    customerCount?: 12,\n  },\n  categoryTotals: [\n    { category: \"Payroll\", inflow: 0, outflow: 18400.00, net: -18400.00, count: 4, share: 34.8 },\n    ...\n  ],\n  recurring: [\n    { name: \"Stripe\", cadence: \"monthly\", avgAmount: -42.99, count: 4, lastSeen: \"2026-01-15\", nextExpected: \"2026-02-15\", tag: \"subscription\" },\n    ...\n  ],\n  flags: [\n    { kind: \"duplicate\", label: \"Duplicate Stripe charge\", detail: \"$42.99 on 2026-01-15 and 2026-01-15\", rowIds: [\"tx_42\",\"tx_43\"] },\n    { kind: \"outlier-amount\", label: \"Unusually large transfer\", detail: \"$8,400 on 2026-01-22 — 12× median outflow\", rowIds: [\"tx_61\"] },\n    { kind: \"first-time-vendor\", label: \"First-time vendor: ALPINE TOOLS\", detail: \"$1,420 — no prior history in this file\", rowIds: [\"tx_72\"] },\n    { kind: \"overdue\", label: \"INV-1031 is 47 days overdue\", detail: \"Northwind Co., $4,200 outstanding\", rowIds: [\"inv_31\"] },\n    { kind: \"missing-category\", label: \"12 transactions missing category\", detail: \"$2,840 unaccounted for\", rowIds: [...] },\n    ...\n  ],\n  timeline: [\n    { date: \"2026-01-04\", inflow: 4200.00, outflow: 1840.00, net: 2360.00, balance: 12840.50, count: 6 },\n    ...\n  ],\n  topVendors: [{ name: \"Stripe\", outflow: 172.00, count: 4 }, ...],\n  topCustomers?: [{ name: \"Northwind Co.\", invoiced: 22400.00, paid: 18000.00, outstanding: 4400.00, count: 6 }, ...],\n  aging?: [\n    { bucket: \"0-30\",  amount: 12400.00, count: 4 },\n    { bucket: \"31-60\", amount:  6800.00, count: 3 },\n    { bucket: \"61-90\", amount:  4400.00, count: 2 },\n    { bucket: \"90+\",   amount:  4000.00, count: 1 },\n  ],\n  accountTree?: [\n    { account: \"Income\", subtotal: 48210.00, children: [\n      { account: \"Income:Consulting\", subtotal: 32000.00, children: [] }, ...\n    ]},\n    ...\n  ],\n  meta: { sourceFile, sizeBytes, ... }\n}\n```\n\nUse the pre-aggregated `summary` / `categoryTotals` / `recurring` /\n`flags` / `timeline` / `topVendors` / `topCustomers` / `aging`\narrays directly. Do **not** re-derive them on the client — the\nparser already did the math, and walking thousands of rows for\nanalysis kills performance on big files.\n\n## Tone\n\nBookkeeper / analyst register, not investor pitch. Headlines read\nlike a monthly close note: *\"$4,630 net outflow this month —\npayroll and SaaS subscriptions account for 64% of spend, with one\nunusually large $8,400 transfer to ALPINE TOOLS that's the only\nfirst-time vendor of the month.\"* Use sentences in the cards,\nmetrics in the charts. Mono numerics. Currency-aware. Tight,\nanalytical. The page should look like a finance tool — but a well-\ndesigned one.\n\n## Hard editorial rules — not accounting / tax / legal advice\n\nThis output is **analytical only**, never accounting / tax / legal\nadvice. The page **must not**:\n\n- Use the words \"advice\", \"should file\", \"owe\", \"report to the\n  IRS\", \"tax-deductible\", \"legally\", \"audit-ready\", or any phrasing\n  that implies a determination of tax treatment, legal status, or\n  fiduciary obligation.\n- Recommend a specific course of action (\"you should pay this\n  invoice\", \"categorize this as a deduction\"). Describe what's in\n  the file; do not prescribe what to do.\n- Compute or claim \"tax owed\", \"deductible amount\", \"net taxable\",\n  or any tax-derived figure.\n- Imply the categorization is canonical — recurring detection,\n  category breakdown, and anomaly callouts are pattern-matching on\n  the file's text, not authoritative classifications.\n\nThe page **must** include a footer line:\n\n> *Analytical summary, not accounting or tax advice. Categories\n> and recurring patterns are inferred from the file's text — verify\n> against your books before acting on anything here.*\n\nTreat every flagged row as a \"worth a second look\" prompt for the\nuser, not a determination. Cards never say \"this is wrong\" — they\nsay \"this looks like a duplicate / outlier / first-time vendor\".\n\n## Privacy note (include in the page footer)\n\nAdd a small footer line. Bank exports, invoice files, and\nQuickBooks reports almost always contain real account numbers,\ncustomer names, vendor relationships, and dollar amounts — remind\nthe user the file is local:\n\n> *Generated locally — your finance file never left your machine.\n> The full transaction list is embedded in this HTML and rendered\n> in your browser. For sharing, prefer an anonymized export with\n> account numbers and customer names redacted.*\n\nFile v0.1.0:prompts/sources/_geo.md\n\n# Geo / travel (shared)\n\nThis prompt is shared by every geo source: **GPX routes and workouts\n(`.gpx`)**, **KML coordinates (`.kml`)**, **multi-day travel itineraries\n(`.csv`)**, and **location history (Google-Takeout-style `.json` or a\nflat lat/lon CSV)**. The parser already normalized them into a unified\nshape — don't write different rendering logic per format. Use\n`DATA.kind` (`route` | `itinerary` | `location-history`) and\n`DATA.format` to label the chrome and pick the framing.\n\nThe output is **not a map viewer**. It's a geo-shaped infographic that\nmakes the user say *\"oh, here's how the route actually broke down /\nwhat this trip looks like / where I actually spent my time\"* — with\nthe raw points / waypoints / itinerary items as drill-down.\n\n## Hard constraint — offline only, no map tiles\n\nThis is non-negotiable. The output is a single self-contained `.html`\nthat must work offline. **Do not** embed Leaflet, Mapbox, Google Maps,\nOpenStreetMap tiles, or any other tile provider. **Do not** call out\nto a CDN for a basemap. **Do not** use a `<script src=\"...\">` for\nmapping libraries.\n\nRender the route geometry and place dots as **inline SVG** using the\nparser's pre-projected coordinates:\n\n- `DATA.tracks[].polyline` is already a fully-formed SVG string of the\n  shape `viewBox=\"0 0 W H\" points=\"x1,y1 x2,y2 ...\"` — drop it inline:\n  `<svg ${polyline}><polyline fill=\"none\" stroke=\"...\" stroke-width=\"3\" points=\"...\"/></svg>`\n  (you'll need to split off the points). Or simply:\n  `<svg viewBox=\"0 0 W H\"><polyline points=\"x1,y1 ...\" fill=\"none\" .../></svg>`\n- For waypoints / placemarks / dwelled places, project lat/lon into\n  the same viewBox using `DATA.bbox` and a cosine-corrected\n  equirectangular projection. The parser already used cosine-corrected\n  longitude when computing the polyline so dots match up:\n  ```\n  const avgLat = (bbox.minLat + bbox.maxLat) / 2\n  const lonScale = Math.cos(avgLat * Math.PI / 180)\n  const W = 1000  // matches polyline viewBox\n  const sx = W / ((bbox.maxLon - bbox.minLon) * lonScale)\n  const sy = H / (bbox.maxLat - bbox.minLat)\n  const x = (lon - bbox.minLon) * lonScale * sx\n  const y = (bbox.maxLat - lat) * sy\n  ```\n- Add a subtle background grid or graticule (every 0.01° lat/lon)\n  rather than a basemap so the SVG reads as a geometric trace, not a\n  half-rendered map.\n- A small north arrow + scale bar (using haversine math from `bbox`)\n  is welcome — both render purely client-side from `DATA`.\n\nMake it visually rich without leaning on a basemap: gradient stroke\nalong the polyline (start → end color shift), elevation-shaded path\nsegments, dwell-time-shaded place dots, etc. The infographic\ntreatment is the design surface here.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the geo contract. The page **must** include\nall of them, with the literal section labels visible somewhere in the\nrendered DOM.\n\n1. **Stats card (top)** — depending on `DATA.kind`:\n   - `route` (GPX / KML): big mono numbers — distance, duration,\n     elevation gain, average pace or speed, max speed when present.\n     One-sentence headline (\"8.4 km run on 2026-04-21 — 42 min at\n     5:00/km, 38 m gain.\").\n   - `itinerary`: total days, cities, countries, item count, total\n     cost when present. Headline (\"7-day Tokyo + Kyoto trip, 4 cities,\n     22 stops, $4,200 total.\").\n   - `location-history`: total points, days, unique places, date\n     range. Headline (\"12 days of pings, 18 unique places, 4 city\n     clusters; ~70% of dwell time at 'Home'.\").\n2. **Route visualization** — labeled \"Route\" / \"Map\" / \"Trace\" /\n   \"Footprint\":\n   - For `route`: an inline-SVG polyline rendered from\n     `DATA.tracks[].polyline`. Add a start dot (green) + end dot\n     (red), waypoint dots labeled by `name`, and a gradient stroke if\n     it reads well. For multi-track GPX, render each track in a\n     different hue.\n   - For `location-history`: scatter the top-N dwelled places as\n     dots sized by dwell time, then optionally connect chronologically\n     with a thin path. Use `DATA.places` + `DATA.bbox` for projection.\n   - For `itinerary`: when items have lat/lon, render dots; otherwise\n     render a horizontal day-strip showing each day's anchor city.\n3. **Stats / timeline view** — labeled \"Splits\" / \"Elevation\" /\n   \"Timeline\" / \"Day by day\":\n   - For `route` with timestamps: km splits as a horizontal bar chart\n     (pace per km, slowest split highlighted) plus the elevation\n     profile as a sparkline area chart from\n     `DATA.tracks[].elevationProfile`.\n   - For `route` without timestamps: just the elevation profile + a\n     waypoint sequence list.\n   - For `itinerary`: a vertical day-by-day timeline. Each day card\n     shows date + anchor city + items (time → title with type chip).\n     Conflicts (overlapping items) flagged in `var(--red)`.\n   - For `location-history`: an hour-of-day activity heatmap (24\n     buckets from `DATA.hourCounts`) and a per-day point-count\n     density strip from `DATA.days`.\n4. **Waypoints / segments / places list** (filterable + searchable) —\n   labeled \"Waypoints\" / \"Places\" / \"Segments\":\n   - For `route`: the waypoint list (name + lat/lon mono + ele +\n     description) + a segment list when splits exist (km marker +\n     pace + elevation).\n   - For `itinerary`: cities + countries + types as filter chips; the\n     items list as a searchable table.\n   - For `location-history`: top-N places sorted by dwell time\n     (rank + lat/lon mono + minutes/hours + visit count). Filter by\n     activity (walking / driving / still / biking) when present.\n5. **Searchable item drill-down** (collapsible, default closed) —\n   labeled \"Browse all N items\":\n   - For `route`: every track point in a virtualized table (idx /\n     timestamp / lat / lon / ele / pace), highlight pauses.\n   - For `itinerary`: every item with all columns.\n   - For `location-history`: every ping (downsampled to ≤ 5000 rows\n     when the file is huge — the parser keeps the full list in\n     `DATA.points`, but the UI table can virtualize / paginate).\n\nRender these five regardless of dataset size. They are the headline\nshape of the geo pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the dataset's shape)\n\nFor routes:\n\n- **Pace / speed profile** — `DATA.tracks[].paceProfile` rendered as a\n  rolling sparkline. Useful for runs and rides; skip for hikes when\n  noisy.\n- **Pauses panel** — `DATA.tracks[].pauses` as cards (location +\n  duration). Often the answer to \"where did I stop?\".\n- **Elevation extremes** — pinned high / low points.\n- **Best split** — slowest / fastest km, big-effort callouts.\n- **Activity classification** — `DATA.activityKind` (run / ride / walk\n  / hike / trip) as a chip near the title.\n\nFor itineraries:\n\n- **Cities / countries leaderboards** — from `DATA.cities` /\n  `DATA.countries` — counts of stops per place.\n- **Type breakdown** — from `DATA.types` — flights / hotels /\n  restaurants / activities. Stacked-bar or donut.\n- **Cost rollup** — when `DATA.totals.totalCost` is set: total + per-\n  day + per-city.\n- **Conflict callouts** — from `DATA.conflicts` — same-day overlapping\n  items (two restaurants at 19:00 in different cities). Flag them.\n- **Day cards** — each `DATA.days[i]` as its own card with the day's\n  anchor city, item count, and a tiny inline timeline bar of the day.\n\nFor location history:\n\n- **Top places leaderboard** — top 10 by dwell time, labeled with\n  reverse-geocoded names if present, otherwise by rounded lat/lon.\n- **City clusters** — group nearby places (within ~5 km) into city\n  clusters using a quick lat/lon bucketing on the client.\n- **Activity stacked bar** — when `points[].activity` is present, show\n  walking / driving / still / biking per day.\n- **Travel days vs. dwell days** — flag days where the user moved\n  more than ~10 km.\n\nDon't try to do all of these. Pick 3–6 beyond the required five,\nbased on what the data supports.\n\n## Interaction discipline\n\n- Filter chips compose, never override. Selecting \"France\" + \"hotel\"\n  filters the itinerary list to French hotels only; the visualization\n  also dims non-matching items.\n- Search across name + lat/lon + city + country + notes. Highlight\n  matches inline.\n- Hover / focus on a route polyline shows the index + lat/lon + ele +\n  pace at that point. Click a waypoint dot to scroll the drill-down\n  to that row.\n- Hover on a place dot shows `place.name (visits, minutes)`.\n- This is a read-only audit. No \"edit\", \"rename place\", or \"split\n  segment\" actions.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — the SVG scales but stays readable, stat\n  cards stack, filters wrap, drill-down list goes single-column.\n- Charts render inline SVG (no Chart.js, no CDNs).\n- Keep the page under ~1 MB inlined where possible. Workouts under\n  ~500 KB; long location histories may need point downsampling for\n  the SVG (the parser already gives you a downsampled polyline).\n- \"Copy as Markdown\" of the analysis section — paste-ready into a\n  trip log, training journal, or weekly review.\n- Mono numerics (lat/lon, distance, pace, elevations); body type for\n  names / notes / descriptions.\n\n## Data shape\n\nEvery geo parser feeds the same envelope; `DATA.kind` switches the\nframing.\n\n```ts\nDATA = {\n  kind: \"route\" | \"itinerary\" | \"location-history\",\n  format: \"gpx\" | \"kml\" | \"itinerary-csv\" | \"location-history-json\" | \"location-history-csv\",\n\n  // route only (GPX / KML)\n  metadata?: { name?: string; time?: string; creator?: string },\n  activityKind?: \"run\" | \"ride\" | \"walk\" | \"hike\" | \"trip\" | \"kml-trip\",\n  isWorkout?: boolean,\n  tracks?: [\n    {\n      name?: \"Morning Run\",\n      pointCount: 320,\n      bbox: { minLat, maxLat, minLon, maxLon },\n      stats: {\n        pointCount, distanceKm, elapsedSec, movingSec, pausedSec,\n        elevationGainM, elevationLossM, minEleM, maxEleM,\n        avgPaceSecPerKm, movingPaceSecPerKm, maxSpeedKmh, avgSpeedKmh,\n        startTime, endTime,\n      },\n      polyline: 'viewBox=\"0 0 1000 480\" points=\"0.0,0.0 1.2,2.4 ...\"',\n      splits: [{ km: 1, durationSec, paceSecPerKm, elevationGainM, ... }],\n      elevationProfile: [{ km: 0.05, ele: 12.4 }, ...],\n      paceProfile?: [{ km: 0.20, paceSecPerKm: 348 }, ...],\n      pauses?: [{ atKm, durationSec, lat, lon, time? }],\n    }\n  ],\n  waypoints?: [{ lat, lon, ele?, name?, description?, time? }],\n  totals?: { pointCount, distanceKm, elapsedSec?, movingSec?,\n              elevationGainM?, maxSpeedKmh?, startTime?, endTime?,\n              trackCount },\n  bbox?: { minLat, maxLat, minLon, maxLon },\n\n  // itinerary only\n  items?: [{ id, date?, dateEpoch?, dayNumber?, time?, location?,\n             city?, country?, type?, title, notes?, cost?, currency?,\n             durationHours? }],\n  days?: [{ date, dayNumber?, items: [...] }],\n  conflicts?: [{ date?, items: [...] }],\n  cities?: [{ name, count }],\n  countries?: [{ name, count }],\n  types?: [{ name, count }],\n  totals?: { items, days, cities, countries, totalCost?, costItems },\n\n  // location-history only\n  points?: [{ t, tEpoch, lat, lon, accuracy?, activity? }],\n  places?: [{ key, lat, lon, visits, minutes }],\n  topPlaces?: [...],          // first 100 places by dwell minutes\n  days?: [{ date, pointCount, uniquePlaces }],\n  hourCounts?: number[24],\n  bbox?: { minLat, maxLat, minLon, maxLon },\n  totals?: { points, uniquePlaces, days },\n\n  meta: { sourceFile, sizeBytes, format, kind, ... }\n}\n```\n\nUse the pre-aggregated arrays directly. Do **not** re-compute splits,\nelevation profile, pace profile, places, day buckets, or hour counts\non the client — the parser already did the math, and re-walking\n`points` (which can be 50K+) on the main thread will jank the page.\n\n## Tone\n\nOperator's-review register for routes and history; trip-log register\nfor itineraries.\n\n- Routes: \"8.4 km on 2026-04-21 — 42 min at 5:00/km, slowest split\n  km 6 (5:32) on the climb.\" Honest about pace + elevation.\n- Itineraries: \"Day 3 in Kyoto — 4 stops; the 19:00 dinner conflicts\n  with the 18:30 onsen, pick one.\"\n- Location history: \"12 days of pings, 4 city clusters, ~70% of\n  dwell time at one place — likely Home.\"\n\nMono numerics, body sentences. Never claim certainty about places the\nuser didn't label (use \"(unnamed cluster)\" for ungeocoded coordinate\nclusters).\n\n## Privacy / safety note (include in the page footer)\n\nGPS traces show home + work + travel. Location history is the\nstrongest re-identification signal in this whole pack. Add a small\nfooter line:\n\n> *Generated locally — your route / itinerary / location data never\n> left your machine. The full export is embedded in this HTML and\n> rendered in your browser; no map tiles are loaded. For sharing,\n> prefer an anonymized / cropped export.*\n\nFile v0.1.0:prompts/sources/_knowledge_base.md\n\n# Knowledge base / multi-document markdown (shared)\n\nThis prompt is shared by every \"folder of markdown\" source: **Notion\nmarkdown exports**, **Obsidian vaults**, and **generic markdown\ndirectories** (Hugo content folders, Bear exports, \"Notes\"\ndirectories). The parser walks the folder, builds a backlink graph,\nextracts tags + TODOs, and inlines every note's full text. Don't\nre-walk the corpus on the client — use the pre-built aggregations.\n\nThe output is **not a file browser or wiki clone**. It's a *concept\nmap* of the user's notes — what's connected, what's the hub, what's\nbeen sitting unread, what's still on the to-do list — with the full\nnotes as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the knowledge-base contract. The page\n**must** include all of them, with the literal section labels visible\nsomewhere in the rendered DOM. Hard constraint; do not skip any of\nthem even on a small vault.\n\n1. **Concept map / backlink graph** — a graph or list-graph hybrid of\n   notes and their connections, drawn from `DATA.graph.nodes` +\n   `DATA.graph.edges` and `DATA.topHubs`. Render as inline SVG. Node\n   size scales with `inboundCount` (the more notes link here, the\n   bigger the hub). On vaults under ~80 notes, draw an actual force-\n   directed-style or radial graph with edges visible. On larger\n   vaults, fall back to a list-graph hybrid: a leaderboard of the top\n   hubs with their incoming/outgoing connections shown as inline\n   chips. The literal heading \"Concept map\" / \"Connections\" /\n   \"Backlink graph\" or equivalent must be visible.\n2. **Theme clusters / tag panel** — visualize how the corpus splits\n   along themes. Use `DATA.topTags` (frontmatter + inline `#tag`\n   tags) when present, falling back to `DATA.themeClusters` (which\n   the parser fills with top-folder groupings if no tags exist). For\n   each theme: name + count + a clickable pill that filters the\n   drill-down. The literal heading \"Themes\" / \"Tags\" / \"Clusters\" or\n   equivalent must be visible.\n3. **TODO / stale / orphan callouts** — three labeled callout blocks.\n   - **TODOs**: card with `DATA.todoStats.openCount` open items and\n     5–8 representative lines from `DATA.topTodos` (each with a link\n     back to its note).\n   - **Stale notes**: card showing notes from `DATA.stale` (older than\n     the family's stale threshold, default 60 days) with `ageDays` per\n     row.\n   - **Orphans**: card showing notes from `DATA.orphans` (notes with\n     no inbound links) with the title + folder + age.\n   If any of the three lists is empty, render the card with a friendly\n   placeholder (\"No open TODOs in this vault.\") rather than omitting\n   it. The literal labels \"TODO\" / \"Open todos\" / \"Stale\" / \"Orphan\"\n   / \"Unlinked\" or equivalents must be visible. All three matter —\n   they answer \"what's owed?\" \"what's drifting?\" \"what's lonely?\".\n4. **Searchable knowledge atlas (drill-down)** — a collapsible\n   \"Browse all N notes\" section with the full corpus, default\n   collapsed so the analysis is the headline. Inside: virtualized or\n   paginated note cards / rows showing title + path + tag chips +\n   wordCount + age + open-todo count. Filter chips for tags + folder\n   + status (orphan / stale / has-todos). Full-text search across\n   `title` + `path` + `tags` + `excerpt`. Click a note to expand\n   its full body (rendered from `note.raw`) in a side panel or\n   accordion, plus an inline list of its inbound + outbound links\n   with click-through to the linked notes' full bodies. The drill-\n   down is a hard requirement; without it the analysis can't be\n   trusted.\n5. **Top-pages index / hub leaderboard** — a labeled \"Hubs\",\n   \"Most-linked notes\", or \"Index\" section pulling\n   `DATA.topHubs`. For each hub: title + inbound count + outbound\n   count + a one-line excerpt. This is what tells the user \"if you\n   only re-read 6 notes from this vault, these are the 6\". Visible\n   heading \"Top notes\" / \"Hubs\" / \"Most-linked\" or equivalent.\n\nRender these five regardless of vault size. They're the contract;\nwithout them the output is incomplete.\n\n## What else to surface (pick what fits the vault's shape)\n\n- **Vault summary card (top)** — note count, total cross-note links,\n  unique tags, total open TODOs, distinct folders, and a one-sentence\n  read on the corpus (\"14 notes, 88 links, 5 tags, 26 open TODOs —\n  Pricing V2 is the densest hub with 11 inbound links, and the\n  Resources/ folder has two stale notes from late 2025\").\n- **Folder breakdown** — a pinned panel showing top-level folders +\n  note count per folder + open-todo count per folder.\n- **Recently-touched timeline** — a horizontal date strip plotting\n  notes by `updatedFromFrontmatter` / `ageDays`. Helps spot the\n  rhythm: daily notes consistent? project notes only when shipped?\n- **Longest notes** — list from `DATA.longestNotes` (the deep-dives,\n  the pinned essays). These often deserve their own re-read pass.\n- **Daily-note streak** (if the vault has a `Daily/` folder or notes\n  whose titles parse as ISO dates) — the cadence visualization,\n  longest run, last touched.\n\nDon't try to do all of these. Pick 2–4 beyond the required five,\nbased on what the data supports.\n\n## Interaction discipline\n\n- The tag / folder / state filter chips should **compose**, not\n  override each other. Clicking \"project\" + \"has-todos\" filters the\n  drill-down to project notes with open TODOs. The summary card\n  stays static; only the atlas / map adjusts.\n- Search box should match across title + path + tags + excerpt.\n  Highlight matches inline.\n- Clicking any callout (a stale note, an orphan, a top todo, a hub)\n  should jump to that note's expanded view in the drill-down.\n- Avoid editing UI. This is a read-only audit — no inline TODO\n  checkbox, no \"rename note\" action, no drag-to-reorganize. Surfaces,\n  not actions.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — graph collapses to a hub leaderboard on\n  narrow viewports, theme chips wrap, callouts stack.\n- Concept map renders inline SVG (no Cytoscape, no D3 imports). For\n  vaults over ~150 notes, render the list-graph hybrid instead of an\n  edge-heavy SVG.\n- Keep the page under ~1.5 MB inlined where possible. Most vaults\n  under 100 notes are <500 KB; only multi-thousand-note exports get\n  heavy.\n- \"Copy as Markdown\" of the analysis section — paste-ready into a\n  weekly review, a vault audit doc, or a status update.\n- Full-text search across the note list.\n- Drill-down note bodies render with a tiny inline markdown parser\n  (~80 lines covers headings, paragraphs, lists, blockquotes, code\n  fences, inline code, bold, italic, links, wikilinks rendered as\n  pill chips that jump to the linked note).\n\n## Data shape\n\nEvery knowledge-base parser feeds the same notes array plus\naggregations. Treat them generically.\n\n```ts\nDATA = {\n  kind: \"notion-export\" | \"obsidian-vault\" | \"markdown-folder\",\n  notes: [\n    {\n      id: \"projects/pricing v2\",\n      path: \"Projects/Pricing V2.md\",\n      filename: \"Pricing V2.md\",\n      title: \"Pricing V2\",\n      tags: [\"project\", \"pricing\"],\n      wordCount: 412,\n      headingCount: 8,\n      headings: [{ level: 1, text: \"Pricing V2\" }, ...],\n      outboundLinks: [\"projects/onboarding 2.0\", \"people/sarah kim\", ...],\n      inboundLinks: [\"index\", \"people/mira chen\", \"projects/series a\", ...],\n      outboundCount: 7,\n      inboundCount: 11,\n      todoOpenCount: 4,\n      todoTotalCount: 4,\n      todos: [{ line: \"Final copy pass with Alex Rivera by Friday\", done: false }, ...],\n      updatedFromFrontmatter: \"2026-05-07\",\n      ageDays: 2,\n      isStale: false,\n      isOrphan: false,\n      excerpt: \"Replacing the legacy three-tier page. Live A/B running since...\",\n      raw: \"---\\ntitle: Pricing V2\\n...\",\n      notionPageId: undefined\n    }\n  ],\n  topHubs:        [{ id, title, path, inboundCount, outboundCount }],\n  orphans:        [{ id, title, path, ageDays?, updatedFromFrontmatter? }],\n  stale:          [{ id, title, path, ageDays, updatedFromFrontmatter? }],\n  todoStats: {\n    openCount: 26,\n    totalCount: 28,\n    topNotesByOpenTodos: [{ id, title, path, openCount }]\n  },\n  topTodos:       [{ noteId, noteTitle, line }],\n  topTags:        [{ tag, count, notes: [\"id1\", \"id2\", ...] }],\n  themeClusters:  [{ name, tag?, noteIds, size }],\n  longestNotes:   [{ id, title, path, wordCount }],\n  graph: {\n    nodes: [{ id, title, size }],\n    edges: [{ from: id, to: id }]\n  },\n  totalOutboundLinks: 88,\n  totalInboundLinks: 88,\n  totalNotes: 14,\n  totalTags: 12,\n  meta: { sourceFile, sizeBytes, kind, ... }\n}\n```\n\nUse the pre-aggregated arrays directly. Do **not** re-walk the\n`notes` array to derive top-hubs / orphans / stale / theme clusters\non the client — the parser already did the math, and re-deriving on\nbig vaults kills the page.\n\n## Tone\n\nKnowledge-worker register. The output should read like a quarterly\nnotes audit or a \"second brain\" review, not a marketing dashboard.\n\"The Resources/ folder has two stale notes from late 2025 and one\ntrue orphan\" is a sentence; \"Stale: 2, Orphans: 1\" is a metric. Use\nsentences in the cards, metrics in the charts. Mono numerics. Direct.\n\n## Privacy / safety note (include in the page footer)\n\nNotion / Obsidian / personal-notes folders almost always contain\nreal names, customer references, internal strategy, and private\nthoughts. Add a small footer line:\n\n> *Generated locally — your vault never left your machine. The full\n> note bodies are embedded in this HTML and rendered in your\n> browser. For sharing, prefer an anonymized export.*\n\nFile v0.1.0:prompts/sources/_planning.md\n\n# Planning / project (shared)\n\nThis prompt is shared by every planning source: **calendar exports\n(`.ics`)**, **issue trackers (`.csv` from Linear, Jira, GitHub Issues,\nAsana, ClickUp, generic)**, and **Trello boards (`.json`)**. The parser\nalready normalized them into the same item shape — don't write\ndifferent rendering logic per format. Use `DATA.format` and `DATA.kind`\n(`calendar` vs `tasks`) to label the chrome and pick the time framing.\n\nThe output is **not a calendar viewer or a kanban board**. It's a\nplanning-shaped infographic that makes the user say *\"oh, here's where\nmy time is going / where this project is bottlenecked / what's been\nsitting\"* — with the raw items as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the planning contract. The page **must**\ninclude all of them, with the literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint; do not skip any of\nthem even on a small calendar or short backlog.\n\n1. **Time allocation map** — for calendar input, a visualization of\n   when time is being spent: a per-week or per-day density strip, a\n   day-of-week × hour heatmap of meeting density, OR a sparkline of\n   total scheduled hours per week. For task input, an equivalent\n   \"where work is concentrated\" view: items per assignee, items per\n   list / project / sprint, OR a stacked-bar of items by status per\n   owner. Drive it from `DATA.calendar.weeks` /\n   `DATA.calendar.busyHours` (calendar) or `DATA.tasks.assigneeCounts`\n   / `DATA.tasks.lanes` (tasks). Render inline SVG. The literal\n   heading \"Time allocation\" / \"Where time goes\" / \"Where work is\" or\n   equivalent must be visible.\n2. **Owner / status filters** — filter chips that toggle the drill-\n   down list. For calendar: by attendee / organizer and event status\n   (confirmed / cancelled / tentative). For tasks: by assignee, by\n   status (open / in progress / in review / done / blocked /\n   cancelled), by priority, by label. Drive them from\n   `DATA.calendar.topAttendees` (calendar) or\n   `DATA.tasks.assigneeCounts` + `DATA.tasks.statusBucketCounts` +\n   `DATA.tasks.priorityCounts` + `DATA.tasks.labelCounts` (tasks).\n   Render as toggle chips. Multi-select; clearing all chips shows\n   everything. Visible \"Owners\" and \"Status\" labels (or equivalents).\n3. **Stale / bottleneck callouts** — a labeled \"Stale\" or \"Bottlenecks\"\n   panel. For tasks: 4–8 cards from `DATA.tasks.staleItems` (items\n   open longer than the family's stale threshold) and\n   `DATA.tasks.bottlenecks` (owners with too much WIP or items sitting\n   too long). For calendar: cards for back-to-back blocks, overloaded\n   weeks, and meeting-free streaks pulled from\n   `DATA.calendar.backToBackBlocks` / `DATA.calendar.weeks` (with\n   `overloaded: true`) / `DATA.calendar.meetingFreeStreaks`. If the\n   data is too thin to surface anything, render a placeholder card\n   (\"Backlog is small enough that nothing has gone stale.\") rather\n   than omitting the section. The literal label \"Stale\" / \"Bottlenecks\"\n   / \"Overloaded weeks\" / \"Back-to-back blocks\" or equivalent must be\n   visible.\n4. **Roadmap / story-map / calendar view** — a time-bounded\n   visualization. For calendar: a week or month strip with each day's\n   events laid out (or a Gantt-like ribbon for items with both start\n   and end). For tasks: a swimlane / story-map / kanban-by-status\n   render of `items` grouped by `list` (Trello) or `project` /\n   `statusBucket` (issue trackers), with each lane showing item count\n   + an inline stack of cards. Items with `due` should plot on a\n   timeline ribbon at the top; items without due dates collapse into\n   their lane. Visible heading \"Roadmap\" / \"Calendar\" / \"Story map\" /\n   \"Board\" or equivalent.\n5. **Searchable item drill-down** — a collapsible \"Browse all N items\"\n   section with the full list (data inlined). Default to collapsed so\n   the analysis is the headline. Inside: a virtualized or paginated\n   table / list (calendars and backlogs can be 1000+ items),\n   full-text search across title + description, status + owner +\n   priority + label filter chips that compose with the search, click\n   a row to expand the structured fields (description, attendees,\n   labels, due, etc.). Highlight overdue / stale rows in the brand\n   error color (`var(--red)`); completed rows muted in\n   `var(--fg-muted)`. The drill-down is a hard requirement; it's how\n   trust gets re-earned after the inferred analysis.\n\nRender these five regardless of dataset size. They are the headline\nshape of the planning pack — without them, the output is incomplete.\n\n## What else to surface (pick what fits the dataset's shape)\n\nFor calendar inputs:\n\n- **Calendar card (top)** — date range, event count, total scheduled\n  hours, distinct participants, and a one-sentence read on the\n  calendar (\"12 days, 47 events, 38h scheduled — Tuesdays carry 60%\n  of meeting load and there are 4 back-to-back blocks of 3+ meetings\").\n- **Recurring series** — a pinned panel listing recurring events\n  (standups, weekly 1:1s) pulled from `DATA.calendar.recurring`. Each\n  with title + count + cadence chip. These are the \"always-on\" load\n  before anything else gets booked.\n- **Top attendees / organizers** — leaderboards from\n  `DATA.calendar.topAttendees` and `DATA.calendar.topOrganizers` —\n  who you spend the most time with, who books the most.\n- **Longest events** — list from `DATA.calendar.longestEvents` (the\n  90-min+ deep-work blocks, off-sites, board meetings) — useful as\n  \"where the big chunks went\".\n- **Day-of-week / hour heatmap** — a 7×24 matrix shaded by event\n  count (or total minutes) from `DATA.calendar.busyHours`. Prime real\n  estate for a founder calendar — shows whether mornings stay\n  protected, whether Fridays are clear, etc.\n\nFor task / issue / Trello inputs:\n\n- **Project card (top)** — total items, open / in-progress / done\n  split, overdue count, stale count, top assignees, and a one-\n  sentence read (\"38 issues across 4 lanes — 17 open, 8 stale (>3\n  weeks no movement), and 2 owners hold 60% of in-progress work\").\n- **Status flow** — a horizontal status bar: open → in-progress →\n  in-review → done with the count + share at each stop. Helps see\n  where work pools up.\n- **Priority distribution** — a chart of items by priority (P0 / P1\n  / P2 / P3) with overdue slices highlighted.\n- **Cycle time** — for issue trackers with `created_at` +\n  `updated_at` on completed items, surface\n  `DATA.tasks.cycleTime.medianDays` and `p95Days`. Often the most\n  honest signal of execution pace.\n- **Lane breakdown** — for Trello + tracker `project` columns,\n  swimlane chart of items per lane with done vs open shading.\n- **Overdue ribbon** — a timeline of overdue items grouped by week,\n  pulled from `DATA.tasks.overdueItems`.\n\nDon't try to do all of these. Pick 3–6 beyond the required five,\nbased on what the data supports.\n\n## Interaction discipline\n\n- The status / owner / priority / label chips should **compose**, not\n  override each other. Clicking \"John\" + \"in-progress\" filters the\n  drill-down to John's in-progress items. The summary card stays\n  static; only the table / map adjusts.\n- Search box should match across title + description + label + owner\n  + status. Highlight matches inline.\n- Every callout in the analysis (stale items, bottleneck owners,\n  overdue items, longest events, back-to-back blocks) should link\n  back into the drill-down — clicking jumps to that item's row,\n  expanded.\n- Avoid editing UI. This is a read-only infographic — no drag-and-\n  drop kanban, no checkbox-to-complete. Surfaces, not actions.\n\n## Always include\n\n- Light + dark mode (`prefers-color-scheme`).\n- Mobile-first responsive — analysis cards stack, time-allocation\n  visualization shrinks but stays readable, owner / status chips wrap,\n  the drill-down list goes single-column.\n- Charts render inline SVG (no Chart.js, no CDNs) for under ~2000\n  data points.\n- Keep the page under ~1 MB inlined where possible. Calendars and\n  backlogs are usually <300 KB; only Trello boards with full\n  `actions` history get heavy.\n- \"Copy as Markdown\" of the analysis section — paste-ready into a\n  weekly review doc, a sprint retro, or a calendar audit.\n- Full-text search across the item list; highlight matches in place.\n- Item drill-down rows render mono for IDs / dates / durations /\n  estimates; body type for titles / descriptions / labels.\n\n## Data shape\n\nEvery planning parser feeds the same `items` array plus a\nformat-specific aggregation block. Treat them generically.\n\n```ts\nDATA = {\n  kind: \"calendar\" | \"tasks\",\n  format: \"ics\" | \"trello\" | \"linear-csv\" | \"jira-csv\" | \"github-csv\" | \"task-csv\" | \"issue-csv\",\n  items: [\n    {\n      id: \"i_0001\",\n      title: \"Sprint review w/ engineering\",\n      kind: \"event\" | \"card\" | \"issue\",\n      // calendar-shaped fields\n      start?: \"2026-05-12 14:00\",\n      end?:   \"2026-05-12 15:00\",\n      startEpoch?: 1747058400000,\n      endEpoch?:   1747062000000,\n      durationMinutes?: 60,\n      allDay?: false,\n      organizer?: \"Alex Rivera\",\n      location?: \"Zoom\",\n      rrule?: \"FREQ=WEEKLY;BYDAY=TU\",\n      // tasks-shaped fields\n      status?: \"In Progress\" | \"Done\" | \"...\",\n      statusBucket?: \"open\" | \"in_progress\" | \"in_review\" | \"done\" | \"blocked\" | \"cancelled\" | \"unknown\",\n      priority?: \"P1\" | \"High\" | \"...\",\n      priorityRank?: 1,\n      due?: \"2026-05-20\",\n      ageDays?: 12,\n      staleDays?: 12,\n      isStale?: true,\n      isOverdue?: false,\n      isCompleted?: false,\n      // shared\n      assignees?: [\"Mira Chen\"],\n      owner?: \"Mira Chen\",\n      labels?: [\"frontend\", \"needs-design\"],\n      list?: \"In Progress\",\n      project?: \"Pricing Page V2\",\n      url?: \"https://linear.app/...\",\n      description?: \"...\"\n    }\n  ],\n  // calendar-only block (only when kind === \"calendar\")\n  calendar?: {\n    totalMinutes: 2280,\n    uniqueAttendees: 14,\n    weeks: [{ weekOf: \"2026-W19\", count: 23, totalMinutes: 1380, overloaded: true }],\n    busyHours: [{ day: \"Mon\", hourCounts: [0,0,...,1,2,3,...] }, ...],   // 7 entries\n    topAttendees: [{ name: \"Mira Chen\", count: 8, minutes: 480 }, ...],\n    topOrganizers: [{ name: \"Alex Rivera\", count: 12, minutes: 720 }, ...],\n    longestEvents: [{ id, title, minutes, start }],\n    recurring: [{ title: \"engineering standup\", count: 9, rrule }],\n    backToBackBlocks: [{ start, end, count, minutes }],\n    meetingFreeStreaks: [{ start, end, days }],\n    totals: { events: 47, cancelled: 2, minutes: 2280, distinctTitles: 31 }\n  },\n  // tasks-only block (only when kind === \"tasks\")\n  tasks?: {\n    statusCounts: { \"In Progress\": 8, \"Done\": 14, ... },              // raw status strings\n    statusBucketCounts: { open: 12, in_progress: 8, done: 14, ... },  // normalized buckets\n    priorityCounts: [{ priority: \"P0\", count: 1, rank: 0 }, ...],\n    assigneeCounts: [{ name, open, in_progress, done, total, oldestStaleDays }],\n    lanes: [{ name: \"In Progress\", count, openCount, doneCount }],\n    labelCounts: [{ label, count }],\n    staleItems: [{ id, title, ageDays, owner, status }],\n    overdueItems: [{ id, title, due, owner, status }],\n    bottlenecks: [{ name, openCount, oldestStaleDays }],\n    cycleTime: { medianDays: 4.2, p95Days: 18.0 },\n    totals: { items, open, inProgress, inReview, done, blocked, cancelled, overdue, stale }\n  },\n  meta: { sourceFile, sizeBytes, format, kind, ... }\n}\n```\n\nUse the pre-aggregated arrays directly. Do **not** re-derive\n`weeks` / `busyHours` / `assigneeCounts` / `staleItems` on the client\n— the parser already did the math, and walking the full items array\nfor analysis kills performance on big calendars / boards.\n\n## Tone\n\nOperator's-review register. The output should read like a weekly\nreview or a quarterly planning audit, not a marketing dashboard.\n\"Tuesdays carry 60% of the meeting load and Mira holds 5 of 8 in-\nprogress items\" is a sentence; \"Tuesdays: 60%, Mira: 5\" is a metric.\nUse sentences in the cards, metrics in the charts. Mono numerics.\nDirect, specific.\n\n## Privacy / safety note (include in the page footer)\n\nCalendars often contain real names, attendee email addresses, meeting\nlinks, and customer references. Trackers often contain internal\nroadmap, customer names, and sprint commitments. Add a small footer\nline:\n\n> *Generated locally — your calendar / project file never left your\n> machine. The full export is embedded in this HTML and rendered in\n> your browser. For sharing, prefer an anonymized export.*","readmeExcerpt":"Skill: Html Anything Owner: kelvin-clockless Summary: 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,... Tags: latest:0.1.0 Version history: v0.1.0 | 2026-05-12T02:46:35.988Z | auto Initial release of html-anything. - Turn any idea, file, folder, or URL into a polished live HTML page automatically. - Supports","codeSnippets":[],"executableExamples":[{"language":"ts","snippet":"DATA = {\n  kind: \"ai-chat-export\",\n  format: \"chatgpt-export\" | \"claude-chat-export\" | \"generic-conversations-json\" | \"ai-chat-log-md\",\n  platform: \"ChatGPT export\" | \"Claude chat export\" | \"Generic AI chat export\" | \"AI chat log\",\n  conversations: [\n    {\n      id: \"c_0001\",\n      title: \"Tax classification logic for 1099 contractors\",\n      createdEpoch: 1744449200000,\n      createdIso: \"2026-04-12\",\n      updatedEpoch: 1744452800000,\n      updatedIso: \"2026-04-12\",\n      messageCount: 14,\n      userCount: 7,\n      assistantCount: 7,\n      systemCount: 0,\n      toolCount: 0,\n      wordCount: 1840,\n      assistantWordCount: 1500,\n      userWordCount: 340,\n      codeBlockCount: 4,\n      hasCode: true,\n      models: [\"gpt-4o\", \"gpt-4-turbo\"],\n      topic: \"Tax classification logic for 1099 contractors\",\n      kind: \"code\",\n      firstUserPrompt: \"...\",\n      firstAssistantReply: \"...\",\n      lastUserText: \"...\",\n      lastUserEpoch: 1744452500000,\n      isUnresolved: false,\n      messages: [\n        { id: \"m_0001\", role: \"user\", text: \"...\", ts: \"2026-04-12 09:14\",\n          tsEpoch: 1744449240000, model: undefined, wordCount: 22,\n          charCount: 124, codeBlockCount: 0, hasCode: false }\n      ]\n    }\n  ],\n  weeklyHistogram: [{ weekOf: \"2026-W15\", count: 4 }],\n  monthlyHistogram: [{ month: \"2026-04\", count: 12 }],\n  hourCounts: number[24],\n  dowCounts: number[7],\n  topicClusters: [{ name: \"tax\", count: 3, conversationIds: [...] }],\n  kindBreakdown: [{ kind: \"code\", count: 7 }],\n  modelBreakdown: [{ model: \"gpt-4o\", count: 6, messageCount: 38 }],\n  longestConversations: [{ id, title, messageCount, wordCount }],\n  reusablePrompts: [{ id, conversationId, text, sharedKeywords, ts }],\n  importantAnswers: [{ id, conversationId, preview, charCount, ts }],\n  unresolvedThreads: [{ id, title, lastUserText, lastTs, gapDays, reason }],\n  totals: { conversations, messages, userMessages, assistantMessages,\n            codeBlocks, activeDays, withModel },\n  activeRange: \"2026-0"},{"language":"ts","snippet":"DATA = {\n  messages: [\n    {\n      id: \"m_0001\",\n      ts: \"2026-04-12 09:14:00\",      // sortable\n      date: \"2026-04-12\",\n      time: \"09:14:00\",\n      tsEpoch: 1744449240000,\n      sender: \"Mira Park\",\n      text: \"...\",\n      channel?: \"#product-eng\",       // platforms with a channel concept\n      threadId?: \"1744449200.000100\", // platform-native thread anchor\n      isThreadReply?: true,\n      replyCount?: 4,\n      replyToId?: \"m_0042\",           // for Telegram/Discord reply pointers\n      forwardedFrom?: \"Mira Park\",    // Telegram only\n      reactions?: [{ name: \"+1\", count: 2 }],\n      reactionCount?: 3,\n      mentionCount?: 1,\n      attachmentCount?: 1,\n      isMedia?: true,\n      isFromMe?: true                 // iMessage owner-flagged exports\n    }\n  ],\n  senders: [{ sender, count, firstTs, lastTs }],\n  messagesPerSender: { \"Mira Park\": 42 },\n  heatmap: [{ dow: 0..6, hour: 0..23, count }],   // pre-aggregated\n  volumeByDay: [{ date, count }],                  // pre-aggregated\n  threads: [{ id, parentSender, parentText, participants, messageCount, firstTs, lastTs, reactionCount }],\n  actionable: [{ id, ts, sender, text, signal: \"action\" | \"decision\" | \"question\" }],\n  topReactions: [{ name, count }],\n  dateRange: \"2026-04-12 → 2026-04-26\",\n  messageCount: 217,\n  senderCount: 9,\n  threadCount: 12,\n  reactionCount: 84,\n  mediaCount: 6,\n  platform: \"slack\" | \"discord\" | \"telegram\" | \"imessage\" | \"multi-sender-chat\",\n  channel?: \"#product-eng\",\n  guild?: \"Acme HQ\"                     // Discord guild name\n}"},{"language":"ts","snippet":"DATA = {\n  events: [\n    {\n      id: \"e_000001\",\n      ts: \"2026-04-12 09:14:00\",         // sortable\n      date: \"2026-04-12\",\n      time: \"09:14:00\",\n      tsEpoch: 1744449240000,\n      severity: \"error\" | \"warn\" | \"info\" | \"debug\" | \"trace\" | null,\n      category: \"auth\" | \"GET 200\" | \"payment\" | null,  // free-form\n      source: \"api-edge-01\" | \"192.0.2.42\" | \"auth-service\" | null,\n      message: \"...\",                    // human-readable summary\n      fields?: { user_id: \"u_42\", request_id: \"...\", duration_ms: 312 },\n      raw: \"...\"                         // original line, for drill-down\n    }\n  ],\n  timeBuckets: [\n    { bucket: \"2026-04-12T09:14\", label: \"09:14\", count: 142, errorCount: 3 }\n  ],\n  severityCounts: { error: 312, warn: 41, info: 18420, debug: 0 },\n  categoryCounts: [{ category: \"GET 200\", count: 14820 }, ...],\n  topMessages: [{ message: \"request completed\", count: 12410, share: 64.0 }, ...],\n  topSources: [{ source: \"192.0.2.42\", count: 1182, share: 6.1 }, ...],\n  topErrors: [{ message: \"DB connection refused\", count: 47, firstTs, lastTs }, ...],\n  outliers: [\n    { kind: \"burst\", label: \"Error spike 14:23\", detail: \"47 events in 1 min\", ts },\n    { kind: \"slow\", label: \"Slow GET /reports\", detail: \"p99 = 4.7s vs 220ms median\", ts },\n    { kind: \"rare\", label: \"503 from /checkout\", detail: \"first occurrence in 24h\", ts },\n    { kind: \"top-error\", label: \"DB connection refused\", detail: \"47×\", ts },\n    { kind: \"top-source\", label: \"192.0.2.42\", detail: \"6.1% of all events\", ts: null },\n    { kind: \"schema\", label: \"Field user_id missing\", detail: \"in 12.8% of events\", ts: null }\n  ],\n  schema?: [                                 // jsonl / ndjson only\n    { field: \"user_id\", type: \"string\", fillPct: 87.4, examples: [\"u_42\", \"u_7c1\"] },\n    ...\n  ],\n  format: \"jsonl\" | \"ndjson\" | \"access-log\" | \"error-log\" | \"syslog\" | \"app-log\",\n  timeRange: \"2026-04-12 09:14:00 → 2026-04-12 11:42:18\",\n  durationLabel: \"2h 28m\",\n  eventCount: 19420,\n  errorCoun"},{"language":"ts","snippet":"DATA = {\n  format: \"bank-transactions\" | \"invoices\" | \"quickbooks-report\",\n  subtype: \"bank\" | \"credit-card\" | \"invoices\" | \"receipts\" | \"quickbooks-gl\" | \"quickbooks-pl\" | \"xero-report\",\n  rows: [\n    {\n      id: \"tx_000001\",\n      date: \"2026-01-04\",\n      amount: -42.99,                      // signed: negative = outflow, positive = inflow\n      currency: \"USD\",\n      description: \"STRIPE TRANSFER\",\n      merchant: \"Stripe\" | null,           // normalized vendor when extractable\n      category: \"Software\" | null,\n      memo: \"monthly fee\" | null,\n      account: \"Checking 4421\" | null,\n      balance: 12840.50 | null,            // running balance if file had one\n      status: \"paid\" | \"outstanding\" | \"overdue\" | null,   // invoices\n      dueDate: \"2026-02-04\" | null,        // invoices\n      issuedDate: \"2026-01-04\" | null,     // invoices\n      customer: \"Northwind Co.\" | null,    // invoices\n      invoiceNumber: \"INV-1042\" | null,    // invoices\n      flags: [\"duplicate\"] | [],\n      raw: { ... }                         // original CSV row, for drill-down\n    }\n  ],\n  summary: {\n    rowCount: 87,\n    inflow: 48210.00,\n    outflow: 52840.00,\n    net: -4630.00,\n    currencySymbol: \"$\",\n    currencyCode: \"USD\",\n    period: \"2026-01-04 → 2026-01-31\",\n    durationLabel: \"27 days\",\n    distinctMerchants: 34,\n    distinctCategories: 12,\n    // invoices-only:\n    invoiced?: 72400.00,\n    paid?: 44800.00,\n    outstanding?: 27600.00,\n    overdue?: 8400.00,\n    invoiceCount?: 38,\n    customerCount?: 12,\n  },\n  categoryTotals: [\n    { category: \"Payroll\", inflow: 0, outflow: 18400.00, net: -18400.00, count: 4, share: 34.8 },\n    ...\n  ],\n  recurring: [\n    { name: \"Stripe\", cadence: \"monthly\", avgAmount: -42.99, count: 4, lastSeen: \"2026-01-15\", nextExpected: \"2026-02-15\", tag: \"subscription\" },\n    ...\n  ],\n  flags: [\n    { kind: \"duplicate\", label: \"Duplicate Stripe charge\", detail: \"$42.99 on 2026-01-15 and 2026-01-15\", rowIds: [\"tx_42\",\"tx_43\"] },\n    { kind: \"outlier-a"},{"language":"text","snippet":"const avgLat = (bbox.minLat + bbox.maxLat) / 2\n  const lonScale = Math.cos(avgLat * Math.PI / 180)\n  const W = 1000  // matches polyline viewBox\n  const sx = W / ((bbox.maxLon - bbox.minLon) * lonScale)\n  const sy = H / (bbox.maxLat - bbox.minLat)\n  const x = (lon - bbox.minLon) * lonScale * sx\n  const y = (bbox.maxLat - lat) * sy"},{"language":"ts","snippet":"DATA = {\n  kind: \"route\" | \"itinerary\" | \"location-history\",\n  format: \"gpx\" | \"kml\" | \"itinerary-csv\" | \"location-history-json\" | \"location-history-csv\",\n\n  // route only (GPX / KML)\n  metadata?: { name?: string; time?: string; creator?: string },\n  activityKind?: \"run\" | \"ride\" | \"walk\" | \"hike\" | \"trip\" | \"kml-trip\",\n  isWorkout?: boolean,\n  tracks?: [\n    {\n      name?: \"Morning Run\",\n      pointCount: 320,\n      bbox: { minLat, maxLat, minLon, maxLon },\n      stats: {\n        pointCount, distanceKm, elapsedSec, movingSec, pausedSec,\n        elevationGainM, elevationLossM, minEleM, maxEleM,\n        avgPaceSecPerKm, movingPaceSecPerKm, maxSpeedKmh, avgSpeedKmh,\n        startTime, endTime,\n      },\n      polyline: 'viewBox=\"0 0 1000 480\" points=\"0.0,0.0 1.2,2.4 ...\"',\n      splits: [{ km: 1, durationSec, paceSecPerKm, elevationGainM, ... }],\n      elevationProfile: [{ km: 0.05, ele: 12.4 }, ...],\n      paceProfile?: [{ km: 0.20, paceSecPerKm: 348 }, ...],\n      pauses?: [{ atKm, durationSec, lat, lon, time? }],\n    }\n  ],\n  waypoints?: [{ lat, lon, ele?, name?, description?, time? }],\n  totals?: { pointCount, distanceKm, elapsedSec?, movingSec?,\n              elevationGainM?, maxSpeedKmh?, startTime?, endTime?,\n              trackCount },\n  bbox?: { minLat, maxLat, minLon, maxLon },\n\n  // itinerary only\n  items?: [{ id, date?, dateEpoch?, dayNumber?, time?, location?,\n             city?, country?, type?, title, notes?, cost?, currency?,\n             durationHours? }],\n  days?: [{ date, dayNumber?, items: [...] }],\n  conflicts?: [{ date?, items: [...] }],\n  cities?: [{ name, count }],\n  countries?: [{ name, count }],\n  types?: [{ name, count }],\n  totals?: { items, days, cities, countries, totalCost?, costItems },\n\n  // location-history only\n  points?: [{ t, tEpoch, lat, lon, accuracy?, activity? }],\n  places?: [{ key, lat, lon, visits, minutes }],\n  topPlaces?: [...],          // first 100 places by dwell minutes\n  days?: [{ date, pointCount, uniquePlaces }],\n  ho"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: html-anything\ndescription: 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.\nversion: 0.1.0\nhomepage: https://github.com/clockless-org/html-anything\nwhen_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.\nmetadata:\n  openclaw:\n    emoji: \"🧩\"\n    homepage: https://github.com/clockless-org/html-anything\n---\n\n# html-anything\n\nYou are the `html-anything` skill.\n\nYour job is to turn **an idea, file, folder, URL, or exported dataset**\ninto a polished live HTML page the user can open, share, or publish.\n\nDo not present this as a parser, CLI, or internal pipeline. The user only\nneeds to understand:\n\n- **Input**: an idea, file, folder, URL, or source they want help exporting.\n- **Output**: a live HTML page, usually `output.html`, sometimes with an\n  `assets/` folder when generated images or local media are useful.\n\nEverything else is your responsibility: source understanding, export\nguidance, style choice, page design, asset generation, implementation,\nbrowser verification, and final handoff.\n\nTwo constraints are non-negotiable:\n\n1. **Style fidelity**: if a style is based on a reference design, reproduce\n   the reference's layout system, first viewport, component vocabulary,\n   typography roles, color/surface language, and motion grammar. Do not merely\n   borrow the mood.\n2. **Final HTML compliance**: the delivered HTML must visibly and structurally\n   follow the selected style, not a generic html-anything report with different\n   colors.\n\n## User-Facing Promise\n\nAccept requests like:\n\n- \"Create an interactive teaching site about the solar system.\"\n- \"Turn my Amazon order history into a personal spending atlas.\"\n- \"Make this WhatsApp export into a relationship rhythm report.\"\n- \"Turn this transcript into a meeting scorecard.\"\n- \"Make this CSV into a dashboard I can share.\"\n- \"Use this GitHub repo URL and make a browsable architecture page.\"\n\nReturn a working HTML artifact, not a proposal.\n\n## Inputs\n\nHandle these input modes automatically:\n\n| Input mode | What to do |\n|---|---|\n| Idea / brief | Expand the brief into a concrete content plan, choose an auto style, create the HTML, and generate assets when useful. |\n| Local file | Inspect the file, sample it if large, identify the source type, and create the page. |\n| Folder | Inspect structure and representative files, then create an atlas / audit / browser for the folder. |\n| URL | Fetch or inspect the URL when possible, then create a page from the page/repo/article content. |\n| Export request | If the user names a platform"},{"path":"prompts/styles/README.md","content":"# Style Catalog\n\nThese style prompts define the reusable **design systems + layout systems** for\nhtml-anything. Source prompts answer \"what is in this input?\" Style prompts\nanswer \"what system should shape the HTML experience?\"\n\nStyles are not skins. A style must change the page shell, first viewport,\ncomponent vocabulary, interaction model, density, chart grammar, and voice.\nThe shared contract is [`_system.md`](./_system.md). The compact catalog is\n[`catalog.json`](./catalog.json): it keeps each style's routing triggers,\nsource fit, example, preview, required primitives, and avoid rules in one\nmachine-checkable place.\n\nThe default is `auto`: the agent picks a style from the request and source.\n\n## Current Styles\n\n| Style | Use when | Core shape |\n|---|---|---|\n| `default` | The input does not clearly fit a specialized style | Clean live page with strong summary, useful sections, practical drill-down |\n| `teaching` | Tutorial, lesson, \"teach me\", interactive explainers, course-like pages | Visual stage, step rail, try-it controls, concept cards, check-yourself, recap |\n| `interactive-learning` | App-like object/system studios, anatomy/architecture/spec exploration, manipulable learning models | Learning Studio with entity rail, central interactive stage, live inspector, layer/mode controls, comparison bench |\n| `relationship` | 1:1 chats and intimate message exports | Aggregate-first relationship rhythm report with anonymized evidence |\n| `living-essay` | Reflective essays, Kindle highlights, idea notes, and concept-heavy reading archives | Mycelium writing environment with a vertical question capsule, spore words, living SVG threads, and quiet appendix |\n| `dashboard` | Operational, tabular, finance, admin, log, planning data | Dense KPIs, charts, filters, flags, searchable table |\n| `soft-saas` | Support inboxes, email campaigns, onboarding, customer-success queues, and lightweight SaaS metrics | Airy SaaS app canvas with profile/source card, central metric bloom, campaign panels, leaderboard, and activity strip |\n| `kinetic-scoreboard` | Multi-participant activity streams, team chats, work races, ranked contributors | Full-viewport championship lanes with kinetic bodies, live ranks, telemetry, and linked evidence pits |\n| `timeline-story` | Personal histories — chronological (orders, listening, health) and topical (Notion / Obsidian vaults) | Scroll-driven story with timeline spine, chapters, rhythm strip, drawer |\n| `map-atlas` | Places, routes, trips, rideshare, location/photo geodata | Spatial atlas with map/route stage, place drawer, filters, waypoint browser |\n| `paper-trail` | Explicit tactile/printed-collateral requests: itineraries, hotel folios, receipts, tickets, reservation bundles | Artifact desk with folio tabs, receipt tape, stamp callouts, source drawer |\n| `network-map` | Personal/professional networks, senders, contacts, communities, payments | Relationship graph with entity inspector, clusters, hubs, linked records |\n| `docu"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7c2zapkmjyy4skhma3fx816s86jcw8\",\n  \"slug\": \"html-anything\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1778553995988\n}"},{"path":"prompts/sources/_ai_chat_export.md","content":"# AI chat export (shared)\n\nThis prompt is shared by every \"everyday AI chat history\" source in\nthe pack: **ChatGPT** (`conversations.json`), **Claude** chat /\nproject export-style JSON, the **generic** `{ conversations: [...] }`\nshape, and plain **markdown / text** \"User: / Assistant:\" logs.\n\nThe output is **not a chat viewer**. It's a one-page **personal AI\nwork-memory atlas** that makes the user say *\"oh, this is what I've\nbeen using AI for\"* — what topics they keep coming back to, which\nconversations contain real decisions / code / prompts they could\nreuse, what's still unanswered, and how their AI work has evolved\nover time — with the raw conversation log as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese six sections form the AI-chat-export contract. The page **must**\ninclude all of them, with literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint — even on a small\nsample, render every section (with empty-state copy if the data\ngenuinely doesn't support it).\n\n1. **Overview cards** (top of page) — at minimum:\n   - conversation count, total messages, active date range,\n     active days as a fraction of the date range\n   - a one-sentence read on the user's AI usage shape\n     (\"you used AI mostly for code in 2026-Q1 — 68% of your\n     longest threads include code blocks\")\n   - the **kind** breakdown (`DATA.kindBreakdown`): code / writing\n     / planning / research / chat / other, as a small bar or\n     chip cloud\n   - the **model** breakdown if the source carries model info\n     (`DATA.modelBreakdown`)\n2. **Activity timeline** — render `DATA.weeklyHistogram` (or\n   `DATA.monthlyHistogram` if the dataset spans many months) as a\n   bar chart or sparkline. Highlight bursts (\"April 2026 carried\n   38% of all your conversations — what was happening?\") and\n   quiet weeks. Visible heading \"Timeline\" or equivalent.\n3. **Topic clusters** — drive from `DATA.topicClusters` (already\n   computed as keyword roll-ups). 4–10 clusters as a chip cloud\n   or small bar chart. Each chip / bar should let the user\n   filter the conversation index to that cluster. Visible\n   \"Topics\" heading. **Label clusters as heuristic** — the\n   parser used keyword roll-up, not real topic modeling.\n4. **Reusable prompts & important answers** — two side-by-side\n   panels (or stacked on mobile):\n   - **Reusable prompts** — `DATA.reusablePrompts` (user prompts\n     that share keywords with prompts from other conversations,\n     i.e. things the user has asked variations of). Each card\n     shows the prompt text, the conversation it came from, and\n     a \"copy prompt\" button. Empty-state line if there are\n     fewer than 3 candidates.\n   - **Important answers** — `DATA.importantAnswers` (the\n     longest single assistant reply per conversation). Each\n     card shows the conversation title, a 360-char preview,\n     and a \"jump to conversation\" link. These are the chunks\n     of advice / code / writing the user might want to"},{"path":"prompts/sources/_chat.md","content":"# Multi-sender chat (shared)\n\nThis prompt is shared by every multi-sender chat source in the pack:\n**Slack**, **Discord**, **Telegram**, **iMessage**, and the generic\nmulti-sender CSV. WhatsApp has its own 1:1-relationship-shaped prompt\nand is **not** part of this family — don't borrow framing across.\n\nThe output is **not a chat viewer**. It's a one-page infographic that\nmakes the user say *\"oh, here's what's actually going on in this\nchannel\"* — who carries it, when it lights up, what got decided, what's\nstill unanswered, and which threads were the real ones — with the raw\nlog as drill-down.\n\n## Required sections (must always render — non-negotiable)\n\nThese five sections form the chat-pack contract. The page **must**\ninclude all of them, with the literal section labels visible somewhere\nin the rendered DOM. This is a hard constraint; do not skip any of them\neven on a small or single-thread sample.\n\n1. **Activity heatmap** — a 7×24 day-of-week × hour-of-day grid (or a\n   responsive equivalent that preserves both axes), intensity by\n   message count. Drive it from `DATA.heatmap` (already aggregated as\n   `[{ dow, hour, count }]` — `dow` is `0=Sun..6=Sat` in UTC). Render\n   inline SVG. Visible heading \"Activity heatmap\" or equivalent.\n2. **Contributor leaderboard** — top senders ranked by message count,\n   each row showing name, count, and that sender's share of total\n   activity. Drive it from `DATA.senders` (already sorted descending).\n   Visible heading \"Contributors\" or \"Leaderboard\".\n3. **Decisions & action items** — a callout panel listing what got\n   committed to and what was decided. Drive it from `DATA.actionable`\n   (already classified `signal: \"action\" | \"decision\" | \"question\"`)\n   plus anything else you can pull from the sample. Group by signal so\n   \"Decisions\" / \"Action items\" / \"Open questions\" each get a sub-panel\n   with the original message, sender, and timestamp. If a sub-list is\n   empty, render an empty-state line (\"No decisions surfaced — this\n   channel is mostly chatter.\") rather than omitting the section. The\n   literal labels \"Decisions\" and \"Action items\" must be visible.\n4. **Topic clusters** — pick 4–8 themes from the sample (planning,\n   incidents, hiring, product, off-topic, …) and show a small bar\n   chart or chip cloud of message volume per theme. Theme labels are\n   the LLM's call from the sample. If the sample is too thin to\n   support clustering (< 20 messages), render a placeholder card with\n   the top 8 most-frequent non-stopword terms. Visible \"Topics\" label.\n5. **Searchable log drill-down** — a collapsible \"Browse all N\n   messages\" section with the full thread (data inlined). Default to\n   collapsed so the analysis is the headline. Inside: bubble-style\n   timeline grouped by day, sender filter chips, full-text search,\n   reaction badges where present, jump-to-message links from the\n   decisions / leaderboard rows. The drill-down is a hard requirement;\n   it's how trust gets re-earned after the inferred anal"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"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,... Skill: Html Anything Owner: kelvin-clockless Summary: 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,... Tags: latest:0.1.0 Version history: v0.1.0 | 2026-05-12T02:46:35.988Z | auto Initial release of html-anything. - Turn any idea, file, folder, or URL into a polished live HTML page automatically. - Supports","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":2134,"uniquenessScore":49,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T05:05:00.862Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:35:59.158Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}