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).
日本語の概要は準備中です。原文の説明を表示しています。
Design AI-first interfaces that build ongoing relationships through memory, trust evolution, and collaborative planning, not just isolated screen interactions
インストールする前に、エージェントに与えられる指示の中身を確認できます。
The paradigm shift from screen-centric to relationship-centric design.
Traditional UX optimizes individual screens and isolated interactions. Agentic UX designs for ongoing relationships where systems learn, remember, and evolve alongside users across sessions, devices, and contexts.
Core principle: Every interaction builds on learned preferences and user history. Systems don't just respond—they develop understanding that compounds over time.
Announce at start: "I'm using the Relationship Design skill to create an agentic, memory-aware interface that builds long-term relationships with users."
Use this skill when:
When NOT to use:
Old model: Store static preferences (theme: dark, language: EN)
New model: Maintain dynamic, evolving relationship models
Design for:
Key question: What would this experience look like if it remembered everything and got better over time?
Design interfaces that earn autonomy through graduated trust:
Stage 1: Transparency Phase
Stage 2: Selective Disclosure Phase
Stage 3: Autonomous Action Phase
Design patterns:
Key question: How might users develop trust with this system gradually?
Design ongoing partnerships, not isolated transactions.
From: User logs in → completes task → logs out → system forgets
To: System maintains continuous awareness of:
Implementation patterns:
Key question: What goals are users really trying to achieve, and how could an agentic system help them get there more effectively?
From: Design every possible user path explicitly
To: Design goal-alignment mechanisms where system dynamically constructs paths
Agentic systems:
Design for:
Key question: Can the system help users achieve goals they haven't fully articulated yet?
Traditional UX metrics (session duration, conversion rates, clicks) miss the point for agentic experiences.
Measure instead:
Relationship Quality
Compounding Value
Context Accuracy
Democratic Alignment
Key question: How do we know if the relationship is getting better, not just more frequent?
Ask these questions:
For your specific use case:
Choose 2-3 metrics from each category:
Track these over weeks/months, not just sessions.
Contextual Timeline
Emotional State Indicators
Dynamic Suggestions Panel
Reasoning Display (Transparency Phase)
Confidence Meter
Undo/Correct Patterns
Goal Dashboard
Planning Canvas
Preference Evolution Map
Problem: Storing preferences as key-value pairs (theme: dark) instead of evolving patterns
Fix: Design dynamic models that understand behavioral patterns, temporal context, and evolution over time
Problem: System is either fully transparent or fully autonomous from day one
Fix: Design three-stage trust evolution with gradual autonomy and user-controlled trust levels
Problem: Measuring session duration and conversion rates for relationship-based systems
Fix: Track relationship quality, compounding value, context accuracy over weeks/months
Problem: System remembers everything with no user control
Fix: Build forgetting controls, memory visualization, and clear data retention policies
Problem: Focusing on pixel-perfect interfaces without relationship architecture
Fix: Start with relationship model, then design screens that support ongoing partnership
Problem: When system makes mistakes, users lose all trust permanently
Fix: Design clear correction paths, system learning from mistakes, and trust recovery protocols
See EXAMPLES.md for:
See REFERENCE.md for:
See CHECKLIST.md for:
| Traditional UX | Agentic UX |
|---|---|
| Session duration | Relationship depth over months |
| Conversion rates | Trust scores and delegation comfort |
| Click-through rates | Compounding value (Month 6 vs Month 1) |
| Isolated screens | Continuous relationship context |
| Static preferences | Dynamic pattern evolution |
| One-size-fits-all | Individually adaptive interfaces |
| Explicit navigation | Goal-aligned path construction |
| Binary permissions | Graduated trust evolution |
The screens will always matter. But the relationships matter more.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
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`.
日本語の概要は準備中です。原文の説明を表示しています。