@salesforce/afv-skills 1.54.0 → 1.56.0

package/skills/experience-design-validate/references/state.md

@@ -0,0 +1,53 @@
+# State Management UX
+
+> **Load this reference for `DYNAMIC_VISUAL` evidence of state transitions. Static captures may support critique of a depicted state's visible treatment, but cannot substantiate state coverage, transition behavior, save behavior, recovery, or timing; mark those areas `INSUFFICIENT_EVIDENCE`.**
+
+The craft of state is the craft of in-between moments — the loading shimmer, the empty canvas, the recovered failure. A well-crafted product feels considered in these moments: the skeleton matches the layout, the spinner is sized for its container, the empty state has been designed rather than left as blank space, the error feels like part of the product instead of something escaping from the database.
+
+## Why this matters
+
+Most products are judged on their happy path, but craft reveals itself in the transitions and edge cases. A loading state that shimmers in the exact shape of what's coming feels like a designed product; a generic full-page spinner feels like an unfinished one. An empty state with a thoughtful illustration and a clear next action feels like a host welcoming you in; a blank screen feels like a dead end. When a design is polished in these moments, the product feels alive and tended to. When it isn't, every wait, error, and empty view chips away at trust.
+
+---
+
+## Loading
+
+- **The indicator matches the wait.** Instant feedback for micro-operations, an inline spinner for short waits, a skeleton for longer ones, real progress for anything substantial. A spinner that flashes for a fraction of a second is worse than silence.
+- **Skeletons mirror the shape of what's coming.** Same dimensions, same item count, same layout. When the real content arrives, nothing shifts.
+- **Progress is honest.** A determinate bar moves with confidence. Fake or jumpy progress trains users to distrust every indicator the product will ever show them.
+- **The page never goes blank between routes.** Navigation lights up the new destination immediately and uses a skeleton or crossfade for the body.
+
+## Errors
+
+- **Severity matches visual weight.** Inline notes for fields, banners for sections, page-level treatments for global failures. When everything is the same shade of red, nothing reads as urgent.
+- **Errors speak to the user, not the database.** A message names what went wrong and how to recover — never a stack trace, never an opaque code.
+- **Errors don't delete the user's work.** Submission failure preserves every valid field, scrolls to the first problem, and shows how many remain. Reversible mistakes get undo, not pre-confirmation.
+
+## Empty
+
+- **Empty is designed, not abandoned.** A short, situational headline; a sentence of context; a way forward. Blank space is a defect.
+- **The flavor of empty is communicated.** "Nothing yet" reads differently from "no matches" reads differently from "you don't have access." Empty tables keep their headers.
+
+## Offline and Sync
+
+- **Offline is a state, not an error.** It's communicated calmly — visible but not alarming, self-removing the moment connectivity returns. Local interactions still feel alive; pending changes are visible. No silent data loss, ever.
+- **Sync is invisible when it works.** Indicators only appear during active syncing, pending changes, or conflicts. Conflicts surface immediately with both values visible. Stale presence is worse than no presence.
+
+## Optimism and Long Jobs
+
+- **Optimism is reserved for the safe.** Reversible, rarely-failing changes show instantly. Destructive or financial changes don't. Rollback explains itself rather than reverting silently.
+- **Long work doesn't trap the user.** Operations beyond a handful of seconds become jobs the user can navigate away from. Progress, time, and current activity are visible. Completion finds the user wherever they went. Cancellation is always honest about what happens to partial results.
+
+---
+
+## Scoring Guide
+
+**Contributes to dimensions: Reliable, Usable**
+
+| Score | Criteria |
+|-------|----------|
+| 9-10 | The in-between moments are designed. Loading, errors, empty, offline, sync, and long jobs all feel considered. The product feels tended to even when nothing is happening. |
+| 7-8 | State handling is solid for primary flows with minor gaps at edges. |
+| 5-6 | Generic errors, blank empty states, basic save behavior. The polish drops away outside the happy path. |
+| 3-4 | States unmanaged. Silent failures. Blocking spinners. The product feels brittle. |
+| 1-2 | Lost connection loses work. States show nothing. Trust is broken. |

