skills/html-tools/SKILL.md
Build single-file HTML tools — self-contained HTML+JS+CSS applications that solve a specific problem without a build step. Use this skill whenever the user asks to build a utility, converter, viewer, debugger, or any small interactive web tool. Also trigger when the user says "build me a tool that...", "make a quick app for...", "I need a single-file HTML page that...", or wants to create something that could be hosted as a static file. This skill is specifically for practical, utility-focused tools (not landing pages, portfolios, or marketing sites — use frontend-design for those).
npx skillsauth add nbbaier/agent-skills html-toolsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Build single-file HTML applications that combine HTML, JavaScript, and CSS into one portable file. These tools solve specific problems, load instantly, require no build step, and can be hosted anywhere as static files.
This skill codifies patterns from building 150+ such tools. The goal is always: one file, no build step, no framework overhead, maximum utility.
Use this when the user wants a utility or tool — something interactive that transforms, displays, debugs, converts, or processes data. Common types:
If the user wants a polished marketing page or portfolio, use the frontend-design skill instead.
Single file: All HTML, JS, and CSS in one .html file. Trivially copyable, hostable, and shareable.
No React, no build step: Avoid React (JSX requires transpilation). Use vanilla JS or lightweight CDN libraries. If the user specifically requests React, explain the tradeoff and offer both options.
CDN dependencies only: Load from cdnjs.cloudflare.com or cdn.jsdelivr.net with pinned versions. Fewer dependencies is better, but don't reinvent well-solved problems.
Keep it small: A few hundred lines is ideal. At this size, the code is easy to understand, easy to rewrite, and easy to hand to another LLM for modification.
Copy-paste as primary I/O: Many great tools accept pasted input, transform it, and offer a "Copy to clipboard" button for the output. Default to this interaction pattern unless the problem calls for something else.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>[Tool Name]</title>
<!-- CDN dependencies with pinned versions -->
<style>
/* All CSS inline */
</style>
</head>
<body>
<!-- Tool UI -->
<script>
/* All JS inline */
</script>
</body>
</html>
Always include the viewport meta tag for mobile. Use semantic HTML where practical.
When building a tool, consider which patterns from references/patterns.md apply. Here is a quick decision framework:
How does data get in?
How does data get out?
Does the tool need to remember anything?
Does the tool need external data?
Does the tool need heavy computation?
Read references/patterns.md for detailed code examples and implementation guidance for each pattern.
When building an HTML tool, verify:
.html file with inline CSS and JS<title> tagHTML tools are utilities, not showcases. Prioritize clarity and function over visual flair. A clean sans-serif font, sensible spacing, and clear visual hierarchy are enough. Don't over-design.
That said, the tool should look intentional, not broken. Use a system font stack, consistent padding, and visible interactive affordances (buttons look like buttons, inputs look like inputs).
When the user has an existing HTML tool and wants to extend it or build something similar, read the existing tool's source first. Working tools are the best documentation for browser API patterns, library usage, and interaction flows. Use them as a starting point rather than building from scratch.
development
Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays Applies principles: data-ink ratio, chartjunk elimination, graphical integrity, lie factor, small multiples, and data density.
tools
Manage Val Town projects using the vt CLI. Use when working with Vals (Val Town serverless functions), syncing code to Val Town, creating HTTP endpoints, streaming logs, or managing Val Town branches. Triggers on tasks involving Val Town development, val creation/editing, or when user mentions "vt", "val town", or "vals".
development
Guidelines for proper React useEffect usage and avoiding unnecessary Effects. Use when writing, reviewing, or refactoring React components that use useEffect, useState, or handle side effects. Triggers on tasks involving React Effects, derived state, event handlers, data fetching, or component synchronization.
testing
Audit and harden Node.js projects against npm supply chain attacks — compromised maintainer accounts, malicious package versions, and install-script payloads. Use when reviewing or setting up package.json, lockfiles, .npmrc, Dockerfile, or CI workflows for security; when the user mentions npm security, supply chain attacks, `npm audit`, lockfile policy, install scripts, or min-release-age; also when the user wants to check whether their dependencies are safe, or recover from a suspected compromise.