html-data-explorer

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: html-data-explorer
description: Build HTML data explorers for CSV, JSON, log, and event data — filterable tables, faceted search, inline charts, timeline scrubbing, A/B test result dashboards. Use whenever the user has a dataset to explore, browse, filter, chart, facet, or analyze — especially for ad-hoc analysis where opening a heavy BI tool is overkill. Reach for this when the user pastes data, mentions a CSV/JSON/log file, or asks to "look at" or "analyze" a dataset. Always runs a secret-redaction pass before embedding data — credential-shaped values (API keys, tokens, cookies, passwords) are replaced with placeholders unless the user explicitly opts in to embedding them.
metadata:
  version: "1.2.1"
---

# HTML Data Explorer

For ad-hoc data exploration — a CSV someone pasted, a JSON dump from an API, a log file from production — opening Tableau or even a Jupyter notebook is overkill. A self-contained HTML file with the data baked in, a filterable table, a few charts, and faceted search is faster to build and faster to share.

## When to use this skill

- "Look at / analyze / explore this CSV / JSON / log data"
- "Show me [a chart, filter, breakdown] of this data"
- "Build me a quick dashboard for X"
- "Help me find the rows where Y"
- Pasted tabular data with an implicit "do something useful with this"
- Log files where the question is "what happened around time T"

## Output requirements

Data baked into the file as a JS object/array — no separate file to load, no fetch call. Embed the data only after the mandatory secret-redaction pass below — the artifact is built to be shared, so everything baked in travels with it, including rows and columns the current filter hides. Filtering and charting happens entirely in the browser. Pre-aggregated views update live as filters apply.

If the dataset is large enough that inlining is awkward (>~5MB), still inline it but warn the user about file size — and that the file carries the full dataset, including filtered-out rows; otherwise the artifact loses its "just send the link" superpower.

## Redact secrets before embedding (mandatory)

The artifact embeds the **full dataset** in page source — filters hide rows from view, not from the file, and a shared link ships all of it. Logs and API dumps routinely carry Authorization headers, cookies, and keys. For anything beyond a trivially small dataset, run the scan programmatically — a script/regex pass over every row — never by reading or sampling rows manually; a sample-based scan misses the one row that matters. Before baking data in:

1. **Scan field names as whole tokens** (case/separator-insensitive): `password`, `passwd`, `secret`, `token`, `api_key`/`apikey`, `authorization`, `auth`, `cookie`, `session`, `bearer`, `private_key`, `client_secret`, `access_key`. Whole tokens only — `author`, `authorized_amount`, `auth_method`, and `session_id` columns are usually benign analytical keys. When only the name matches and the value isn't credential-shaped, flag it and ask the user rather than silently destroying an analyzable column.
2. **Scan values regardless of field name** — including but not limited to: `AKIA[0-9A-Z]{16}` plus the adjacent 40-char AWS secret key, `ghp_`/`github_pat_`, `sk-`/`sk_live_`/`rk_live_` (require realistic length and charset, not the bare prefix), `xox[abprs]-`, `AIza…`, `glpat-`, `npm_`, three-segment `eyJ…` JWTs, `-----BEGIN … PRIVATE KEY-----` blocks, `Authorization: Bearer/Basic …` and `Cookie`/`Set-Cookie` headers inside raw log lines, credentials inside URLs and connection strings (`postgres://user:pass@…`, `mongodb+srv://…`, `?api_key=`, `?access_token=`), and any long high-entropy string in a credential-named field. Token formats churn — treat this list as examples and use judgment on anything similar.
3. **Replace each hit with a stable indexed placeholder** — `[REDACTED:aws-key#1]`, `[REDACTED:jwt#2]` — same original value maps to the same placeholder, distinct values to distinct placehol