package/skills/experience-design-validate/references/trust.md

@@ -0,0 +1,47 @@
+# Trust & Safety
+
+> **Skip this reference if the design shows no auth surfaces, no privacy controls, no permission UI, no destructive settings, and no risk-bearing actions.**
+
+Craft in trust surfaces is the visual proof that a product takes consequences seriously. It shows up in the placement of a verification icon, the elevation of a danger zone, the restraint of a sensitive-data mask, the calibrated visual weight of a warning versus a critical confirmation. This reference judges the visual treatment of trust signals, the staging of authentication, and the progressive elevation of risk surfaces.
+
+## Why this matters
+
+Trust is a felt quality, not a feature — and craft is what makes a user feel safe before they read any copy. When craft is high, sensitive moments feel deliberate: the lock icon sits where the eye expects it, the danger zone is visually quarantined from the rest of the settings, warnings escalate in visual weight as stakes increase, and confirmations carry the right amount of friction without theatrics. When craft is low, trust surfaces feel either gaudy (every action a red banner) or careless (a destructive button styled like a save button). The visual register of risk is something users absorb subconsciously — a misstep here is the difference between confidence and unease.
+
+---
+
+## Trust Signals
+
+- **Visual polish is itself a trust signal.** Misaligned elements, mismatched typography, and broken layouts read as carelessness with everything else — including the user's data.
+- **Verification indicators sit where the eye expects them.** A single recognizable icon, placed consistently across the product, with a quiet explanation on hover.
+- **Sensitive data is masked by default.** A visibility toggle returns it on demand. Showing a credit card number or a phone number unprompted reads as careless.
+
+## Authentication
+
+- **Login is staged, not stuffed.** Identity first, credential second. A single mega-form for everything reads as bureaucratic.
+- **Password fields are forgiving.** A show/hide toggle and live validation reduce the anxiety of typing into a black box.
+
+## Consent
+
+- **Cookie banners don't trap the user.** Dismissing without accepting is as easy as accepting. "Essential only" carries the same visual weight as "Accept all." A banner that blocks content until the user accepts reads as coercive.
+
+## Risk Communication
+
+- **Severity escalates with consequence.** Informational notes, cautionary highlights, warnings that pause the user, and critical confirmations that demand typing — each carries a distinct visual weight. When everything is the same shade of red, nothing reads as urgent.
+- **Warnings appear before the point of no return.** Not after, not during — before. A warning that arrives after the action committed is theater.
+- **The same severity treatment is never used for unequal risks.** When archiving and deleting wear the same warning, the user stops trusting the warnings.
+- **Destructive settings are visually quarantined.** A "danger zone" set apart from ordinary settings — not interleaved with everyday toggles where a misclick is one row away.
+
+---
+
+## Scoring Guide
+
+**Contributes to dimensions: Reliable, Coherent, Well-Crafted**
+
+| Score | Criteria |
+|-------|----------|
+| 9-10 | Trust is earned through every interaction. Sensitive moments feel deliberate. Risk is calibrated. The danger zone is unmistakable. |
+| 7-8 | Trust patterns are mostly consistent with minor gaps in disclosure or symmetry. |
+| 5-6 | Bundled consent. Inconsistent warning severity. A few dark patterns. |
+| 3-4 | Dark patterns. Invasive defaults. The product feels indifferent to consequence. |
+| 1-2 | Trust is actively broken. Hidden data collection. Misleading consent. |

package/skills/experience-design-validate/references/usability.md

