layers-surface
Skill307 starsChanged 6 months agoMITView on GitHub
Techniques for auditing and deciding the surface against the layers below — vocabulary, object consistency, completeness, feedback, hierarchy, accessibility
3 other projects use a version of this.
Adopted by
Most recently taken up by
- davidanthonyn/claude-skillstheir own version, first seen Oct 20, 2026
- pengGgxp/skillsword for word, first seen Oct 11, 2026
- miovrag/claude-skillsword for word, first seen Jun 12, 2026
Other versions3 projects use a version of this.
Word for word · 2
- miovrag/claude-skills★ 1100% same
- pengGgxp/skills★ 1100% same
Edited · 0
None found.
Wrote their own version · 1
- davidanthonyn/claude-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository8 other files it gives its agents.
- layers-conceptual-modelSkill
- layers-domainSkill
- layers-interaction-flowSkill
- layers-introSkill
- layers-observed-behaviourSkill
- layers-orientSkill
- layers-product-strategySkill
- layers-user-needsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 31
Object consistency: No shapeshifters (same object in significantly different forms across contexts), no masked objects (a form where the …
- Very specific: line 32
Completeness both ways: Every breadboard affordance is present.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/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, touch targets, keyboard, screen-reader labels, focus), voice (everything conveyed verbally, recovery without visual context), physical (reach, tactile differentiation, lighting, no fine-motor requirement). |
| Consistency pass | Similar things treated similarly, different things differently; medium conventions honoured or deliberately broken. |
| Make it (real medium, mockups, style tiles, prototypes, design system, copy-first) | When producing surface rather than auditing it. Work in code for real interaction feedback; mockups for layout/hierarchy; style tiles for early tone; prototypes for timing and motion; extend (don't contradict) an existing design system; write copy first when language is the primary material. |
Working with the designer
Establish the medium and what exists from below — conceptual model (objects + ubiquitous language), breadboard, job stories including emotional/social jobs. If surface exists, audit it; if not, work the open decisions.
Offer the technique that fits the live concern — a vocabulary check when terms feel off, a feedback inventory when users don't know what happened, an accessibility pass when it's been left to defaults. Don't run all ten.
Capture only the residue: audit findings (each tagged surface-fix or deeper-layer issue), the open surface decisions grouped and prioritised (with options and constraints), the cross-layer issues to resolve first, and what's already working well so it isn't lost in revision.
The surface either honours what's decided below or undermines it. Revisit after any significant change to the conceptual model or interaction structure.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.