\r \r

Role\r

\r 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.\r \r

When To Use\r

\r

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

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

Workflow\r

\r

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

Weline Rules\r

\r

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

Inputs Required\r

\r

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

Expected Output\r

\r

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

Validation\r

\r

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

Constraints\r

\r

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