Html
Write and refactor semantic, accessible HTML and Svelte templates without div soup or broken landmarks.
Install
npx skills add https://github.com/stolinski/s-stack --skill htmlWhat is this skill?
- Decision order: pick the most appropriate element for content and interaction, not mechanical rules
- Covers landmarks, heading hierarchy, form labeling, and native controls vs custom widgets
- Explicit anti-scope: not for pure CSS architecture or unrelated Svelte state/reactivity
- Supports Svelte template cleanup without changing component behavior
- Core principle: semantic, accessible, maintainable, low-wrapper markup
Adoption & trust: 1 installs on skills.sh; 51 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
Recommended Skills
Frontend Designanthropics/skills
Vercel React Best Practicesvercel-labs/agent-skills
Remotion Best Practicesremotion-dev/skills
Vercel Composition Patternsvercel-labs/agent-skills
Develop Userscriptsxixu-me/skills
Next Best Practicesvercel-labs/next-skills
Journey fit
Common Questions / FAQ
Is Html safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.
SKILL.md
READMESKILL.md - Html
# HTML Write HTML that is semantic, accessible, maintainable, and easy to scan. Prefer simple structure, meaningful elements, and minimal wrapper noise. ## Core Principle Use the most appropriate HTML element for the content and interaction. Do not apply best practices mechanically. ## When to Use This Skill Use this skill when: - writing raw HTML or template markup - refactoring noisy or wrapper-heavy markup - improving semantics, landmarks, or heading structure - fixing form labeling and control choice - deciding between `div`, `section`, `article`, `ul`, and other structural elements - replacing custom interactions with better native HTML - cleaning up Svelte component markup without changing its behavior Do not use this skill for: - pure CSS architecture decisions - JavaScript behavior design unless the HTML choice is the root issue - marketing copy or content strategy - deep framework-specific state or reactivity changes unrelated to markup structure ## Decision Order When writing or reviewing markup: 1. choose the element that best matches the content or interaction 2. prefer native HTML behavior before custom behavior 3. remove wrappers that add no structural value 4. ensure labels, headings, landmarks, and image handling are correct 5. add ARIA only when native HTML cannot express the needed behavior ## Template Safety When the markup lives inside Svelte or another HTML-like template language: - treat the file as template markup, not as a plain standalone HTML document - preserve framework syntax such as `{#if}`, `{#each}`, `{:else}`, `{@html}`, `bind:`, `class`, `style:`, event attributes, and special elements like `<svelte:head>` - do not replace components or capitalized tags with native elements unless the task explicitly asks for that change - improve the HTML around directives and blocks without breaking bindings, keys, control flow, or component boundaries - apply full-document rules like `<!doctype html>`, `html`, `head`, and `body` only when the file is actually a document shell - in Svelte, treat compiler accessibility warnings as useful guardrails and do not add `svelte-ignore` comments casually ## Rules ### 1. Prefer Semantic Elements - Use semantic tags whenever they accurately match the content: - `header` - `main` - `section` - `article` - `nav` - `aside` - `footer` - `button` - `form` - `label` - Do not use `div` when a semantic element is clearly better - Do not force a semantic element where a plain container is more accurate ### 2. Structure Content by Meaning - HTML should describe content structure, not visual appearance - Choose elements based on what the content is - Do not choose elements based on default browser styles - Do not invent extra structure just to satisfy a rule ### 3. Keep Nesting Shallow - Avoid unnecessary wrappers - Prefer flatter, easier-to-read markup - Every extra layer should have a real structural, behavioral, or styling purpose ### 4. Heading Hierarchy Must Make Sense - Use one clear `h1` for the page or main view - Follow a logical heading order: - `h1` - `h2` - `h3` - Do not skip heading levels without reason - Do not use headings just to create large text ### 5. Accessibility Is Required - Always use proper labels for form controls - Use `button` for actions and `a` for navigation - Add meaningful `alt` text to informative images - Use ARIA only when native HTML cannot solve the problem - Do not add unnecessary ARIA ### 6. Prefer Native HTML Behavior - Use built-