Web Latest

Use the most recent web platform features freely in $ARGUMENTS. This is a modifier skill — it changes exactly one thing about the composed stack: the browser-support policy.

Purpose & Precedence

Experiments and PoCs exist to explore what the newest browsers can do; a support policy designed for production audiences would defeat their purpose. When composed with /web-static, /web-sprinkles, or /web-components (and their shared /web-conventions), this skill overrides:

• the Baseline Policy section of /web-conventions
• the Baseline check of /web-static's verification loop (replaced below)
• any @supports or existence-check requirements the stack skills impose on Newly Available features — feature detection becomes optional

Everything else in the composed skills remains binding. Explicitly not relaxed:

• accessibility rules, including prefers-reduced-motion and prefers-color-scheme
• semantic HTML and heading hierarchy
• /web-static's no-JavaScript constraint
• /web-sprinkles' enhancement contract — detection becomes optional, but a page whose content depends on an experimental API is broken, not experimental
• /web-components' dependency and architecture rules
• design-token discipline

A PoC that is inaccessible or unsemantic demonstrates nothing about the feature it showcases.

Relaxed Policy

• any Baseline status is usable: Widely Available, Newly Available, Limited availability, and experimental or flag-gated features
• no @supports wrappers required, no fallbacks required, no graceful-degradation argument needed
• the view-transition exemptions carved out in /web-static and /web-components are subsumed by this policy — no special casing needed
• when a feature exists in several maturity stages (e.g. a spec revision only Canary ships), prefer the newest form that runs in at least one stable or pre-release browser

Honesty Stays

The policy changes; the lookup discipline does not. A PoC is only useful if the viewer can actually run it, so:

• still determine each feature's status from the /web-conventions bundled snapshot (references/baseline-snapshot.md); a feature missing from the snapshot is likely newer than it — verify against webstatus.dev or the feature's spec/release notes
• declare the support floor in the deliverable: a short section in the README (or a comment at the top of the stylesheet/entry module) listing every below-Widely feature used, its status, and which browser/version runs it
• for flag-gated features, name the flag and how to enable it (e.g. chrome://flags/#enable-experimental-web-platform-features)
• never present the PoC as production-ready; when an experiment graduates, drop this modifier and converge to the composed skill's default Baseline policy

Verification Loop Amendment (with /web-static or /web-sprinkles)

The verification loop runs unchanged with one substitution: the Baseline check becomes a support-floor report — an inventory, not a gate:

• list each below-Widely feature the site uses with its status (Newly / Limited / experimental) and the browsers that run it; confirm the declared support floor matches
• all other standard checks (console, structure, responsive, preferences, Lighthouse), the /web-sprinkles no-JavaScript pass, and every checks.md line still apply and still define green
• if a feature does not run in the DevTools Chrome, that is still red — unless the support-floor declaration documents it as needing a flag or a different browser, in which case report it as "not verifiable in this browser" rather than silently passing it

What NOT to Do

• do not use this modifier for production sites — it exists for experiments, PoCs, and demos
• do not drop accessibility, reduced-motion, or semantic-HTML rules because "it's just a PoC"
• do not skip the support-floor declaration — an unrunnable demo is a failed demo
• do not claim Baseline compliance in any report while this modifier is active
• do not invent feature support from memory — cite the snapshot or verify upstream