Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Develop an independent visual language and turn the human-chosen direction into a production-ready graphic, brand, campaign, publication, web, or product system. Use when originality and differentiation matter enough to escape generic AI and Big Tech aesthetics. Guides a minimum-evidence start, ten isolated typography-led HTML design directions made only from type, color, and space, visual-first human judgement, explicit commitment, and concrete Round 2 production. Do not use for routine UI fixes, small components, or applying an existing design system.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Create a visual language that could only have emerged from this subject and context. Temporarily isolate authorship from contemporary design culture, let one author develop ten independent typography-led HTML design directions through type, color, and space, show them visually before explaining them, and let the human decide when generation stops.
<canvas> element.<svg> markup.Read references/ISOLATION-PROTOCOL.md before collecting creative evidence or looking for fonts. Read references/CONCEPT-ROUNDS.md before checking evidence or generating directions. Read references/PRODUCTION-SYSTEM.md only after one direction has been explicitly locked. Read references/VERIFICATION.md before showing the Round 1 HTML files or claiming a Round 2 production result is complete.
Internally identify the furthest state the human has explicitly approved:
Continue from that state. Do not restart the journey when the human already approved a premise or direction. Do not infer commitment from enthusiasm.
Do not announce phase numbers, the number of steps remaining, or an estimated time for answering questions. The workflow serves the design; the user should not have to manage the workflow.
Treat the existing message as sufficient when it gives:
The preferred starting input is one high-level purpose statement, not an aesthetic direction or a production questionnaire:
This is for [subject and audience]. It should help them understand, feel, or do [goal].
If the user has not supplied a usable subject and intent, ask for this one statement and begin when they answer. If they already supplied it in ordinary language, do not ask them to reformat or repeat it. This shared purpose influences language dominance, hierarchy, rhythm, and which subject evidence each direction translates, but it must not make A through J visually similar.
The user's own wording is a valid formal seed. Do not demand separate history, story, material, or content evidence when the brief already offers language or tension that can generate form.
Ask before round one only when the subject or intent is fundamentally unclear, two plausible readings would create opposite work, or an assumption risks harm or false representation. Ask one batch of no more than two short questions. Do not ask a second batch before round one. If answers remain incomplete, use reversible assumptions and proceed.
Do not request final campaign copy, every channel and dimension, quantities, schedules, budgets, technical stacks, complete asset inventories, participant biographies, permissions, legal text, or exhaustive accessibility requirements before generating directions unless one fact is necessary to prevent immediate harm or false representation. Collect production facts after the human has reacted to the typography.
Use anonymous roles or obvious placeholders when real people, names, or permissions are not ready; never invent personal facts. Preserve exact user copy. When working copy, translation, or board size is missing, choose one provisional option for all ten directions and disclose that assumption after the first visual reaction rather than seeking another round of permission.
Record only the evidence already available and an internal design premise. Do not announce a persuasive aesthetic thesis before the first visual reaction.
If the user asks for an ordinary implementation of an already committed system, use that system and skip concept creation.
Declare the allowed evidence and prohibited sources. Stop browsing contemporary design. Functional research may establish facts, constraints, availability, licensing, or compatibility, but it must not become a visual reference hunt.
If a font is necessary for round one, first derive its formal and language requirements without opening a type catalogue. Then use the controlled font exception in the isolation protocol. Do not browse fonts for inspiration.
Use one author to produce ten professional typography-led HTML design directions labelled A through J. Build Round 1 with dependency-free HTML and CSS only. Technology is only a neutral rendering material.
The ten directions share the same working copy and may share an optional comparison viewport for fair judgement. They do not share a fixed canvas, artifact ratio, layout, or palette. Each direction owns its complete browser-page composition and its own flat background color. It must reveal:
Round one must contain no non-typographic visual elements. Do not create CSS shapes or use borders, rules, lines, boxes, panels, bands, circles, blobs, pseudo-elements, gradients, shadows, filters, masks, clipping paths, textures, patterns, icons, logos, photography, illustration, generated imagery, or animation. Do not use punctuation as decorative geometry. Apart from a flat background color, color must live on text. The HTML body should contain only the text required for the direction and neutral structural containers.
Do not artificially stretch, warp, skew, or distort letterforms. Use genuine font styles, widths, weights, optical sizes, grades, italics, slants, and variable-font axes. Controlled overlap, ordinary overflow cropping, and vertical text are allowed only as readable typesetting, never as abstract letterform illustration.
Do not show swatches, labelled type samples, category labels, annotations, grids, tokens, font names, or design-system explanations. The human should experience each direction directly while a professional can infer its palette, type combination, scale, case, hierarchy, spacing, and whitespace logic.
Create a concise concept capsule alongside every direction. Record:
The capsule is operational context, not sales copy. Do not give the direction a style name, invoke prestige, claim meaning that is not grounded in evidence, or use confident prose to compensate for weak visual work.
Each direction must independently decide:
The ten directions may share only the real content, evidence capsule, and essential legibility or functional boundaries. They must not share a layout skeleton, font combination, size scale, case strategy, palette, alignment logic, reading path, or whitespace rhythm. Every direction must differ materially in color as well as typography and space. Do not use a divergence matrix, numeric quotas, dice, style menus, or mechanical parameter rotation to manufacture those differences. Begin every direction from its own subject-derived premise and a blank HTML file.
Across A through J, include at least one credible one-color, two-color, three-color, and four-color letterform system. Count active letterform colors, not the single flat canvas background: a one-color direction uses one text color on its ground; a two-color direction establishes primary and secondary text roles; a three-color direction adds a distinct tertiary or accent role; and a four-color direction gives primary, secondary, tertiary, and accent colors different jobs. The other six directions may use any of these depths when their premises justify them. This is set-level coverage, not a divergence matrix: do not assign palette sizes mechanically or let color count substitute for a distinct premise. Every role must be visible in the supplied copy, used in a deliberate proportion, and change hierarchy, rhythm, or language behavior. Do not add swatches, labels, dummy text, or random highlighted words to prove that a color exists.
When a direction uses primary, secondary, tertiary, or accent colors, their different roles should be visible during the first visual encounter. A color does not count merely because it exists in the CSS or appears on one insignificant fragment. Each role should govern enough meaningful supplied text to affect hierarchy, rhythm, language, or reading order—without arbitrary highlighting.
Reject and rebuild any direction that:
Create A.html through J.html and a neutral index.html, then link the actual HTML files for the human to open. Round 1 delivers HTML, not PNG, WebP, JPEG, PDF, screenshots, contact sheets, or any other image export. The human may use a consistent browser viewport for fair comparison, but it must not become a fixed canvas or shared design template.
Stop after source-level validation. Do not open the HTML yourself or use Claude in Chrome, Chrome, browser automation, Computer Use, Playwright, Puppeteer, screenshots, image analysis, or any rendering tool to inspect or compare A through J. Do not claim that typography, composition, legibility, optical balance, or visual independence passed inspection. Those are human judgements.
Do not show code, a written premise, a style label, a font name, a reference, or a persuasive explanation before the human reacts. Do not stage the directions as buttons, forms, cards, navigation, dashboards, landing-page sections, device mockups, fake product controls, posters, illustrations, scenes, logos, or production mockups. Do not claim production readiness.
Ask for the human's immediate visual response: which direction stays in memory, what feels alive, what feels false, and whether one deserves to continue. Explicitly tell them that they do not have to choose from this set: if none deserves commitment, they may reject all ten and ask for another ten. There is no fixed limit to the number of ten-direction rounds.
The concept capsules are part of the saved round-one package, but do not reveal them before this first response. After the human reacts, show the neutral capsules for the directions they want to consider. This preserves unprimed visual judgement while retaining written context for later work.
If all ten fail, return to the evidence capsule and premise. Create a new set of ten only after learning from the rejection and only when the human asks to continue. Repeat for as many rounds as the human requests; keep each batch at ten so the judgement remains manageable. Do not pressure the human to select a weak direction merely to advance the workflow.
Do not treat interest, praise, or a shortlist as a lock. The human may compare capsules, request a bounded typography-only refinement, reject all ten, or explicitly lock one direction.
When one direction is explicitly locked:
ROUND-2-CONTEXT.md;Inject the locked concept capsule as governing context, then create the concrete artifacts the project actually needs. If the artifact is not already clear, ask one short question after the lock rather than another creative interview.
Round 2 may produce, for example:
Shapes, lines, imagery, icons, material effects, and motion may enter only in Round 2 and only when the artifact requires them or the human approves them. Derive them from the locked typography and concept capsule; do not let them import a new style or replace the typographic character.
For interfaces, build real components with real states, content, responsive behavior, keyboard access, visible focus, and recoverability rather than a decorative component sheet. For graphic artifacts, use real format constraints and verify the intended size and medium. Continue with HTML and CSS source plus rendered raster previews when practical. Do not switch to SVG for complex shapes or production adaptation.
Use the original prompt as the authority for the requested artifact set. If it requested three items, rebuild those same three items with the real copy; do not turn them into three new directions or silently add more. When real copy is missing, ask for it or ask whether the placeholder should remain temporarily. After rebuilding, give the artifacts to the human and ask whether the locked direction's character survived. Do not freeze the work or claim human acceptance until the human explicitly approves it.
When the human approves the rebuilt artifacts, freeze the approved files and their generation rules as the production baseline. Record what is invariant, what may vary, and what requires an explicit reopening decision. Then create a self-contained HTML style guide based on the locked direction and link it to the human. The guide must include every applicable rule from the concept capsule and production constitution: premise and source boundary; typography and font licensing; color; hierarchy; composition; spacing; margins; padding; gaps; gutters; columns; alignment; density; rhythm; whitespace; language behavior; responsive or contextual variation; shapes, lines, material, imagery, icons, motion, and interaction when applicable; accessibility and recoverability boundaries; invariants; allowed variation; prohibited normalization; asset and license status; generation rules; proof status; open issues; and reopening conditions. Render the guide in the locked visual language without importing a new style. Include copyable prompt examples showing how to request another artifact, adapt an approved artifact, revise without reopening the direction, and continue in a new thread using ROUND-2-CONTEXT.md and STYLEGUIDE.html. Tell the human that they may request further artifacts from this visual language at any time. Do not create additional artifacts until requested.
Reopen the locked direction only for new evidence, cultural harm, an accessibility or implementation failure, a changed business need, or an explicit human override. Offer a small project-local ledger, but create it only with approval.
As part of Round 2, turn the committed language into the smallest system that can reliably generate the required artifacts. Use the existing project stack when one exists. Do not add a framework, third-party component library, icon family, font, or production dependency without approval.
For Round 2 graphic production, keep HTML and CSS as the editable source when practical and export PNG, WebP, or JPEG for digital use and PDF for print when appropriate. These export formats do not apply retroactively to Round 1. If the project needs a professionally drawn scalable vector master, specify the approved geometry and require completion in a professional vector tool; do not fake that master by emitting SVG path code.
An existing user-supplied or licensed third-party SVG may be treated as an immutable input only after the direction is locked and the human approves its use. Do not alter it, trace it, inline it, derive new SVG from it, or present it as work created by this skill.
Create actual working files when the environment permits. Otherwise give the human a precise production package and name what remains to be built. Preserve the concept even if the system is not yet complete.
Report the outcome honestly:
Never call a Round 1 direction production-ready. Never discard an original concept merely because the full system remains unfinished.
Lead with what now exists and the current proof level. For Round 1, link the actual HTML files and state that visual review remains with the human. For Round 2, show the concrete artifact as appropriate, explain the next steps, and distinguish placeholder, rebuilt, human-approved, and frozen states. State any remaining production, licensing, accessibility, or verification work. After approval and freezing, create and link the required HTML style guide, state that the human may request further artifacts without generating them automatically, and provide a small set of copyable continuation prompts. End with the one decision or action the human must take next; if none remains, say that clearly.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
日本語の概要は準備中です。原文の説明を表示しています。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
日本語の概要は準備中です。原文の説明を表示しています。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
日本語の概要は準備中です。原文の説明を表示しています。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
日本語の概要は準備中です。原文の説明を表示しています。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
日本語の概要は準備中です。原文の説明を表示しています。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
日本語の概要は準備中です。原文の説明を表示しています。