web-conventions

Generic, composable web platform conventions — semantic HTML, accessibility, modern CSS, custom-property design tokens, and Baseline browser-support policy that apply across all web frontends (static sites, web component SPAs). Meant to be composed with context-specific skills (e.g. `web-static`, `web-components`). Use when writing, generating, or reviewing HTML or CSS anywhere the composed skill does not already specify a rule. Triggers on "web conventions", "semantic HTML", "web forms", "form validation", "input types", "accessibility review", "modern CSS", "design tokens", "DESIGN.md", "Baseline status", "serve the site", "dev server", "zws", or any request to write or review HTML/CSS. Also use when a project contains a DESIGN.md that should guide HTML/CSS generation, when a Baseline status must be looked up (bundled webstatus.dev snapshot in `references/baseline-snapshot.md`), or when a static site root needs to be served locally (bundled zws dev server in `scripts/zws`).

跳到安装

仓库: AdamBien/airails
最近来源活动: 2026年8月5日 16:59
检测到的 SKILL.md 语言: 英语
星标: 46
分支: 10

安装方式

默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

直接命令不会经过审查 Prompt；运行前请先检查来源。

npx skills add https://github.com/AdamBien/airails --skill web-conventions

命令会保持在同一行。复制前请横向滚动并检查完整内容。

想先保存到本地？可下载 SkillsMP 当前能够提供的文件。

检查来源文件

决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。

文件资源管理器

4 个文件

SKILL.md

来源说明 · 只读预览

返回搜索返回安装

sbce

Spec-driven BCE workflow where one capability spec equals one business component (same name) and the spec is the boundary contract. Invoked as `/sbce new|apply <capability-or-feature>` (or by intent), it drives declare → converge; the stack's own test loop is the oracle for "done". `new` accepts a BC name or a natural-language feature description that may decompose into one or several BCs (new or existing). Stack-neutral — composes with `/bce` and a stack skill (`/java-cli-app`, `/microprofile-server`, `/web-components`, …) for code shape and verification. Use when authoring or converging a capability spec, declaring a feature as one or more BCs, mapping a spec to a BC, or running `/sbce new`, `/sbce apply`. Triggers on "SBCE", "capability spec", "spec-driven BCE", "declare a feature", "spec to BC", "converge to spec", "/sbce new", "/sbce apply".

2026-08-05

javascript-conventions

Generic, composable JavaScript (ECMAScript) code conventions — modules, declarations, functions, collections, asynchrony, errors, JSDoc types, naming, and the Baseline lookup that decides which language and standard-library features may be used. Technology-neutral within the JavaScript world; meant to be composed with context-specific skills (e.g. `web-components`) alongside `web-conventions` (HTML/CSS). Use when writing, generating, or reviewing JavaScript anywhere the composed skill does not already specify style. Triggers on "JavaScript conventions", "JS style", "modern JavaScript", "ECMAScript", "ES2025", "idiomatic JavaScript", "ES modules", "JSDoc types", "async/await style", "which JS feature may I use", or any request to write or review JavaScript where context-specific skills do not already cover style. Not for HTML or CSS rules — see `web-conventions`.

2026-08-05

web-components

Architecture and coding rules for single-page applications using web components, BCE layering, lit-html templating, unidirectional Redux-style state management (reduction.js, standards-based), and standards-based client-side routing (Navigation API + URLPattern). Web standards and web platform first, minimal external dependencies. Composes with `web-conventions` (semantic HTML, accessibility, design tokens, Baseline policy). Use when creating, scaffolding, generating, writing, or reviewing web component applications, custom elements, state management, client-side routing, or frontend BCE architecture. Not for server-side rendering or framework-heavy applications, not for static content sites without client-side state — use `web-static` — and not for static sites needing only a few isolated enhancements — use `web-sprinkles`.

2026-08-05

查看这个仓库的全部 Skills

name

web-conventions

description

Apply all rules below strictly to any HTML and CSS you write, generate, or review.

Scope

Platform-level rules for HTML and CSS only — semantics, accessibility, styling, theming, browser-support policy.
JavaScript language-level rules — modules, syntax, functions, collections, asynchrony, errors, JSDoc types — are not in this skill; they are the sibling baseline javascript-conventions, which applies the Baseline policy below to JavaScript syntax and APIs.
JavaScript policy (whether JavaScript is used at all), architecture, state management, routing, dependencies, project structure, and verification loops are not in this skill — see the context-specific skills web-static (no-JavaScript static sites), web-sprinkles (static sites with bounded JavaScript enhancements), and web-components (web component SPAs).
Responsive strategy (media queries vs container queries) is stack-specific — the composed skill decides.
When a composed skill specifies a rule, the composed skill wins; this skill is the fallback baseline.

Guiding Principles

web standards and web platform first
minimal external dependencies — every dependency must justify its existence
progressive enhancement over JavaScript-first design

HTML Rules

semantic elements over generic <div>/<span> — use <header>, <nav>, <main>, <article>, <section>, <aside>, <footer>, <figure>, <time>, <address>
one <main> per page
proper heading hierarchy (h1 → h2 → h3, no skipping)
lang attribute on <html>
alt on all images (empty alt="" for decorative)
aria-label on <nav> when multiple navs exist
<label> associated with every form input
skip link for keyboard users
use <a> for navigation, not buttons
use <br> only for line breaks in content, never for spacing

Form Rules

