web-latest

Name: web-latest
Author: AdamBien

40stars10forks

How to install web-latest?

adambien/airails/web-latest

$npx -y skills add AdamBien/airails --skill web-latest

Installs into the current project.

Summary

Composable modifier for experimentation and PoCs that lifts the /web-conventions Baseline browser-support policy so the newest web platform features — Newly Available, Limited availability, even experimental or flag-gated — can be used freely, without @supports wrappers or fa

Files · 1

View on GitHub

SKILL.md

1	Use the most recent web platform features freely in $ARGUMENTS. This is a modifier skill —
2	it changes exactly one thing about the composed stack: the browser-support policy.
3
4	## Purpose & Precedence
5
6	Experiments and PoCs exist to explore what the newest browsers can do; a support policy
7	designed for production audiences would defeat their purpose. When composed with
8	`/web-static` or `/web-components` (and their shared `/web-conventions`), this skill overrides:
9
10	- the Baseline Policy section of `/web-conventions`
11	- the Baseline check of `/web-static`'s verification loop (replaced below)
12	- any `@supports` or existence-check requirements the stack skills impose on
13	Newly Available features — feature detection becomes optional
14
15	Everything else in the composed skills remains binding. Explicitly not relaxed:
16
17	- accessibility rules, including `prefers-reduced-motion` and `prefers-color-scheme`
18	- semantic HTML and heading hierarchy
19	- `/web-static`'s no-JavaScript constraint
20	- `/web-components`' dependency and architecture rules
21	- design-token discipline
22
23	A PoC that is inaccessible or unsemantic demonstrates nothing about the feature it showcases.
24
25	## Relaxed Policy
26
27	- any Baseline status is usable: Widely Available, Newly Available, **Limited
28	availability**, and experimental or flag-gated features
29	- no `@supports` wrappers required, no fallbacks required, no graceful-degradation argument needed
30	- the view-transition exemptions carved out in `/web-static` and `/web-components` are
31	subsumed by this policy — no special casing needed
32	- when a feature exists in several maturity stages (e.g. a spec revision only Canary ships),
33	prefer the newest form that runs in at least one stable or pre-release browser
34
35	## Honesty Stays
36
37	The policy changes; the lookup discipline does not. A PoC is only useful if the viewer can
38	actually run it, so:
39
40	- still determine each feature's status from the `/web-conventions` bundled snapshot
41	(`references/baseline-snapshot.md`); a feature missing from the snapshot is likely newer
42	than it — verify against webstatus.dev or the feature's spec/release notes
43	- declare the support floor in the deliverable: a short section in the README (or a
44	comment at the top of the stylesheet/entry module) listing every below-Widely feature
45	used, its status, and which browser/version runs it
46	- for flag-gated features, name the flag and how to enable it
47	(e.g. `chrome://flags/#enable-experimental-web-platform-features`)
48	- never present the PoC as production-ready; when an experiment graduates, drop this
49	modifier and converge to the composed skill's default Baseline policy
50
51	## Verification Loop Amendment (with `/web-static`)
52
53	The verification loop runs unchanged with one substitution: the Baseline check becomes a
54	support-floor report — an inventory, not a gate:
55
56	- list each below-Widely feature the site uses with its status (Newly / Limited /
57	experimental) and the browsers that run it; confirm the declared support floor matches
58	- all other standard checks (console, structure, responsive, preferences, Lighthouse) and
59	every `checks.md` line still apply and still define green
60	- if a feature does not run in the DevTools Chrome, that is still red — unless the
61	support-floor declaration documents it as needing a flag or a different browser, in which
62	case report it as "not verifiable in this browser" rather than silently passing it
63
64	## What NOT to Do
65
66	- do not use this modifier for production sites — it exists for experiments, PoCs, and demos
67	- do not drop accessibility, reduced-motion, or semantic-HTML rules because "it's just a PoC"
68	- do not skip the support-floor declaration — an unrunnable demo is a failed demo
69	- do not claim Baseline compliance in any report while this modifier is active
70	- do not invent feature support from memory — cite the snapshot or verify upstream

