Layers Surface
Audit screens, copy, feedback, and hierarchy so the surface matches your conceptual model, breadboard affordances, and accessibility needs.
Overview
layers-surface is an agent skill most often used in Build (also Validate, Ship) that audits customer-facing surfaces for model alignment, completeness, feedback, hierarchy, and accessibility.
Install
npx skills add https://github.com/jamiemill/layers-skills --skill layers-surfaceWhat is this skill?
- Separates surface fixes from problems that require revisiting conceptual or structural layers
- Checks vocabulary and object consistency against the conceptual model
- Verifies every breadboard affordance exists and flags orphan UI elements
- Covers emotional register, progress/error feedback, hierarchy, and accessibility
- Technique library (not a rigid script)—pairs with layers-intro framing
Adoption & trust: 579 installs on skills.sh; 155 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your UI looks finished but feels confusing, inconsistent, or untrustworthy—and you cannot tell if the fix is copy and layout or a broken model below.
Who is it for?
Builders using the Layers methodology who have conceptual and breadboard artifacts and need disciplined surface QA before ship.
Skip if: Greenfield projects with no layers-intro context or teams wanting a single linear implementation script without design diagnosis.
When should I use this skill?
After layers-intro is loaded, when auditing or deciding surface choices against vocabulary, affordances, feedback, hierarchy, and accessibility.
What do I get? / Deliverables
You classify each issue as a true surface fix or a lower-layer revisit, with explicit checks for vocabulary, affordances, feedback states, prominence, and accessibility.
- Surface-vs-deeper-layer issue classification
- Gap list for missing affordances or orphan UI
- Accessibility and feedback-state audit notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Surface quality is exercised most visibly while building UI, but the same audit lens applies whenever customer-facing touchpoints are designed or refined. Frontend and product surfaces are where vocabulary, object consistency, prominence, and accessibility either align with lower layers or betray them.
Where it fits
Walk a clickable prototype to confirm every promised affordance from the breadboard appears before you commit to build scope.
Review live screens so labels and objects match the conceptual vocabulary while hierarchy reflects the primary job.
Pre-release pass on loading, success, and error feedback plus accessibility before customers hit the first mile.
Re-audit lifecycle emails or in-app prompts so surface tone and clarity still match the model after feature churn.
How it compares
Layered UX audit techniques—not a component library generator or generic accessibility linter runbook.
Common Questions / FAQ
Who is layers-surface for?
Solo founders and product designers who already use the Layers skills and need structured surface audits across UI, voice, or physical touchpoints.
When should I use layers-surface?
While scoping prototypes in Validate, implementing frontend in Build, and doing pre-launch experience review in Ship when surface quality affects comprehension and trust.
Is layers-surface safe to install?
It is editorial methodology with no prescribed shell or network actions; still review the Security Audits panel on this page before adding any skill pack to your agent.
Workflow Chain
Requires first: layers intro
SKILL.md
READMESKILL.md - Layers Surface
# /layers-surface *Assumes `/layers-intro` has been loaded. This skill is a library of techniques, not a script — see "How to use these skills" there.* The surface layer is where everything decided below becomes something a person actually encounters: words, sounds, visuals, physical affordances, motion, feedback. It's the most medium-specific layer, but the decisions that matter most first are universal — they hold whether the surface is a screen, voice interface, physical device, or service touchpoint. Surface problems are often symptoms of deeper ones. The central discipline here is telling apart issues you can fix at the surface from issues that need a lower layer revisited. --- ## The decisions this layer makes - Whether the surface honours the vocabulary and objects from the conceptual model - Whether every affordance from the breadboard is present — and whether any surface element has no model behind it - Whether the emotional register fits the jobs users are doing - How the user knows what happened, what's in progress, and what went wrong - What's most prominent, and whether it should be - Whether everything is accessible to the users who need it --- ## Disciplines — what keeps the surface honest - **Surface fix vs deeper-layer issue.** The key judgement: is this something to fix in the copy/layout, or a symptom whose root is in the conceptual model or interaction flow? Wrong vocabulary may be a rewrite — or a model that never settled the term. Route deeper issues back to the relevant skill rather than patching the symptom. - **Terms match the ubiquitous language.** Flag direct violations (a model term used inconsistently), unlisted terms (surface words not in the model — add to model, or remove as noise), and tone misalignments. - **Object consistency.** No shapeshifters (same object in significantly different forms across contexts), no masked objects (a form where the user can't recognise the object type). - **Completeness both ways.** Every breadboard affordance is present; no surface element exists with no model or flow behind it (those are interaction decisions that slipped through — route to `/layers-interaction-flow`). - **Errors diagnose, explain, recover.** "Something went wrong" fails all three. Flag every error state that doesn't do all three. - **Prominence reflects importance.** What the flow needs the user to notice is what stands out; nothing prominent that shouldn't be. - **Accessibility is decided, not defaulted.** - **Emotional register matches the emotional and social jobs** from user needs — not the product's benefit framed as the user's. --- ## Techniques Two kinds of work live here: auditing existing surface against the layers below, and working through open surface decisions. Use whichever the situation calls for. | Technique | Use it to | |---|---| | **Vocabulary check** | Take the ubiquitous language list; check every label, heading, button, error, notification, help string against it. | | **Object-consistency check** | For each model object: where does it appear, in how many forms? Catch shapeshifters and masked objects. | | **Completeness check** | Walk the breadboard against the surface in both directions — missing affordances, and surface with no model behind it. | | **Emotional-register check** | Return to the emotional and social jobs; find where tone, framing, or emphasis misaligns. | | **Feedback & error inventory** | For each action and state transition: how does the user know it worked, is in progress, or failed — and what to do next? | | **Hierarchy review** | Per key place: what must the user notice or act on, and does the surface make that most prominent? Decide what's primary before how to signal it. | | **Accessibility pass** | Per medium — screen (contrast, sizing, touc