Run any Skill in Manus with one click

Get Started

qa-verification

Stars17

Forks13

UpdatedJuly 8, 2026 at 22:04

Phase 3 of code review: run tests, verify behavior, check edge cases, confirm no regressions.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ASU

ASU/asu-unity-stack

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name	qa-verification
description	Phase 3 of code review: run tests, verify behavior, check edge cases, confirm no regressions.

QA Verification (Phase 3)

Verify the implementation actually works, not just that the code looks correct.

Verification Ladder

Work from narrow to broad:

Run targeted tests for changed behavior.
Check edge/error-path tests from the design document are covered.
Run package/module test suite.
Run typecheck/lint/build if present.
Run full test suite before APPROVED.

If a full suite is too slow or unavailable, report: command not run, reason, risk, and narrower evidence collected.

Quality Checks

Do tests verify behavior or just exercise code paths?
Did any previously passing tests break (regressions)?
Do error conditions produce correct results?

Browser Interaction Testing (Interactive Components)

For components with user interaction, QA verification includes browser-based testing via Chrome DevTools MCP or agent-browser:

Required Verifications

Click Navigation
- Click each interactive element
- Screenshot each resulting state
- Verify state matches Behavioral Matrix from design doc
Keyboard Navigation
- Tab into component, verify focus lands correctly
- ArrowLeft/Right through all items
- Verify focus ring visible on active element
- Tab out, verify exit to correct element
Mobile/Touch
- Resize to 375×667 (iPhone SE)
- Verify layout adapts (scroll vs stack)
- Test swipe gestures if applicable
Accessibility Audit
- Run mcp_chrome_devtoo_lighthouse_audit with mode="snapshot"
- Verify Accessibility score ≥ 95 (ideally 100)
- Document any issues

Evidence Required

## Browser Interaction Results
- Click navigation: [PASS/FAIL with screenshot paths]
- Keyboard navigation: [PASS/FAIL with test sequence]
- Mobile layout: [PASS/FAIL at 375px]
- Lighthouse a11y: [score]

Output

PASS or FAIL with specific test results and evidence.

## QA Results
- Test suite: [X passed, Y failed, Z skipped]
- Edge case coverage: [list from design doc, each PASS/FAIL]
- Regressions: [none / list]
- Error path verification: [PASS/FAIL with evidence]

More from this repository

same repository

architecture-lock

ASU/asu-unity-stack

Use this skill after problem framing to produce a locked architecture document. Creates data flow diagrams, state machines, error paths, test matrices, and bite-sized task breakdowns.

2026-07-0817

asu-design-a11y

ASU/asu-unity-stack

Design + accessibility skill for ASU UI work (WCAG 2.1 AA). Use when designing, building, or reviewing any ASU component or page in Unity or Webspark. Covers semantics/landmarks, keyboard + focus, contrast, reflow at 320px, forced-colors mode, labels/forms, and a pre-delivery checklist. Prefer Unity/Bootstrap components over hand-rolled div+ARIA.

2026-07-0817

code-quality

ASU/asu-unity-stack

Evaluate code structure, maintainability, and engineering standards alongside adversarial review.

2026-07-0817

visual-diff

ASU/asu-unity-stack

Use during REVIEW to compare a rendered UI component against its design references (screenshots in .intake/ and/or the Figma frame). Drives a running Storybook (Unity) or local Webspark page with agent-browser to screenshot the build at multiple viewports, then reports P1/P2/P3 visual-fidelity findings to .pipeline/visual-report.md. Used by the acp-visual agent.

2026-07-0817

unity-handoff-out

ASU/asu-unity-stack

Use at the END of the Unity stage to enforce the PR-ready gate and write the cross-stage handoff. Defines the gate (build+lint, Storybook story + interaction/a11y tests, HTML-parity) and writes handoff.json (+ markup.html) to the shared peer handoff/ directory, keyed by Jira key or component slug, for the Webspark stage to consume. Validate with .kiro/scripts/validate-handoff.sh.

2026-07-0117

jira-figma-intake

ASU/asu-unity-stack

Use at pipeline INTAKE to turn a component request into an enriched intake brief. A component name is ALWAYS required; a Jira key, a Figma URL, and/or one-or-more screenshots in .intake/ are optional enrichment. Reads Jira via mcp-atlassian (read-only), design specs/tokens via the Figma Dev Mode MCP, and screenshots via vision. Ask clarifying questions when inputs are sparse or conflicting. Produces .pipeline/intake-brief.md for the architect.

2026-06-2917

QA Verification (Phase 3)

Verify the implementation actually works, not just that the code looks correct.

Verification Ladder

Work from narrow to broad:

Run targeted tests for changed behavior.

Check edge/error-path tests from the design document are covered.

Run package/module test suite.

Run typecheck/lint/build if present.

Run full test suite before APPROVED.

If a full suite is too slow or unavailable, report: command not run, reason, risk, and narrower evidence collected.

Quality Checks

Do tests verify behavior or just exercise code paths?

Did any previously passing tests break (regressions)?

Do error conditions produce correct results?

Browser Interaction Testing (Interactive Components)

For components with user interaction, QA verification includes browser-based testing via Chrome DevTools MCP or agent-browser:

Required Verifications

Click Navigation

Click each interactive element
Screenshot each resulting state
Verify state matches Behavioral Matrix from design doc

Keyboard Navigation

Tab into component, verify focus lands correctly
ArrowLeft/Right through all items
Verify focus ring visible on active element
Tab out, verify exit to correct element

Mobile/Touch

Resize to 375×667 (iPhone SE)
Verify layout adapts (scroll vs stack)
Test swipe gestures if applicable

Accessibility Audit

Run mcp_chrome_devtoo_lighthouse_audit with mode="snapshot"
Verify Accessibility score ≥ 95 (ideally 100)
Document any issues

Evidence Required

## Browser Interaction Results - Click navigation: [PASS/FAIL with screenshot paths] - Keyboard navigation: [PASS/FAIL with test sequence] - Mobile layout: [PASS/FAIL at 375px] - Lighthouse a11y: [score]

Output

PASS or FAIL with specific test results and evidence.

## QA Results - Test suite: [X passed, Y failed, Z skipped] - Edge case coverage: [list from design doc, each PASS/FAIL] - Regressions: [none / list] - Error path verification: [PASS/FAIL with evidence]