f-labs-io/agent-html-skills/html-throwaway-editor

HTML Throwaway Editor

When describing what you want to do is harder than just doing it, build a one-off editor. Not a product. Not a reusable tool. A single HTML file purpose-built for this one piece of data, with one Submit button at the end that sends the result back to the agent.

<!-- block:preflight -->

Pre-flight — run BEFORE writing the artifact

Invoke html-skills:html-skills-listen (Skill tool) first; it is idempotent. If it returns a URL, inject it verbatim as window.__CLAUDE_SUBMIT_URL__ in the HTML you are about to write, ?t= query string included (a local, single-session loopback handshake — not a credential). If it reported web/sandbox mode, leave that line out; submitToClaude then falls back to clipboard mode. <!-- /block:preflight -->

When to use this skill

• "I need to reprioritize / reorder / triage these N things"
• "Help me edit / curate / annotate / tag this dataset"
• "I want to tune / pick / configure these values" (where the values aren't simple text)
• "Build me a quick editor for X"
• Any time the user describes a manipulation that would be painful to do in chat but easy with a UI

Output requirements

Pre-populate with the actual data the user provided (after the secrets pass below) — never make them paste it again. End with one Submit button that sends the edited structure back in the standard envelope.

The Submit button is non-negotiable. An editor without it is a dead-end; "throwaway" means the result lives outside the artifact, not inside it.

Secrets are never embedded

Before pre-populating, scan the input for secret-shaped values. Mask anything that matches:

• Key names matching /(key|secret|token|passw|credential|private|auth|dsn|connection[_-]?string)/i.
• Known prefixes: AKIA, ghp_/gho_, sk-, xox, AIza, eyJ-prefixed JWTs, PEM PRIVATE KEY blocks.
• URLs with userinfo — scheme://user:pass@host connection strings.
• Secret-bearing sources: if the source file is secret-bearing by convention (.env, *credentials*, *secret*, .npmrc, key/PEM files), treat every value in it as secret by default — don't rely on the regexes alone.
• High-entropy strings ≥ 20 chars — in config/env-shaped inputs (Pattern B) only; treat a bare entropy hit as "mask unless the user confirms it's not a secret". Don't apply this heuristic to dataset or annotation rows (Patterns D/E), where hashes, UUIDs, and base64 are legitimate payload.

For each match, replace the value with a masked preview (•••• + last 4 chars when the value is ≥ 12 chars; full mask otherwise) and a stable reference id, e.g. {{SECRET:STRIPE_API_KEY}}. Render those fields read-only with a "secret — value withheld" badge. The real value must never appear in the HTML source, the DOM, the live state preview, browser storage, or the submitToClaude payload — the payload carries key names and reference ids only. After the user submits, re-join real values from the original source on the agent side when applying the result.

If the user needs to change a secret value, don't let them type the new one into the artifact — it would round-trip through the DOM and clipboard. Submit a rotation marker instead (e.g. {"rotate": ["STRIPE_API_KEY"]}) and collect the new value directly at the source after submit.

Two foundation carve-outs apply whenever an editor carries masked-secret or config-derived data — the secrets rule wins over the foundation list:

• It is single-user: don't link-share it or treat it as a phone-openable hand-off, even though it's mobile-responsive.
• It overrides "Filename is part of the artifact": if the source is gitignored or a dotfile, write the artifact to $TMPDIR, or verify the chosen path passes git check-ignore first (prefer .git/info/exclude over editing the user's tracked .gitignore). Delete the file once the submit lands — "throwaway" includes the file.

Pass { redactSecrets: true } as the second argument to submitToClaude whenever the scan above matched anything — in any pattern, not just config editors — and always for config/env editors (Pattern B), even on a clean scan. The shared handler then strips high-confidence credential patterns from the payload and shows a visible notice. Defense-in-depth only: with the masking above in place, there is nothing for it to find.

Core structure

1. Header — what this editor is for, and a link/note showing when work is unsaved
2. Editing surface — the actual UI
3. Live state preview (optional but useful) — a sidebar or footer showing the current state as JSON
4. Submit — one button that sends the current state back

Patterns

Pattern A: Drag-and-drop board (Kanban-style)

For reordering, triaging, or bucketing. Columns like "Now / Next / Later / Cut" or "Approved / Rejected / Unsure". Cards are draggable. Counter per column. Pre-sort intelligently if you can guess the user's intent.

Submit data: ordered list per column with a one-line rationale field per item.

Pattern B: Form-based config editor

For structured config (feature flags, env vars, JSON/YAML with constraints). Group fields by area. Show dependencies between fields — warn if enabling A requires B that's currently off. Highlight changes from the original. Submit only the diff, not the whole config.

.env files and config routinely carry credentials — apply ### Secrets are never embedded: show key names with masked values, let the user edit flags, toggles, and non-secret values, and make the submitted diff reference keys, never secret values. Pass { redactSecrets: true } to submitToClaude for this pattern.

Pattern C: Side-by-side prompt/template editor

Editable input on the left, live preview on the right with the variables filled in. Multiple sample inputs to switch between. Token/char counter. Highlight variable slots in the input.

Pattern D: Dataset curator

For approve/reject workflows on rows. Big yes/no buttons or keyboard shortcuts (j/k, y/n). Filtered list of remaining items. Show counts: "37 to review, 12 approved, 4 rejected". Submit the labeled set.

Pattern E: Annotation tool

For document/transcript/diff annotation. Click a span to add a note. Tags or color categories. Submit annotations as a structured list with source quotes.

Pattern F: Value picker

For things painful to express in text — colors, easing curves, crop regions, cron schedules, regexes. Visual picker UI with live preview of what the value does. Submit the chosen value; the agent formats it (CSS, code, etc.) when applying.

If the user wants to explore a parameter space (sweep through values, compare A/B, find the sweet spot through tuning), use html-interactive-playground instead. This pattern is for picking one value with a visual control; the playground is for tuning behavior across many values.

Submit shape

data carries the structured result, e.g. { "ordered": ["ENG-101", "ENG-87"], "rejected": ["ENG-203"], "rationale": { "ENG-203": "deprioritized" } }. Any natural-language hand-off ("Move ENG-101 and ENG-87 to Now — most blocking") is derived by the agent from that envelope after submit; the page never offers a second "copy as prompt" affordance.

Keyboard ergonomics

If the user is going to do this for more than a few items, add keyboard shortcuts. Common ones:

• j / k — next / previous item
• 1–9 — assign to bucket N
• enter — confirm
• cmd+enter or the visible Submit button — submit

Show the shortcuts in a small "?" panel.

Anti-patterns

• Treating browser storage as the deliverable. The foundation allows localStorage under the artifact's key prefix as a guard against reloads, but Submit is the persistence layer that matters — and masked secrets never go into storage.
• A "Save" button that doesn't do anything. The one button is Submit.
• Building generic infrastructure. This is one-shot. Hardcode for the data you have.
• Asking the user to enter the data. They already gave it to you — pre-populate.
• Embedding API keys, tokens, passwords, connection strings, or any credential verbatim in the artifact or in the submitToClaude payload. Mask the value and submit a key reference (see ### Secrets are never embedded); the agent re-joins real values from the source after submit.
• Leaving a data-bearing editor somewhere it can be committed. If the source is gitignored or a dotfile, default the artifact to $TMPDIR or a git check-ignore-verified path, and delete it once the submit lands — "throwaway" includes the file.

Example prompt

I need to reprioritize these 30 Linear tickets [pasted list]. Make me an HTML file with each ticket as a draggable card across Now / Next / Later / Cut columns. Pre-sort them by your best guess. End with a Submit button that sends the final ordering with a one-line rationale per bucket back to you.

Output: HTML file with four columns, 30 pre-sorted draggable cards, counters per column, and a Submit-to-Claude button at the bottom.

Submit wire-up (see ## Submit pipeline below): inline ${CLAUDE_PLUGIN_ROOT}/assets/submit-handler.js, then call:

submitToClaude({
  skill: 'html-throwaway-editor',
  kind: 'kanban-reorder',
  data: { now: [...ids], next: [...ids], later: [...ids], cut: [...ids], rationale: { 'ENG-101': 'most blocking', ... } },
  version: 1,
});

<!-- block:foundation -->

HTML output foundation

These defaults apply to every artifact this skill produces. A rule above wins on conflict; otherwise they are non-negotiable.