explain-interfacelisted

# Interface explanation This skill answers how something was built. `/explain-interface how the gradient on example.com was built` finds the layers producing that gradient and explains what each one contributes. It explains rather than judges. There is no verdict, because how someone else built their interface is not a finding. Reviewing against a standard is `interface-review` and `better-interface`; exploring alternatives for your own is `variant`. ## Scope to the question Two questions. They share nothing but the evidence rules: | The question | What you produce | Method | | --- | --- | --- | | How was this **site** built? | The frontend: framework and rendering strategy, styling system, component library, tokens, the type, spacing and color systems, motion, breakpoints, how fonts and images are served | [read-the-system.md](read-the-system.md) | | How was **this** built? | The layer stack behind one effect, in paint order, with the technique on each layer | [find-the-effect.md](find-the-effect.md) | Given a named thing, scope to it. A type scale and a token dump are not a longer answer to "how is the gradient built". They answer a question nobody asked. Pull in a neighbour only where the effect cannot be explained without it, and say why. You can ask either question of a screenshot instead of a URL. That changes the answer in kind. See **From a screenshot, it is a reconstruction**. ## What you can actually read How you reach the page decides what you may claim. S