HTML Testing Checklist

"Please verify this works" usually arrives as a vague worry and leaves as a vague "looks fine". This skill turns it into an artifact: a thorough, walkable test plan — organized into the end-to-end flows a tester actually performs, each step carrying the exact command to run or input to type, what passing looks like, and a tick that advances a real progress bar. When the tester finishes (or gives up for the day), one Submit sends every step's pass/fail/blocked state and notes back to you, so failures become your next work queue instead of a Slack paragraph.

When to use this skill

• "Help me test / QA / verify this change (feature, PR, release, migration, bug-fix batch)"
• "What should I check before shipping?"
• "Write me a test plan / verification checklist / regression checklist"
• "I fixed these N bugs — how do I confirm they're all really fixed?"
• Handing work to a tester, reviewer, or teammate who needs to verify results without reverse-engineering the diff

If the user wants to edit or triage data rather than verify software, use html-throwaway-editor. If they want automated tests written, write tests — this skill is for the human verification pass that automated tests don't cover.

Tracker-backed checklists — bug lists are a natural input

A QA queue in an issue tracker is this skill at its best: "test the bugs marked check-QA on the board" should become a smart, two-way HTML checklist rendered from the tracker's real items, not a markdown dump of titles. The round trip runs through the same html-skills-listen receiver as everything else — the page never touches the tracker's API; you hold the credentials and do the writes.