@@ -0,0 +1,35 @@
+# Usability
+
+> **Skip this reference if the design has no decisions to make, no actions to take, and no flow to navigate — i.e. nothing for craft to make smoother.**
+
+Usability craft is the difference between a product that you operate and one that operates with you. It's the visible system status that tells you the save went through, the predictable interaction that lets you trust your muscle memory, the consistent pattern that makes the second use easier than the first. Good usability craft is invisible when it works — you just feel competent. Poor usability craft makes you feel stupid for not knowing where the controls are.
+
+## Why this matters
+
+Designs win or lose on the small moments of feedback and predictability. When a click produces an immediate visible response, when a state change is announced through motion or color, when consistent patterns mean the user never has to relearn — the product feels responsive and trustworthy. When those moments are missing, every interaction carries doubt: did it work, am I in the right place, is this the same control I used yesterday. Craft here is about respect — respecting the user's time, attention, and prior learning by making the system answer back when spoken to.
+
+---
+
+## Feedback and Predictability
+
+- **The system answers back when spoken to.** Every action produces a visible response — a state change, a confirmation, a transition — within the moment of the click. Silence reads as broken.
+- **Patterns repeat.** The same kind of action looks and behaves the same across the product. When a "save" feels different on two screens, the user has to relearn instead of trust their muscle memory.
+- **The user's place in the system is always visible.** Where they are, what's selected, what they just did. A page that wipes context after every interaction asks the user to rebuild it constantly.
+- **Edges are designed.** Empty states, errors, loading, and success all feel like part of the same product — not afterthoughts grafted onto the happy path.
+- **Hierarchy matches priority.** What's important looks important. When secondary actions outweigh primary ones visually, the user has to fight the design to do the right thing.
+- **Interactive elements look interactive.** A button that looks like a label, a link that looks like static text, a card that hides a click target — each forces the user to discover by trial.
+- **Simpler is preferred when both work.** Two controls where one would do, three options where two cover the cases — the extras add cognitive load without adding capability.
+
+---
+
+## Scoring Guide
+
+**Contributes to dimensions: Usable, Useful, Well-Crafted**
+
+| Score | Criteria |
+|-------|----------|
+| 9-10 | Edges are designed. Interactive elements look interactive. Hierarchy matches priority. The product responds to every input with visible craft. |
+| 7-8 | Most flows feel responsive and predictable. Minor gaps in edge-state polish. |
+| 5-6 | Happy path is fine; edges feel unfinished. Some controls don't feel interactive. |
+| 3-4 | Inconsistent feedback. Edge states neglected. Hierarchy fights the user. |
+| 1-2 | No visible system response. Interactions feel unanswered. |

package/skills/experience-design-validate/references/visual-system.md