People who liked this also viewed

6 picks

Type

web-latest

40stars10forks

View on GitHub

How to install web-latest?

adambien/airails/web-latest

$npx -y skills add AdamBien/airails --skill web-latest

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Use the most recent web platform features freely in $ARGUMENTS. This is a modifier skill —
2	it changes exactly one thing about the composed stack: the browser-support policy.
3
4	## Purpose & Precedence
5
6	Experiments and PoCs exist to explore what the newest browsers can do; a support policy
7	designed for production audiences would defeat their purpose. When composed with
8	`/web-static` or `/web-components` (and their shared `/web-conventions`), this skill overrides:
9
10	- the Baseline Policy section of `/web-conventions`
11	- the Baseline check of `/web-static`'s verification loop (replaced below)
12	- any `@supports` or existence-check requirements the stack skills impose on
13	Newly Available features — feature detection becomes optional
14
15	Everything else in the composed skills remains binding. Explicitly not relaxed:
16
17	- accessibility rules, including `prefers-reduced-motion` and `prefers-color-scheme`
18	- semantic HTML and heading hierarchy
19	- `/web-static`'s no-JavaScript constraint
20	- `/web-components`' dependency and architecture rules
21	- design-token discipline
22
23	A PoC that is inaccessible or unsemantic demonstrates nothing about the feature it showcases.
24
25	## Relaxed Policy
26
27	- any Baseline status is usable: Widely Available, Newly Available, **Limited
28	availability**, and experimental or flag-gated features
29	- no `@supports` wrappers required, no fallbacks required, no graceful-degradation argument needed
30	- the view-transition exemptions carved out in `/web-static` and `/web-components` are
31	subsumed by this policy — no special casing needed
32	- when a feature exists in several maturity stages (e.g. a spec revision only Canary ships),
33	prefer the newest form that runs in at least one stable or pre-release browser
34
35	## Honesty Stays
36
37	The policy changes; the lookup discipline does not. A PoC is only useful if the viewer can
38	actually run it, so:
39
40	- still determine each feature's status from the `/web-conventions` bundled snapshot
41	(`references/baseline-snapshot.md`); a feature missing from the snapshot is likely newer
42	than it — verify against webstatus.dev or the feature's spec/release notes
43	- declare the support floor in the deliverable: a short section in the README (or a
44	comment at the top of the stylesheet/entry module) listing every below-Widely feature
45	used, its status, and which browser/version runs it
46	- for flag-gated features, name the flag and how to enable it
47	(e.g. `chrome://flags/#enable-experimental-web-platform-features`)
48	- never present the PoC as production-ready; when an experiment graduates, drop this
49	modifier and converge to the composed skill's default Baseline policy
50
51	## Verification Loop Amendment (with `/web-static`)
52
53	The verification loop runs unchanged with one substitution: the Baseline check becomes a
54	support-floor report — an inventory, not a gate:
55
56	- list each below-Widely feature the site uses with its status (Newly / Limited /
57	experimental) and the browsers that run it; confirm the declared support floor matches
58	- all other standard checks (console, structure, responsive, preferences, Lighthouse) and
59	every `checks.md` line still apply and still define green
60	- if a feature does not run in the DevTools Chrome, that is still red — unless the
61	support-floor declaration documents it as needing a flag or a different browser, in which
62	case report it as "not verifiable in this browser" rather than silently passing it
63
64	## What NOT to Do
65
66	- do not use this modifier for production sites — it exists for experiments, PoCs, and demos
67	- do not drop accessibility, reduced-motion, or semantic-HTML rules because "it's just a PoC"
68	- do not skip the support-floor declaration — an unrunnable demo is a failed demo
69	- do not claim Baseline compliance in any report while this modifier is active
70	- do not invent feature support from memory — cite the snapshot or verify upstream

People who liked this also viewed

6 picks

Type