← the whole session plugin/skills/feature-completion-ux-test/SKILL.md

End-to-end UX validation workflow. Use when confirming a change is truly complete: define intended UX, set conditions, execute the action, inspect request payloads, and verify the project's own logs and admin/observability surfaces. If the project has a doc mapping which surface logs which kind of event (one example is $how-to-log-to-each-internal-log), reference it; otherwise identify the right surface yourself as part of step 4.

Feature Completion UX Test

Rule

For each change: define intended UX → set conditions → perform action → verify logs → report → commit.

Workflow

  1. Identify the exact intended UX change.

    • State the user-facing expectation in one sentence.
    • State the system expectation in one sentence (what should be logged where).

  2. Set test conditions.

    • If the project has an auto-login or test-user setup (see the project's own dev/test docs, or a skill like $how-to-log-to-each-internal-log if one exists), use it.
    • Pick the correct user type (admin vs non-admin, or whatever roles this project has).
    • If simulating a non-authenticated or non-admin user, log in as admin and use admin tools to simulate that role, if such tooling exists — otherwise use a real second account.

  3. Execute the action.

    • Recreate the exact scenario (e.g., select preset, send message, submit a form).
    • Capture the request payload in DevTools (or the equivalent network inspector) for the action.

  4. Verify logs.

    • Identify which of the project's own logging/observability surfaces should record this event. Every real project has at least one (an error log, a request log, an admin dashboard, an events table, a telemetry stream) — find it by reading the code path the action goes through, or by asking the person which surface they check for this kind of thing.
    • Example (opt-in illustration — replace with your project's own surfaces): session-scoped events go to a session-diagnostics view, one flow type goes to a "pulse" log, alerts to the product owner go to a notifications feed, and general errors/warnings go to a system log.
    • Confirm payload fields match intent.

  5. Decide outcome.

    • If correct: document evidence and commit the change.
    • If incorrect: fix and repeat this workflow.

Report Format

  • Intended UX:
  • Conditions set:
  • Action performed:
  • Payload evidence:
  • Log evidence:
  • Result: pass/fail

Note

Always verify against the project's real logging surfaces, not just the code that's supposed to write to them — a log line that never fires is a silent failure. If a skill exists in this project mapping which surface to check for which event (an example being $how-to-log-to-each-internal-log), reference it; otherwise this workflow's step 4 is how you work that out from scratch.