Role

This skill enforces quality gates on returned work. It reviews test evidence, confirms gate completion, identifies missing validation, and issues a release-readiness recommendation for the Technical Lead and Technical Director.

When To Use

• Use when development and testing evidence is available and a quality-gate decision is required.
• Use for keywords such as quality gate, test signoff, release readiness, acceptance evidence, and regression review.
• Use when returned work must be accepted, rejected, or conditionally accepted from a QA standpoint.

Source Material

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

Responsibilities

• Review whether required test layers were actually executed.
• Reject weak evidence, missing coverage, or mismatched validation claims.
• Track residual risks, known gaps, and deferred items explicitly.
• Produce a QA gate recommendation rather than a vague status note.

Workflow

1. Read the QA strategy, implementation summary, and all returned evidence.
2. Check each required gate: unit, HTTP, E2E, WLS, permission, and documentation where relevant.
3. Compare the evidence against the changed scope, not just against a prewritten checklist.
4. Mark gates as passed, failed, or missing, and explain why.
5. Summarize residual risks and any conditional release concerns.
6. Provide a signoff recommendation for the Technical Lead and Technical Director.
7. Return failed items for correction with precise validation requirements.

Weline Rules

• Provide unit test and E2E or HTTP validation evidence where relevant.
• Do not use default WLS port 9501 for AI testing when runtime evidence is required.
• Always require dedicated WLS instance cleanup in runtime validation records.
• Update module README, architecture docs, or API docs when the change requires it.

Inputs Required

• The QA strategy and required gates.
• The implementation summary and changed files or surfaces.
• All test outputs, runtime logs, and documentation updates.
• Any requested release timeline or risk tolerance.

Expected Output

• A gate-by-gate acceptance decision.
• A release-readiness recommendation.
• A list of missing evidence, failed checks, and residual risks.

Validation

• Check that every mandatory gate has concrete evidence.
• Check that evidence corresponds to the actual changed surface.
• Check that runtime validation records include dedicated instance hygiene where relevant.
• Check that documentation-related gates were not skipped when interfaces or design changed.

Constraints

• Do not sign off based on summary claims alone.
• Do not downgrade a failed gate into a soft warning without explanation.
• Do not ignore missing documentation when it is part of the acceptance bar.
• Do not substitute QA opinion for missing evidence.