Frontend verification

Checks frontend changes with repository tooling and real browser behavior, then reports precisely what the available evidence covers.

frontend-verification

Agents using this skill

See how it helps

When is it useful?

Use it before handing off a Vue or frontend change whose build success alone does not prove the user flow.

What does it help you do?

Runs the repository’s actual typecheck, lint and build commands.
Tests observable Vue component and composable behavior.
Exercises browser network, console, keyboard and narrow-screen states.

Try asking this

Verify a changed registration form and report untested browser paths. Submit invalid data, correct it with the keyboard and repeat at phone width. Separate successful checks from unavailable browsers or tests that never started.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Frontend Verification & Browser QA

Prove that a frontend change compiles cleanly, passes targeted automated checks, and works in the browser across states and screen sizes before calling it done.

1. Static and build verification

Run the project's actual scripts from package.json:
- Typecheck: run vue-tsc --noEmit (or the repo's typecheck script) so template expressions, slot props, component emits and TypeScript files are all checked together. Plain tsc does not typecheck .vue templates.
- Lint & format: run the configured linter (eslint, oxlint, stylelint) and fix every error or warning introduced by your change.
- Build: run the build command when touching imports, dynamic chunks, Vite config, SSR or environment variables.

2. Targeted Vue component and composable tests

Test observable behavior, not internal implementation details:
- In @vue/test-utils / Vitest Browser Mode, interact via props, user events (trigger, user-event) and slots, and assert on rendered DOM output and emitted events (wrapper.emitted('save')), never wrapper.vm private refs.
- Await DOM updates (await nextTick()) after state changes and await flushPromises() after async requests before asserting.
- For composables: test pure reactivity directly; when a composable uses lifecycle hooks (onMounted, onUnmounted) or inject, run it inside a small withSetup(() => useMyComposable()) helper component and unmount it to verify cleanup.
- For Pinia stores: call setActivePinia(createPinia()) (or createTestingPinia()) in beforeEach so state never leaks across tests.

3. Browser, network and interaction check

Whenever browser or preview tools are available, exercise the changed flow in a real browser:
- States: verify initial load, loading indicators, empty state, validation error, server failure & retry, and successful completion.
- Console & network: check for zero Vue runtime warnings ([Vue warn]), unhandled promise rejections, console errors, failed network requests, or duplicate/runaway API calls.
- Responsive & keyboard: check phone, tablet and desktop widths (375px, 768px, 1280px), keyboard navigation (Tab, Enter, Escape in dialogs/menus) and visible focus rings.

4. Honest handoff

Record exactly which commands, tests, screens, states and widths you verified and what their output showed.
State clearly any check that could not be run (for example, no live backend or browser tool in the environment) and provide concrete reproduction and verification steps for the reviewer or tester. Never claim a check was done when it was not.

Before you finish

vue-tsc / typecheck, linter and relevant unit/component tests ran and passed.
No [Vue warn], console errors or duplicate network requests in the changed flow.
Loading, empty, validation error, server error and success states verified.
Verification steps and any remaining environment limits are documented for the tester.

Included files 2

LICENSE.txt
SKILL.md