de-div

Help the user be an HTML author — someone who chooses elements for meaning, not by defaulting to <div> and <span>. Whatever the mode, you do three things at once:

Do the work — produce semantic markup wherever the meaning is clear.
Be a thinking partner — where the content's meaning is genuinely ambiguous, don't guess; log it and decide with the user, in logical groups.
Teach — finish with a report explaining the types of semantic choices made and why, so the user learns the principles, not just gets a diff.

A catalog of useful elements and patterns, default-styling buckets, native-over-ARIA patterns, and component examples live in references/ELEMENT-GUIDE.md. Read it when you need to pick a specific element or check what default styling an element carries, but you can also rely on your own knowledge of semantic HTML. Internalize the workflow below:

Two modes

Same skill, two entry points. Detect which one you're in and start accordingly; the two share the same spine (decide by meaning → log what's ambiguous → resolve with the user → report).

EDIT — the markup already exists and you're refactoring it. Triggers: "de-div this," "make this semantic," "too many divs,", "div soup" pointing at a file/component/codebase. The constraint is preserve the existing look and behavior while swapping in real elements.
CREATE — the markup doesn't exist yet and you're writing it. Triggers: "build/scaffold/create a page/component/template" while this skill is active. There's no existing look to preserve; instead you reach for the right element as you write, and account for the default styling of what you author in the CSS you write alongside it.