| name | web-action-testing |
| description | Use this skill whenever UX modernization needs real browser action validation, Webwright/Playwright-style testing, screen-action walkthroughs, screenshots, traces, or “try the UI and improve from the result.” Runs after UX changes or prototypes to exercise actual user flows and feed findings back into ux-modernization before review. |
Web Action Testing
Real UX quality cannot be proven by static design alone. This skill drives the
modernized UI in a real browser (Webwright / Playwright-style) and turns observed
friction into concrete improvement work.
When to use
- After
ux-modernization produces a prototype or code change.
- Whenever the user asks to "try the screen", "test the UI action", "use
Webwright/Playwright", "click through the flow", capture screenshots/traces, or
improve UX from actual browser behavior.
- This is a UX feedback gate: a UX change is not done until the browser-action
findings are resolved or explicitly accepted.
Preconditions
- The app can be launched locally, in a review environment, or against a safe test
environment.
- Test data is non-production or scrubbed. Do not use real recipient PII in browser
sessions.
- For code-mode UX work,
behavior-harness is green for the touched seams.
- If Figma review was requested or a Figma baseline is claimed,
figma-design-review
approved it. Otherwise use the approved requirements and ux-modernization
after-flow as the browser-action baseline.
Method
- Define action scenarios. Start from
requirements-grilling acceptance
criteria and ux-modernization after-flow. Cover the core path and at least one
failure/edge path.
- Drive the real UI. Use Webwright/Playwright-style browser automation when
available; otherwise perform the same actions manually and record evidence.
Capture screenshots, console errors, network failures, and trace/video if the
runner supports it.
- Measure UX friction. Count clicks, screen transitions, unexpected waits,
confusing labels, validation dead ends, and repeated context switches.
- Compare against the active UX baseline. Use approved requirements and the
ux-modernization after-flow by default; use approved Figma frames/components when
a Figma baseline exists. If a Figma baseline needs to change, route back to
figma-design-review; otherwise route design problems back to ux-modernization.
- Classify findings. Split into:
- Blocker: prevents task completion or corrupts workflow.
- Major: task completes but violates the target flow or creates operational risk.
- Minor: friction or polish issue that does not block the gate.
- Feed back into UX. Blockers and majors return to
ux-modernization; the flow
loops until resolved. Only then continue to strict-code-review.
Suggested action scenarios for nMIMO-like systems
- Message draft → review → approval → send request → result confirmation.
- Bulk-send scheduling with validation and preview.
- Realtime send-status dashboard: delayed/failure state, stale-data warning, refresh.
- System-status dashboard: process/session degradation and operator action.
- AI-assisted message draft: generate, edit, approve, reject.
Output
Use the Korean template and record:
- tested URL/environment and app version/commit;
- action scenario steps and result;
- screenshot/trace/video artifact paths;
- console/network errors;
- UX friction metrics;
- findings and disposition;
- retest result after fixes.
Gate rule
UX code mode cannot be marked done while any Blocker or Major finding is
open. If a finding is accepted rather than fixed, record the explicit reason in the
report and surface it to strict-code-review.
Output template and helper scripts
- Korean template: OUTPUT_TEMPLATE.md
- Report scaffold:
scripts/create-web-action-report.sh <repo-root> <target-name>
- Playwright starter spec scaffold:
scripts/create-playwright-smoke.sh <repo-root>
