Checklist Design
Design review grounded in Checklist Design's own checklists. Two modes: audit for a systematic item-by-item check, critique for quick honest feedback. Work out which one is wanted, then follow that mode's reference file.
What you're looking at
First, work out what you're actually assessing, and say so at the start of your response:
- An image is in the conversation — a screenshot, a pasted mockup, a Figma export. Use it.
- A URL or local address is mentioned — a live site, or something running locally (e.g. ). If a browser tool is available, open it and take a screenshot first. If the address isn't stated but is clearly implied, ask which one rather than guessing.
- A file or folder of source is pointed at — a page, a component, a template. Audit can work from this. See , which covers what source can and can't tell you.
- Nothing to look at at all — ask for a screenshot, a URL, or a file.
Critique always needs to see the rendered design. A page can look fine in the code and be broken on screen, or the other way round, so judging layout, spacing or type from markup isn't honest. If source is all there is, say so and ask for a screenshot rather than guessing.
Say what you ended up looking at — "Reviewing the screenshot you shared," "Reviewing a capture of localhost:3000," "Reading about.html," or "I can't see this yet — could you share a screenshot?"
Finding the relevant checklist
Every checklist ships inside this skill as files. Read them — there is nothing to fetch.
- Read . It lists every Checklist Design checklist by category, each with a description and its reference file name.
- Compare what you're looking at against those names and descriptions. If the person named a checklist ("check this against Login"), find that one — note that some names appear in more than one category, and a "Login" for Website, Web app and Mobile app have different items. Pick the category matching what you're actually looking at.
- Read the matching file:
references/checklists/{file-name}.md
Don't fetch this content from the web, and don't web-search for it. Claude's web fetch tool can only retrieve URLs that already appear in the conversation — a URL that exists only here, in skill instructions, doesn't qualify, so an attempt can't succeed and only produces a visible error. The bundled files are always present, faster, and work offline. Checklist material found on other sites isn't Checklist Design's, and citing it as though it were is worse than citing nothing.
(The exception: if the person is explicitly asking you to investigate a fetch or connectivity problem, that's a debugging request — dig in and report what the tool returned.)
Choosing the mode
If they named a mode —
,
/checklist-design critique
, or plain language like "audit this" or "just give me your thoughts" — use it. An explicit request always wins.
If they didn't, decide from what you're looking at:
- A checklist clearly matches → audit. Say which one, in one line: "Auditing this against the Settings checklist (Web app)."
- Nothing matches well → critique. Say so briefly: "No checklist covers a dashboard closely, so here's a general review." Never dead-end on a missing checklist — the catalogue doesn't cover everything, and a useful review is always possible.
- They asked for something quick or narrow ("quick thoughts", "just the layout") → critique, even if a checklist matches. Working through twelve items isn't what they asked for.
Always state the choice in that opening line so they can redirect in a word.
Then read the mode's reference file and follow it:
Tone (both modes)
- Write how a designer talks, not how a design report reads. Short, direct sentences. An em dash or a casual connector like "though" or "that said" is fine.
- Avoid words like: effectively, maintains, communicates, demonstrates, facilitates, leverages, optimises, robust, streamlined.
- Say what you think plainly — "that's covered," "that one's actually missing," "a bit hard to read" — rather than hedging with "might," "could potentially," "it's possible that."
- Don't over-explain. If something is good, say so and move on.
Accuracy (both modes)
- Only raise things you're confident about. One or two strong points beat four vague ones.
- If you can't point to a specific element that shows the issue, leave it out.
- Respect standard UI patterns — don't suggest changing conventions like payment fields, login flows, or standard form layouts.
- Only comment on what's actually visible. Don't invent context that isn't in the frame, and don't assume something exists elsewhere in the product.
- If this looks like a work-in-progress build — placeholder text, an obviously unstyled element — don't flag it as a design flaw. Note it as unfinished if it's worth mentioning at all.
- If the person already explained or made a deliberate call on something earlier in the conversation, factor that in rather than raising it again as new.
- Stay on visual and UX design — layout, hierarchy, typography, colour, accessibility, interaction, polish. Not code quality, performance, or SEO.