Vanilla Web (HTML/CSS/JS)
Baseline constraints (from the rule)
Use these as non-negotiables:
- "HTML/CSS/JS only (no framework)."
- "Keep JS modular (ESM), split responsibilities (SRP)."
- "Prefer small, focused functions and pure utilities; avoid global state."
- "Ship complete runnable files and minimal tests before marking done."
When to activate this skill
Activate when the user asks for:
- vanilla JS / plain HTML/CSS/JS / static page
- “no framework”, “no React/Vue/Angular”
- small UI components (modal, tabs, dropdown, form validation) built directly in the DOM
- refactors to remove framework dependencies or reduce JS complexity
Output expectations
- Deliver complete runnable files (no missing imports/paths, no TODO placeholders).
- Keep changes small, testable, and incremental.
- Provide a short runbook: how to run/verify locally + what to check in DevTools.
Implementation workflow
1) Clarify only what blocks correctness
Ask up to 3 questions only if requirements are ambiguous in a way that changes implementation.
Otherwise proceed with explicit assumptions.
2) Structure & responsibilities
- Prefer this split:
index.html (semantic markup)styles.css (or css/…)js/main.js as an ESM entrypoint + js/modules/*.js for components/utilities
- SRP: each module does one thing (DOM wiring, state, rendering, API, utilities).
- Avoid global mutable state. If state is needed, encapsulate it in a module and expose minimal functions.
3) HTML guidelines
- Use semantic tags (
header, main, nav, button, dialog where applicable).
- Accessibility baseline: keyboard navigation, focus states, ARIA only when needed (don’t ARIA-overuse).
4) CSS guidelines
- Prefer simple, predictable naming (BEM-like optional).
- Use CSS variables for theme primitives.
- Keep layout responsive by default (flex/grid + relative units).
5) JavaScript guidelines (ESM)
- Use
type="module" and explicit imports/exports.
- Prefer pure utilities and small functions.
- Use event delegation for lists/dynamic UIs.
- Handle errors explicitly (network failures, missing DOM nodes, invalid inputs).
Verification checklist
Use the detailed checklist in:
When finishing work, ensure:
- No console errors/warnings caused by the change
- All referenced assets resolve (paths/imports)
- Feature works with keyboard and without requiring a framework runtime
Progressive disclosure
Keep this SKILL.md lean; store deeper examples and checklists under references/.
Do not paste large style guides into SKILL.md—link to repo examples instead.
Suggested companion scripts (optional)
scripts/serve.sh for quick static serving (manual verification)
See:
1---2name: vanilla-web3description: Build or modify plain HTML/CSS/JavaScript (no framework) using modular ES modules (ESM), SRP, minimal global state, and shippable runnable files with lightweight verification. Use for static pages, small UI widgets, vanilla JS refactors, and quick prototypes without React/Vue/Angular.4---5
6# Vanilla Web (HTML/CSS/JS)
7
8## Baseline constraints (from the rule)
9Use these as non-negotiables:
10- "HTML/CSS/JS only (no framework)."
11- "Keep JS modular (ESM), split responsibilities (SRP)."
12- "Prefer small, focused functions and pure utilities; avoid global state."
13- "Ship complete runnable files and minimal tests before marking done."
14
15## When to activate this skill
16Activate when the user asks for:
17- vanilla JS / plain HTML/CSS/JS / static page
18- “no framework”, “no React/Vue/Angular”
19- small UI components (modal, tabs, dropdown, form validation) built directly in the DOM
20- refactors to remove framework dependencies or reduce JS complexity
21
22## Output expectations
231) Deliver **complete runnable** files (no missing imports/paths, no TODO placeholders).
242) Keep changes **small, testable, and incremental**.
253) Provide a short **runbook**: how to run/verify locally + what to check in DevTools.
26
27## Implementation workflow
28### 1) Clarify only what blocks correctness
29Ask up to 3 questions *only* if requirements are ambiguous in a way that changes implementation.
30Otherwise proceed with explicit assumptions.
31
32### 2) Structure & responsibilities
33- Prefer this split:
34 - `index.html` (semantic markup)
35 - `styles.css` (or `css/…`)
36 - `js/main.js` as an ESM entrypoint + `js/modules/*.js` for components/utilities
37- SRP: each module does one thing (DOM wiring, state, rendering, API, utilities).
38- Avoid global mutable state. If state is needed, encapsulate it in a module and expose minimal functions.
39
40### 3) HTML guidelines
41- Use semantic tags (`header`, `main`, `nav`, `button`, `dialog` where applicable).
42- Accessibility baseline: keyboard navigation, focus states, ARIA only when needed (don’t ARIA-overuse).
43
44### 4) CSS guidelines
45- Prefer simple, predictable naming (BEM-like optional).
46- Use CSS variables for theme primitives.
47- Keep layout responsive by default (flex/grid + relative units).
48
49### 5) JavaScript guidelines (ESM)
50- Use `type="module"` and explicit imports/exports.
51- Prefer pure utilities and small functions.
52- Use event delegation for lists/dynamic UIs.
53- Handle errors explicitly (network failures, missing DOM nodes, invalid inputs).
54
55## Verification checklist
56Use the detailed checklist in:
57- `references/checklist.md`
58
59When finishing work, ensure:
60- No console errors/warnings caused by the change
61- All referenced assets resolve (paths/imports)
62- Feature works with keyboard and without requiring a framework runtime
63
64## Progressive disclosure
65Keep this SKILL.md lean; store deeper examples and checklists under `references/`.
66Do not paste large style guides into SKILL.md—link to repo examples instead.
67
68## Suggested companion scripts (optional)
69- `scripts/serve.sh` for quick static serving (manual verification)
70
71See:
72- `scripts/serve.sh`
janjaszczak