@@ -0,0 +1,183 @@
+# Visual System
+
+> **Always load for any visual design. Skip only if the input is purely textual or pre-visual (a wireframe with no visual decisions yet made).**
+
+What does the design look like? This reference judges the felt qualities of the visual system — layout, typography, color, surfaces, and visual assets — at the level a designer would discuss them in a critique. Not at the level of CSS variables.
+
+## Why this matters
+
+The visual system is the voice of the product. It's what users see before they read a word. A coherent visual system feels like one person made it; a fragmented one feels like a committee shipped it. Two designers can have the same layout brief and end up in completely different places — one with a system that feels intentional and quiet, one with a system that feels accumulated and loud.
+
+Visual system findings are about *taste applied consistently*. The eye notices when the type sizes don't relate to each other, when the grays are slightly off from each other, when borders happen sometimes and not other times, when icons are different weights, when avatars are different sizes. None of these failures is catastrophic alone. Together, they're what separates "looks pro" from "looks built."
+
+---
+
+## Layout
+
+### What good layout feels like
+
+- **One focal point per screen.** The eye knows where to land first. Everything else is calmer.
+- **Generous whitespace around what matters.** Primary actions and headlines have air around them. Density is reserved for content where users need to compare or scan many items at once.
+- **A consistent rhythm.** The vertical beat of the page is predictable — sections are spaced consistently, and the spacing between a heading and its content is tighter than the spacing between sections.
+- **Aligned, not approximate.** Elements share precise edges, not "near enough" edges. The eye can detect 2-pixel misalignment even when it can't name it.
+- **Density matched to context.** A dev tool earns dense, utilitarian layout. A consumer onboarding screen earns generous breathability. The layout reflects what the product is trying to be.
+
+### Felt observations to make
+
+- The eye knows where to land within the first second.
+- Primary content is clearly heavier than chrome (toolbars, headers, sidebars).
+- Headings are closer to their content than to the section above.
+- Page margins are equal and don't change between similar pages.
+- Whitespace around primary actions feels deliberate, not accidental.
+- The grid feels consistent — columns don't shift between similar pages.
+- Toolbar heights, sidebar widths, and content margins feel consistent across screens.
+- Sticky headers stay put; scroll position is preserved when navigating away and back.
+
+### What weak layout looks like
+
+- The eye doesn't know where to start. Multiple things tied for primary.
+- Sections butt up against each other; nothing breathes.
+- Spacing varies subtly between similar screens — same component, different padding.
+- Elements are *almost* aligned (a few pixels off) — looks like a mistake, not a choice.
+- Page margins are uneven; one page has a wide gutter, another has none.
+- Density mismatches the context — a marketing page is dense, a dashboard is sparse.
+
+---
+
+## Typography
+
+### What good typography feels like
+
+- **A small set of sizes, used consistently.** The product has 4–6 distinct text sizes that map to clear roles: page heading, section heading, body, label, metadata. Each role has one size. The reader knows what kind of text is what at a glance.
+- **A tight set of weights.** Two or three weights. Bold for headlines, regular for body, perhaps medium for emphasis. Weight isn't sprinkled across the design.
+- **Headlines have presence.** They feel like something to land on, not something to scroll past. The line break is intentional.
+- **Body text is readable.** Lines are at a comfortable length (not edge-to-edge across a wide screen). Line-height is generous enough that reading feels relaxed.
+- **One voice across the product.** The product speaks in one type voice, not three.
+
+### Felt observations to make
+
+- Type sizes feel like steps in a scale, not arbitrary choices.
+- Headings stand out clearly. The hierarchy is unmistakable.
+- Body text feels comfortable to read at a glance.
+- The number of weights in active use feels small.
+- Numbers in tables align (don't twitch as values change).
+- Truncated text is signaled cleanly with an ellipsis, with full content available on hover or expand.
+- Text doesn't run edge-to-edge across the entire viewport on wide screens.
+
+### What weak typography looks like
+
+- The product has many sizes that don't relate to each other — 13px, 14px, 15px, 16px all visible.
+- Three or four weights mixed without clear logic.
+- Headings and body text feel similar in weight or size — flat hierarchy.
+- Body text runs the entire width of a wide screen, exhausting to read.
+- Numbers in tables shift position as values change — feels unfinished.
+- Capitalization is inconsistent: "Save Changes" here, "save changes" there, "SAVE" elsewhere.
+
+---
+
+## Color
+
+### What good color feels like
+
+- **A small, intentional palette.** The product uses few colors and uses them consistently. Each color earns its place — brand, action, error, success, neutral. Nothing decorative.
+- **Surfaces feel intentional.** Three or four surface tones — page background, card, hover, selected — each visibly distinct. The eye doesn't have to ask "is this a different gray?"
+- **Color signals meaning.** Green is positive, red is negative, the brand color is reserved for primary moments. The mapping is consistent everywhere.
+- **Restraint with accent color.** The brand color appears where it matters — primary actions, key indicators — not as decoration.
+- **Considered dark mode (if present).** Dark mode is its own design, not a color-inverted afterthought.
+
+### Felt observations to make
+
+- The palette feels tight and disciplined.
+- Surface tones feel distinct from each other — no near-duplicates.
+- The brand or accent color is used sparingly and purposefully.
+- Status colors (positive, negative, warning) are consistent across the product.
+- Dark mode (if present) feels like its own designed surface.
+- Information isn't carried by color alone — pair with icon, label, or position.
+
+### What weak color looks like
+
+- Many near-identical grays accumulating across surfaces — the eye registers wear.
+- The accent color is everywhere, including decorative uses, so primary actions don't stand out.
+- Status colors flip meaning between views (green meant "complete" here, "ready to start" there).
+- Dark mode looks like a contrast inversion of light mode, not a designed surface.
+- The palette feels accumulated — colors added by different contributors over time.
+
+---
+
+## Surfaces
+
+### What good surfaces feel like
+
+- **Cards, panels, modals all feel like one family.** Same border treatment, same radii, same elevation language. A card on one screen is recognizable as a card on another.
+- **Elevation has intent.** When something is lifted (modal, popover, sticky element), the elevation is clear and consistent. Shadows are tasteful, not heavy.
+- **Borders are restrained.** Not every container has a border. When a border appears, it earns its place — separating things that need separating.
+- **Radii are limited.** The product picks one or two corner radii and sticks to them. Cards aren't 4px-rounded in one place and 12px-rounded in another.
+
+### Felt observations to make
+
+- Cards across the product feel like the same family.
+- Modals and popovers feel like the same family.
+- Borders appear where separation is needed, not as decoration.
+- Shadows are subtle and consistent — same elevation gets the same shadow.
+- Corner radii are consistent within a context.
+
+### What weak surfaces look like
+
+- Cards on different screens have different radii, different shadows, different border treatments — the family is fragmented.
+- Borders everywhere — every container framed for no reason.
+- Shadows are too heavy or inconsistent — some elements feel like they're floating in front of glass, others feel painted on.
+- A modal looks like a card looks like a popover looks like a panel — no elevation hierarchy.
+
+---
+
+## Visual Assets
+
+### What good visual assets feel like
+
+- **Icons are one family.** Same stroke weight, same style (outlined vs filled), same proportions. They look like a set, not a collection.
+- **Icons are sized consistently in the same context.** A toolbar icon is the same size as another toolbar icon.
+- **Imagery has intent.** Photos and illustrations feel chosen, not searched-and-pasted. They support the content, not decorate it.
+- **Avatars are consistent.** Same size, same shape, same fallback treatment.
+- **Empty states have personality.** When the product needs to fill space because there's nothing to show, the design uses the moment — a small illustration, a clear invitation, a personality.
+
+### Felt observations to make
+
+- Icons feel like a set — consistent stroke weight and style.
+- Icons in similar contexts are similar sizes.
+- Avatars are the same shape (round vs square) across the product.
+- Imagery feels chosen, not generic.
+- Empty states are designed moments, not blank screens with "No items."
+
+### What weak visual assets look like
+
+- Icons mix outlined and filled styles randomly. Stroke weights vary.
+- Toolbar icons are different sizes from each other.
+- Stock photography that doesn't match the brand voice.
+- Avatars are round in one place, square in another.
+- Empty states are blank, with a generic "No data" string.
+
+---
+
+## Cross-cutting felt qualities
+
+When evaluating the visual system as a whole, ask:
+
+- **Does the system feel like it has a point of view?** Or does it feel like an accumulation of contributions?
+- **Could a new contributor extend this system without guessing?** The patterns should be self-documenting.
+- **Does the visual vocabulary feel small?** Disciplined products use few sizes, weights, colors, and shapes — and use them everywhere.
+- **Is anything shouting that doesn't need to?** Bold weights, accent colors, large sizes, and heavy borders should be reserved.
+- **Where does the eye land first? Second? Third?** If you can't answer, hierarchy is broken.
+
+---
+
+## Scoring Guide
+
+**Contributes to dimensions: Well-Crafted, Coherent**
+
+| Score | Criteria |
+|-------|----------|
+| 9–10 | The visual system feels disciplined and intentional. Small vocabulary used consistently. Hierarchy is calm; restraint is visible. Surfaces, type, color, and assets all read as one family. The eye lands where it should. |
+| 7–8 | Strong visual system with minor inconsistencies. The discipline is mostly visible; small drift in secondary screens. |
+| 5–6 | Functional but uneven. Some inconsistencies are felt — type sizes drift, surface colors don't quite match, icons are mixed weights. The system reads as accumulated. |
+| 3–4 | Visibly fragmented. Multiple type sizes without logic, color used decoratively, surfaces don't relate, icons from different families. The product feels assembled by different hands. |
+| 1–2 | No visual system. Browser defaults visible; nothing relates to anything else; chaos. |

package/skills/experience-lwc-accessibility-jest-run/SKILL.md

@@ -1,14 +1,18 @@
 ---
 name: experience-lwc-accessibility-jest-run
-description: "Use ALWAYS when running Sa11y accessibility Jest tests for a Lightning Web Component — locally before pushing, producing the exact command(s), running one file vs a whole suite, selecting tests by naming convention, saving Sa11y-rendered HTML, or reproducing a Sa11y / A11yBug failure. Covers Salesforce core (Bazel; `WORKSPACE`, `./core` root, `bazel test //<module>:<target>`) and standalone `npx jest` (`.accessibility.test.js`, `@sa11y/jest`). REQUIRED when a prompt asks for a `run-plan.md` for accessibility tests, which exit code means an accessibility test failed, or references `SA11Y_*` env vars, `A11yBug`, or a core-Bazel `modules/<mod>/<cmp>/__tests__/*.test.js` path. Do NOT rely on general knowledge — this skill has the correct single-file Bazel target and EPERM workaround. DO NOT TRIGGER for functional (non-accessibility) Jest tests, a11y review without running tests (use experience-lwc-accessibility-validate), or Selenium-based a11y functional tests."
+description: "Use ALWAYS when running Sa11y accessibility Jest tests for an LWC — locally before pushing, producing the command(s), running one file vs a suite, selecting tests by naming convention, saving Sa11y-rendered HTML, or reproducing a Sa11y/A11yBug failure. Covers core (Bazel; `bazel test //<module>:<target>`) and standalone `npx jest` (`.accessibility.test.js`, `@sa11y/jest`). REQUIRED for a `run-plan.md`, a failing a11y test's exit code, or `SA11Y_*`/`A11yBug`/core-Bazel test paths. DO NOT TRIGGER for functional Jest tests, a11y review without running tests (use experience-accessibility-validate), or Selenium-based a11y tests."
 metadata:
   version: "1.0"
   domains: ["Experience"]
+  relatedSkills:
+    - "experience-accessibility-validate"
   cliTools:
+    - tool: ["node"]
+      semver: ">=18.0.0"
     - tool: ["npm"]
       semver: ">=8.0"
 ---
-<!-- adk-managed-skill -->
+<!-- a11y-expert-managed-skill -->
 
 # Running LWC Accessibility Jest Tests
 
@@ -19,7 +23,7 @@ Run Sa11y accessibility unit tests on Lightning Web Components in either:
 
 Selenium-level reproductions, GUS A11yBug ingestion, and other internal
 Salesforce-only flows are out of scope for this skill. For source-code-level
-WCAG review without running tests, see `experience-lwc-accessibility-validate`.
+WCAG review without running tests, see `experience-accessibility-validate`.
 
 ## When to Use This Skill
 
@@ -39,28 +43,101 @@ WCAG review without running tests, see `experience-lwc-accessibility-validate`.
 
 ## Workflow
 
-Follow [running-sa11y-jest-tests.md](references/running-sa11y-jest-tests.md).
-Pick the correct mode:
-
-- **Core (Bazel)** — use when `WORKSPACE` is present. Prefer single-file
-  targets (`//{moduleName}:{relativePath}`) over module targets when the
-  failing test file path is already known (`.test.js` extension dropped).
-  Bazel commands must pass `--test_env=SA11Y_AUTO=1
-  --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1`; when debugging, add
-  `SA11Y_ENABLE_RENDERED_DOM_SAVE=1` with the documented save path to avoid
-  EPERM issues.
-- **Standalone (Jest)** — use when there's no `WORKSPACE`. Run
-  `npm test -- --testMatch="**/*.accessibility.test.js"` for the whole suite,
-  or `npm test -- <file>` targeting the file by the name/path given in the
-  prompt (a **bare filename** when it is "in this directory"). Do **not**
-  prepend `SA11Y_*` env vars in standalone mode — Sa11y runs automatically
-  because `@sa11y/jest` is wired into the project's Jest setup; no extra
-  environment variables are needed.
-
-**Answer only what is asked.** Emit just the command(s) the prompt requests plus
-the exit-code meaning. Do not pad the plan with unrequested variants (watch,
-coverage, verbose), snapshot-update steps, or HTML-save sections unless the user
-explicitly asks for them.
+Choose the approach based on the environment. If this is not a Salesforce core
+build environment, do not mention the Core workflow.
+
+### Core (Bazel)
+
+Use this mode when a `WORKSPACE` file is present. The base command is:
+
+```bash
+{coreRootPath}/tools/bazel test [TARGET] --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+Replace `{coreRootPath}` with the Core repository root, `{moduleName}` with the
+module name, and `{relativePath}` with the test file path without the `.test.js`
+extension.
+
+To discover targets and paths:
+
+```bash
+find {coreRootPath}/{moduleName} -name "*.test.js" -type f
+{coreRootPath}/tools/bazel query "tests(//{moduleName}:*)"
+```
+
+Component tests typically live under
+`modules/{componentDir}/{componentName}/__tests__/`.
+
+Prefer a single-file target when the failing test path is known:
+
+```bash
+{coreRootPath}/tools/bazel test //{moduleName}:{relativePath} --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+Run all Sa11y Jest tests in a module when a specific test is not known:
+
+```bash
+{coreRootPath}/tools/bazel test //{moduleName}:sa11y_jest_test --test_output=streamed --test_env=SA11Y_AUTO=1 --test_env=SA11Y_ENABLE_DOM_MUTATION_OBSERVER=1
+```
+
+Multiple module targets can be passed to the same command. To filter tests
+within a module, add `--test_arg=--testMatch="**/{modulePath}/**"`.
+
+Useful options:
+
+- Update snapshots: `--test_arg="--updateSnapshot"`
+- Disable cached test results: `--cache_test_results=no`
+- Save rendered HTML:
+  `--test_env=SA11Y_ENABLE_RENDERED_DOM_SAVE=1 --test_env=SA11Y_RENDERED_DOM_SAVE_PATH=sfdc-test/unit/javascript/htdocs/sa11y/jest`
+
+Use `sfdc-test/unit/javascript/htdocs/sa11y/jest` as the rendered DOM save path
+to avoid EPERM errors.
+
+### Standalone (Jest)
+
+Use this mode when no `WORKSPACE` file is present. Run all accessibility tests:
+
+Do **not** prepend `SA11Y_*` environment variables in standalone mode;
+`@sa11y/jest` is activated through the project's Jest setup.
+
+```bash
+npm test -- --testMatch="**/*.accessibility.test.js"
+```
+
+Or target a specific file:
+
+```bash
+npm test -- src/components/MyComponent/__tests__/MyComponent.accessibility.test.js
+```
+
+Use the filename or path supplied by the user. When the named test is in the
+current directory, keep a bare filename bare instead of inventing a path.
+
+Other useful options are `--coverage`, `--updateSnapshot`, `--watch`, and
+`--verbose`. To target a named test, use
+`npm test -- --testNamePattern="MyComponent accessibility"`.
+
+Ensure Jest uses a `jsdom` environment and loads the project's `@sa11y/jest`
+setup file. Copy or adapt the bundled `assets/jest.config.js` template into
+the project's Jest configuration, and copy `assets/sa11y-jest-setup.js` to
+`test/setup/sa11y-setup.js`. If the project already has a Jest configuration,
+merge the relevant settings instead of overwriting unrelated configuration.
+
+The `SA11Y_*` variables shown above are for Core/Bazel only; the Bazel commands
+already include them.
+
+## Response Scope
+
+Answer only what the user asked. Emit the requested command or commands plus
+the relevant exit-code meaning. Do not add watch, coverage, snapshot-update,
+HTML-save, or other variants unless the user requests them.
+
+## Expected Exit Codes
+
+- Bazel: `0` means all tests passed, `3` means tests failed, and `1` means the
+  build or command failed.
+- Jest: `0` means all tests passed and `1` means tests failed or an error
+  occurred.
 
 
 ## Verification Checklist
@@ -77,3 +154,5 @@ explicitly asks for them.
   `.test.js` extension in `{relativePath}`.
 - **HTML saving fails with EPERM** — use the prescribed save path
   `sfdc-test/unit/javascript/htdocs/sa11y/jest`.
+- **Standalone tests do not run** — verify the test naming pattern, Jest
+  configuration, `@sa11y/jest` dependency, and `jsdom` environment.

package/skills/experience-lwc-accessibility-jest-run/assets/jest.config.js

@@ -0,0 +1,4 @@
+module.exports = {
+  setupFilesAfterEnv: ["<rootDir>/test/setup/sa11y-setup.js"],
+  testEnvironment: "jsdom",
+};

package/skills/experience-lwc-accessibility-jest-run/assets/sa11y-jest-setup.js

@@ -0,0 +1,5 @@
+import { configure } from "@sa11y/jest";
+
+configure({
+  rules: ["wcag2a", "wcag2aa", "wcag2aaa"],
+});

package/skills/experience-ui-bundle-app-coordinate/SKILL.md

@@ -163,16 +163,16 @@ Search project code (src/) for existing implementations
     v
 Install dependencies (npm install)
     v
-Search, describe, and install features (auth, shadcn, search, navigation, GraphQL)
+Search, describe, and adopt features (auth, shadcn, search, navigation, GraphQL)
     v
 Resolve conflicts (two-pass: --on-conflict error, then --conflict-resolution)
     v
 Integrate __examples__ files into target files (verify build succeeds), then delete them
 ```
 
-Installs pre-built, tested feature packages. See "Prompt Classification Keywords" above for the full trigger keyword list and negative-phrasing handling — these features provide the foundation that UI components build on top of.
+Loads the feature skill to install pre-built packages, or adopt ones the template already shipped — never build your own version of a catalog feature. See "Prompt Classification Keywords" for triggers and negative-phrasing handling.
 
-Only skip this phase if the app is truly a minimal "hello world" with no interactive features (no trigger keywords present at all).
+Skip only for a minimal "hello world" with no interactive features; pre-shipped features still require this phase.
 
 ### Phase 2.5: Custom Objects (Required if the prompt requires a new custom Salesforce object the org doesn't have)
 
@@ -378,14 +378,14 @@ Execute each phase sequentially following the standard pattern in `references/ph
 ---
 
 **Phase 0 -- Template Offer & Bootstrap**
-- Load `experience-ui-bundle-project-generate`, offer templates. If chosen: skip Phase 1, continue at Phase 4. If declined: run `scripts/check-sfdx-project.sh`, create project if missing.
+- Load `experience-ui-bundle-project-generate`, offer templates. If chosen: skip Phase 1, continue at Phase 2. If declined: run `scripts/check-sfdx-project.sh`, create project if missing.
 
 **Phase 1 -- Scaffolding** (skip if template used in Phase 0)
 - **Precondition**: `scripts/check-sfdx-project.sh` passes
 - Load `experience-ui-bundle-metadata-generate`. Determine hosting target FIRST. Run `sf template generate ui-bundle --template reactbasic`, configure meta XML with `<target>`.
 - **Post-verification**: `scripts/check-phase-1-complete.sh` passes
 
-**Phase 2 -- Features** (skip if no feature keywords present — see "Prompt Classification Keywords")
+**Phase 2 -- Features** (run on any feature keyword, even if pre-installed — see "Prompt Classification Keywords")
 - Load `experience-ui-bundle-features-generate`. Install features, integrate examples. Verify with `npm run build`.
 
 **Phase 2.5 -- Custom Objects** (skip if org has all needed objects)