Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/aziontech/webkit/webkit-formnpx skills add aziontech/webkit --skill webkit-formgit clone --depth 1 https://github.com/aziontech/webkitWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00172 | $0.12953 |
| Opus 5 | $0.00086 | $0.06476 |
| Sonnet 5 | $0.00034 | $0.02591 |
| Haiku 4.5 | $0.00017 | $0.01295 |
Grade A, and why
webkit-form scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 1,014 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: webkit-form
Purpose
Forms are where a product is most keyboard- and screen-reader-tested and most often fails: a label
that is really a placeholder, a select whose <label for> points at nothing, a validation error shown
only in colour, a field that never says it was required. This skill fixes the accessibility of a form
built on @aziontech/webkit so it is operable by keyboard, understandable by a screen reader, and
recoverable when it rejects input. It is the a11y companion to /webkit-ux-heuristics
(which establishes the states) and /webkit-ui-states (which locks the scope and
toasts request errors) — this skill owns layout, labels, grouping, validation semantics, and submit.
There are two ways to lay out a form, and both are first-class:
- Approach A — Cards + ItemGroups. Sections are a flush
CardBoxwrapping anItem.List; every field is oneItemrow (name/guidance on the left, control on the right). This is the default for grouped, settings-style, or list-like forms — an account settings page, a resource's config or create page, a create drawer. - Approach B — Fields separated. Standalone
field-*triads stacked in a column. This is for short, focused, single-purpose forms — a sign-in flow, a rename or delete-confirmation dialog, a short create drawer, a single step in a wizard.
Pick one per form; don't mix row-fields and stacked-fields in the same section.
How to use
/webkit-formApply the layout + patterns below to any form you build in this conversation./webkit-form <file>Review the file's form against the patterns and output, per gap:- the exact line / element (quoted),
- which pattern it breaks (1 short sentence),
- the concrete fix, naming the webkit component to use.
When to invoke
- Building or reviewing any create/edit page, settings panel, drawer form, or multi-field form.
- The user asks "is this form accessible", "wire up the labels", "the screen reader skips this", "where do errors go", "which layout for this form".
- After
/webkit-ux-heuristicsestablishes the states and before/webkit-ui-stateslocks the async submit.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 1,014 lines · 172 tokens per session scan A 861cd0ffaf9c
webkit-form is a skill published in the GitHub repository aziontech/webkit (2 stars, last pushed 4d ago), licensed MIT. It adds 172 tokens to every session and 12,953 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
monorepo-management
Sets up or audits a monorepo workspace: tool selection, package naming, shared tooling, inter-package dependencies, selective CI, and versioning strategy. Invoked when the user asks to set up a monorepo, add a workspace, or manage multiple packages in a single repository.
bazel-monorepo-expert
Expert knowledge for managing large-scale Bazel monorepos with multiple services, shared libraries, and cross-cutting concerns. Use for workspace structure, visibility, and dependency management.
pnpm
Skill "pnpm" from pledgeandgrow/pledge-skills, covering pnpm documentation skill, key benefits, file index, quick start and install pnpm.
fast-typescript-check
Keep www-sacred's TypeScript fast to type-check and fast to run. Use when touching the ASCII/canvas animation components (the only real per-frame code here), tightening type-check wall-clock, or auditing a change for runtime or compiler regressions. Scoped to this repo — a React 19 / Next.js 16 component library plus…
port-sacred-terminal-ui-to-typescript-cli
Take a React Window.tsx (or any sacred component) and produce a terminal CLI screen written in TypeScript that uses Simulacrum — the sacred CLI framework in scripts/cli/lib/.
port-sacred-terminal-ui-to-react-using-same-conventions
Take a CLI screen written for Simulacrum — the sacred CLI framework (scripts/cli/templates/.ts or scripts/python/templates/.py) — and produce a React component that lives inside components/examples/ (or components/) using only sacred's existing primitives — Window, Card, SimpleTable, ActionButton, RowSpaceBetween…