use the semantically correct input type — email, url, tel, password, search, number, date, time, range, file, checkbox, radio — never type="text" plus JavaScript re-implementation; the type alone provides the right mobile keyboard, native widget, and built-in validation (all Widely Available)
exception: <input type="color"> is Baseline Limited — do not use it; fall back to a text input with a pattern for hex colors
declare constraints in markup: required, pattern, min/max/step, minlength/maxlength — built-in validation is the first line of defense, JavaScript only for rules markup cannot express (Constraint Validation API is Widely Available)
autocomplete on every field with a well-known meaning (name, email, street-address, current-password, …) — autofill is both UX and accessibility
inputmode only when no dedicated input type fits (Widely Available)
placeholder is a hint, never a substitute for a <label>
group related controls with <fieldset>/<legend>
give every <button> inside a form an explicit type — the default is submit, which makes stray buttons submit the form
style validation states with :user-valid/:user-invalid (Widely Available since 2026-05), not :valid/:invalid — the :user-* pseudo-classes wait for user interaction instead of flagging pristine fields

Accessibility Rules

WCAG AA color contrast minimum (4.5:1)
always maintain visible :focus-visible indicators
every interactive element reachable and operable by keyboard
include prefers-reduced-motion: reduce and prefers-color-scheme: dark media queries

CSS Rules

all CSS in separate .css files — no inline styles
use logical properties (margin-block, padding-inline, inline-size, block-size)
use modern features: CSS nesting, container queries, cascade layers, subgrid, oklch() colors, the :has() selector — subject to the Baseline policy below
use clamp() for fluid typography
prefer gap over margins for spacing in flex/grid layouts

Scrolling

use CSS scroll snap (scroll-snap-type, scroll-snap-align) for carousels, galleries, and section-based scrolling — never JavaScript scroll hijacking (scroll snap is Baseline Widely Available)
pair scroll snap with scroll-padding on the container so snapped content clears sticky headers
apply scroll-behavior: smooth only inside @media (prefers-reduced-motion: no-preference)

Design Tokens

define design tokens as CSS custom properties on :root — colors, spacing, typography, radii
component and page rules reference tokens, never raw values
CSS custom properties are the token source of truth — do not adopt the DTCG token JSON format or token-translation tooling (Style Dictionary, Terrazzo, etc.)
when a DESIGN.md exists at the project root, read it before writing or reviewing any CSS — it declares the design intent: palette, typography, spacing scale, and component rules, with the reasoning behind them
DESIGN.md is context, not a build input: never generate CSS from it mechanically, and never edit it to match the CSS — it is human/tool-owned
when :root tokens contradict DESIGN.md, surface the drift and let the user decide which side changes — never silently pick one

Baseline Policy

Widely Available features may be used freely
Newly Available features require @supports feature detection with a graceful fallback for older browsers
Limited availability features must not be used
when recommending a newer CSS feature, cite its Baseline status (Widely Available, Newly Available, or Limited) so the reader can judge browser support
the policy covers JavaScript features too, where an existence check replaces @supports — the JavaScript-side rules live in javascript-conventions
determine a feature's status by looking it up by feature id in references/baseline-snapshot.md — a bundled, dated snapshot of the complete webstatus.dev feature set — never from model memory; statuses change over time (Newly crosses into Widely 30 months after the low date)
a feature missing from the snapshot, or newer than the snapshot's header date, is uncertain: verify against webstatus.dev before recommending it, or treat it as Limited
the snapshot is generated by zbaseline — never edit it in place; re-run zbaseline to refresh, and replace the whole file
for experiments and PoCs, the /web-latest modifier overrides this policy — any feature status becomes usable, with a declared support floor instead of fallbacks

Bundled Tooling

scripts/zws — a copy of zws, the zero-dependency single-file Java development server. Serves any static site root on http://localhost:3000 (loopback only, caching disabled, opens the browser). Requires JDK 25+.
invocation: java <this skill's directory>/scripts/zws <site-root> — prefer a zws already on the PATH (the maintained install); the bundled copy is the fallback so composed skills (web-static verification loop, web-components dev serving) work after a zip-only install.
flags: --live reloads connected browsers on file changes (injects a one-line SSE script into served HTML — authoring only, never under a verification run, where the injected script would contaminate the evidence); --single serves index.html for extension-less unknown paths (SPA fallback for web-components routing — wrong for multi-page static sites, where it masks broken links). The flags compose.
the copy mirrors AdamBien/zws — never edit it in place; when upstream changes, re-copy.
never serve with python3 -m http.server or Node-based dev servers.

What NOT to Do

do not use tables for layout
do not use <br> for spacing — use CSS spacing
do not use non-semantic <div>/<span> when a semantic element exists
do not use inline styles
do not re-implement in JavaScript what standard input types and constraint attributes already validate
do not add novalidate to a form unless the Constraint Validation API takes over the checks it disables

web-conventions

来源信息

安装方式

检查来源文件

同仓库更多 Skills

Scope

Guiding Principles

HTML Rules

Form Rules

Accessibility Rules

CSS Rules

Scrolling

Design Tokens

Baseline Policy

Bundled Tooling

What NOT to Do

同仓库更多 Skills

Scope

Guiding Principles

HTML Rules

Form Rules

Accessibility Rules

CSS Rules

Scrolling

Design Tokens

Baseline Policy

Bundled Tooling

What NOT to Do