shipshapelisted

Tool-gated front-end QA and pre-deploy hardening for websites and landing pages. Use this whenever the user wants to test, QA, audit, harden, or "find the bugs" in a website, web app, or landing page — accessibility, performance, SEO, broken links, HTML validity, security headers, secrets, XSS sinks, responsive/cross-browser issues, or Lighthouse/Core-Web-Vitals scores. Trigger it for phrases like "QA this site", "is my landing page production-ready", "check accessibility", "run Lighthouse", "audit before launch", "find a11y violations", "harden the frontend", even when no specific tool is named. Runs real tools (Lighthouse, axe, Playwright, semgrep, gitleaks, link + HTML checkers) against a production build and proves each finding with tool output. Front-end scope only — not backend/API/smart-contract testing.
sasonov/shipshape · ★ 0 · Web & Frontend · score 73

Install: claude install-skill sasonov/shipshape

# ShipShape — Front-End QA & Hardening This skill tests a website the way a careful release engineer would: it runs real tools against a **production build**, collects what they actually report, and fixes issues in small reviewable batches — never claiming anything is fixed without re-running the tool that found it. It is front-end / landing-page scope only (no backend, API, or Web3 in this pass). For exploratory click-through bug-hunting with a browser, see the `dogfood` skill; for design/UX improvement, see `impeccable`. This skill is the **objective, tool-gated gate** you run before shipping. ## Why this skill exists (read once) Front-end code — especially AI-generated front-end code — fails in ways that *look* fine on the screen but break in production: missing alt text, a planted API key in the bundle, a layout that scrolls horizontally on a phone, a Lighthouse performance score of 40. The human eye and the model's own judgment miss these. **Tools don't.** So the entire discipline here is: let tools be the source of truth, and don't trust your own "looks good." ## Core principles 1. **Tools are the source of truth, not your judgment.** Never report something as "fixed", "passing", or "good" from reasoning. Run the tool, read the real output, quote the number. If you can't run a tool, say so plainly — don't estimate a score. (This is the `self-verification` / verification-before- completion discipline applied to QA: evidence before claims, always.) 2. **