\r \r

Role\r

\r This skill defines the test strategy for a delivery item. It decides which risks require unit, HTTP, E2E, WLS, or documentation checks and turns those needs into a coherent quality plan before acceptance.\r \r

When To Use\r

\r

• Use for test planning, coverage strategy, risk-based validation, and cross-role quality governance.\r
• Use for keywords such as QA strategy, test plan, coverage, regression scope, quality risk, and validation design.\r
• Use when a task spans multiple validation layers and needs a coordinated testing approach.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/testing/SKILL.md\r
• dev/ai/skills/planning/SKILL.md\r
• dev/ai/skills/documentation-standards/SKILL.md\r \r

Responsibilities\r

\r

• Decide which validation layers are required for the change.\r
• Match test depth to business risk, architecture risk, and runtime sensitivity.\r
• Define entry criteria, exit criteria, and evidence expectations for QA execution.\r
• Prevent under-testing of high-risk changes and over-testing of trivial changes.\r \r

Workflow\r

\r

1. Read the task scope, changed surfaces, and implementation risks.\r
2. Classify the change into data, route, UI, runtime, permission, and documentation impacts.\r
3. Define the minimum required unit, HTTP, E2E, WLS, and documentation checks.\r
4. Identify mandatory isolation rules, especially for WLS validation.\r
5. Assign owners or handoff requirements for each validation layer.\r
6. Define acceptance evidence and residual-risk reporting requirements.\r
7. Revisit the strategy if scope expands during implementation.\r \r

Weline Rules\r

\r

• Read AI-ENTRY.md first.\r
• Do not use default WLS port 9501 for AI testing.\r
• Always start a dedicated WLS test instance with a unique name when WLS validation is required.\r
• Always stop the AI test instance after testing.\r
• Provide unit test and E2E or HTTP validation evidence where relevant.\r \r

Inputs Required\r

\r

• The task scope and changed components.\r
• Known risk areas, runtime sensitivity, and user-facing surfaces.\r
• Available specialist outputs and expected release confidence level.\r
• Existing regression history if available.\r \r

Expected Output\r

\r

• A layered validation plan with clear required checks.\r
• A risk-to-test mapping for the change.\r
• Evidence requirements and gate definitions for execution roles.\r \r

Validation\r

\r

• Check that the strategy covers each changed risk surface.\r
• Check that WLS-sensitive changes include isolated runtime validation.\r
• Check that the required evidence is proportionate and executable.\r
• Check that the plan distinguishes mandatory tests from optional confidence checks.\r \r

Constraints\r

\r

• Do not collapse all testing into one generic “run tests” instruction.\r
• Do not approve a strategy that ignores runtime-sensitive or permission-sensitive risks.\r
• Do not let convenience replace isolation rules for WLS validation.\r
• Do not replace developer responsibility with QA-only catch-up testing.\r \r