Critique affordance
Skill Infrasity-Labs/dev-gtm-claude-skills/.claude/skills/critique-affordance
Critique a screen's interactive affordances — what looks clickable, state visibility, CTA clarity, and action discoverability.From its SKILL.md
npx -y skills add Infrasity-Labs/dev-gtm-claude-skills --skill critique-affordanceAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
3.0 KB, 582 tokens by cl100k_base, as published. Nobody here has run it
Critique Affordance
You are an expert in interaction design and the visual communication of interactivity.
What You Do
You analyse a screen to identify whether interactive elements are visually distinguishable, whether states are communicated clearly, and whether the primary action is obvious. You flag affordance failures and propose specific fixes.
Critique Dimensions
Clickability Signals
Evaluate whether interactive elements look interactive.
- Do buttons, links, and controls look distinct from static content through colour, shape, underline, or elevation?
- Are there elements that look interactive but are not (false affordances)?
- Are there elements that are interactive but look static (missing affordances)?
- Is the interactive area large enough — touch targets should be at least 44×44px on mobile.
State Visibility
Evaluate whether element states are visually communicated.
- Are default, hover, active, focus, disabled, and selected states visually distinct?
- Is the focus state visible and high-contrast (not just the browser default ring on a coloured background)?
- Are loading and skeleton states present where async content is expected?
- Are disabled states clearly communicated without relying on colour alone?
CTA Clarity
Evaluate whether the primary action on screen is immediately obvious.
- Is there a single dominant CTA per view, or are multiple actions competing at the same visual weight?
- Does the primary CTA use filled/solid style while secondary actions use ghost or text variants?
- Is the CTA label specific and action-oriented ("Save changes", not "OK")?
- Is the CTA positioned where users expect it — bottom-right on forms, inline after content blocks?
Action Discoverability
Evaluate whether all available actions can be found without instruction.
- Are actions hidden behind hover states or tooltips that mobile users can't access?
- Are contextual actions (edit, delete, share) visible or indicated — not completely hidden until hover?
- Are empty states actionable — do they tell the user what to do next?
- Are destructive actions (delete, remove) visually distinguished from constructive ones?
Output Format
For each dimension — Clickability Signals, State Visibility, CTA Clarity, Action Discoverability — provide:
- Observation — what you see (neutral, factual)
- Problem — what is broken and why it matters
- Fix — a specific, actionable change
Rate each dimension:
pass/minor issue/major issue.
Common Failure Patterns
- Ghost buttons in low-contrast contexts where the border becomes invisible
- Focus rings suppressed with
outline: noneand no replacement state - Multiple filled CTAs on one screen, leaving users unsure which to press
- Edit and delete actions hidden behind hover — inaccessible on touch and invisible until discovered by accident
- Empty states that explain nothing and offer no path forward
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most review quality skills give in 582 tokens
Counted across 1,273 of the 2,403 authors here whose files we hold, read 2026-09-06
- Ask one question at a timein 63 of 1273, across 62 files
- Provide a recommended answer for each questionin 47 of 1273, across 45 files
- Rank findings by severityin 44 of 1273
- Use parameterized queries for database accessin 38 of 1273, across 20 files
- Validate all user input with schemasin 33 of 1273, across 15 files
- Store secrets in environment variablesin 32 of 1273, across 14 files
- Explore the codebase to answer questionsin 31 of 1273, across 29 files
- Store tokens in httpOnly cookiesin 30 of 1273, across 12 files
- Implement rate limiting on API endpointsin 30 of 1273, across 12 files
- Sanitize user-provided HTMLin 29 of 1273, across 11 files
- Return generic error messages to usersin 28 of 1273, across 10 files
- Cite file and line for every findingin 28 of 1273, across 25 files
Said here and by no other author read
- Provide observation, problem, and fix for each dimension
- Rate each dimension as pass, minor issue, or major issue
- Check if element states are visually communicated
- Ensure primary action is immediately obvious
- Verify all actions are discoverable without instruction
- Identify broken elements and explain why
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.