Build a Website Checklist Skill for Claude in 2026

Published 16 June 2026 by Yanni Papoutsis

TL;DR: AI-built sites fail in predictable ways: pages that look fine at desktop width and collapse at 375px, auth flows missing their error and reset states, hero sections without a clear call to action, and inconsistent buttons because each session reinvented them. A website checklist skill encodes the counter-rules as five gates Claude must pass before calling any front-end task done. UI/UX: spacing scale, visual hierarchy, visible focus states, real empty and loading states. Responsive: verified at 320, 768, 1024, and 1440 pixels, no horizontal scroll, tap targets at least 44px. Auth: signup, login, reset, expiry, and error paths all present and tested. Conversion: one primary CTA above the fold, proof near the ask, forms reduced to minimum fields. Components: shared patterns for buttons, forms, modals, tables, and inline SVG icons rather than emoji. Template and build steps below.

A website checklist skill is a Claude skill that enforces front-end quality gates on every page and component Claude builds: UI and UX fundamentals, responsive behaviour at fixed breakpoints, complete auth flows, conversion essentials, and per-component checks for buttons, forms, modals, and tables. Claude is fast at producing interfaces; the checklist is what makes the tenth page as disciplined as the first.

What goes wrong without front-end quality gates?

The same five failures, on almost every AI-assisted build: broken small-screen layouts, incomplete auth journeys, weak conversion structure, inconsistent components, and missing interaction states. None of them are hard to fix; they are simply easy to forget, and a website checklist skill exists so forgetting is no longer possible.

The gates and what each one catches:

Gate Catches
UI/UX fundamentals cramped spacing, no hierarchy, missing focus and empty states
Responsive overflow at 320px, unreadable type on mobile, tiny tap targets
Auth flows missing reset, silent failures, dead-end error states
Conversion buried CTAs, zero proof, ten-field signup forms
Components five button styles, unlabelled inputs, emoji used as icons

How do you build the checklist skill step by step?

Write a SKILL.md with the five gates as concrete pass or fail checks, add per-component reference checklists, then load it before any front-end work begins. Here is the build.

Step 1: Create the folder

mkdir -p website-checklist/references

website-checklist/
  SKILL.md
  references/
    components.md   # per-component checklists
    auth-flows.md   # full auth journey map

Step 2: Write the SKILL.md

---
name: website-checklist
description: Front-end quality gates for all website and app building. Trigger BEFORE writing any HTML, CSS, or components, and on: landing pages, forms, auth, dashboards, navs, modals, responsive fixes, UI review, redesign, broken layout.
---

# Website Building Checklist

Pass every gate before calling front-end work done.

## 1. UI/UX
- Consistent spacing scale (4 or 8px steps), one type scale
- Clear hierarchy: one primary action per view
- Focus visible on every interactive element
- Empty, loading, and error states designed, not defaulted

## 2. Responsive
- Verify at 320, 768, 1024, 1440 widths
- No horizontal scroll at any breakpoint
- Tap targets 44px minimum; text 16px minimum on mobile

## 3. Auth flows (when present)
- Signup, login, logout, password reset, session expiry
- Every failure has a visible, specific, recoverable message
- Redirect-after-login returns to the intended page

## 4. Conversion
- One primary CTA above the fold, action-verb label
- Proof (numbers, testimonials, logos) near the ask
- Forms: minimum fields, inline validation, clear next step

## 5. Components
- Reuse existing components before creating variants
- Inputs labelled; buttons have one primary style per page
- Icons are inline SVG, never emoji
- Tables scroll on mobile instead of breaking layout

Step 3: Add the component references

The per-component checklists live in references/ so they load only when that component is being built. Two examples from components.md: a button check (label is a verb, disabled state visible, loading state present, focus ring intact) and a form check (labels bound to inputs, errors inline next to the field, submit disabled during processing, success state explicit). The auth reference maps the full journey as a checklist Claude walks before sign-off.

Step 4: Package, install, and load before building

zip -r website-checklist.skill website-checklist

Install it standalone or inside a plugin (see how to build a Claude plugin from scratch), and wire your Cowork navigator to load it on any front-end task. The ordering matters: gates loaded after the code is written become a rework list, while gates loaded before become the plan.

Step 5: Verify on the rendered output

Self-review against the gates happens in the build loop, not from memory of the code:

npm run build && npx astro preview
# check each breakpoint, tab through every interactive element,
# submit every form empty, wrong, and right

For an Astro site on Cloudflare Pages, preview deployments give you a real URL per change for breakpoint testing on actual devices; the workflow is documented in the Cloudflare Pages docs and the framework side at docs.astro.build.

How does this skill fit a larger build pipeline?

It becomes the QA gate that build stages must pass, which is stronger than using it ad hoc. In my 21-agent product pipeline, the frontend stage cannot hand off until this skill's five gates record a pass, the same pattern the pipeline uses for security and testing.

It also pairs with its content twin. This skill governs whether a page works for humans; the SEO and AI search checklist skill governs whether it works for search and answer engines. Running both before deploy covers the two ways a page can fail: nobody converts, or nobody arrives. General guidance on structuring skills so they trigger reliably is in the Claude documentation, and Anthropic's agent-design material at anthropic.com explains why checklist-shaped instructions outperform vague quality prompts.

Frequently asked questions

Why fixed breakpoints instead of "test on mobile"?

Because vague instructions produce vague testing. Naming 320, 768, 1024, and 1440 turns responsiveness into four concrete pass or fail checks, and 320px in particular catches the overflow bugs that "looks fine on my phone" misses.

Should every project pass every gate?

Every project passes the gates that apply: a static landing page has no auth flows to check, so that gate records not-applicable rather than pass. The discipline is recording a verdict per gate, never skipping silently.

Why inline SVG icons instead of emoji?

Emoji render differently across platforms, carry no styling control, and read as unprofessional in product UI. Inline SVG inherits colour from CSS, scales cleanly at any size, and supports accessible labelling, so the gate bans emoji-as-iconography outright.

How is this different from a linter or Lighthouse?

Tools measure what is machine-checkable after the fact; the skill shapes decisions during the build, covering judgement areas tools cannot score, like CTA placement, error message quality, and flow completeness. Use both: the skill for construction, the tools for regression.

About the author

Yanni Papoutsis builds AI products, automation pipelines, and technical documentation with Claude, and publishes free tooling and guides at yanni.uk.

Next step: Run this alongside the SEO and AI search checklist skill before every deploy, and explore 1,000+ free AI tools at yanni.uk/category/all/.

Sources