Web Technique to Skill

Start from working code, not from prose. Reach for article-prompts-to-skills when the source is an article or a prompt pack that describes behavior. Reach for this when you built the thing, it works, and the knowledge is currently trapped in one file.

Extract one mechanism per skill. A page that turned out well usually holds several; package them separately or each one gets diluted.

Treat this as the living quality contract for every web-technique skill. On every creation or revision, audit this skill too. If the work exposes a missing fidelity rule, failure mode, packaging constraint, or verification step, update this contract in the same scoped change instead of solving it only inside one child skill.

Name the mechanism in one sentence

Write the sentence before you write anything else: the one thing that, if removed, makes the effect stop working. If you cannot write it, you have a look, not a mechanism, and there is no skill here yet.

The sentence decides everything downstream. For a leaf fall it is "the tumble crosses edge-on, and that instant of near-disappearance is what the eye reads as a leaf" — so the sprite artwork, the palette, and the night scene are all staging, and the tumble is the skill.

Test it: change the subject, the palette, and the layout in your head. If the sentence still holds, it is the mechanism. If it stops making sense, you named the staging.

Name the demo and disclose the stack

Use the concrete technique name for the visible h1 and browser <title>: Wisps, Cursor Ripples, Liquid Metal Border, or Scroll-scrubbed Word Reveal. Do not hide the subject behind an abstract mechanism claim. “Draw at any speed” describes behaviour, but it does not tell anyone what the demo is.