\r \r

Role\r

\r This skill owns release gating and CI-oriented readiness checks. It verifies that required validation paths are covered, command usage is automation-safe, and the change can move through delivery without bypassing quality gates.\r \r

When To Use\r

\r

• Use for CI checks, release gates, automation readiness, and pre-merge validation policy.\r
• Use for keywords such as CI, release gate, merge gate, preflight, pipeline, and release readiness.\r
• Use when a change must be assessed for automation-safe delivery rather than only local correctness.\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

• Define and enforce the validation set required before release or merge.\r
• Check that commands, tests, and docs support automated delivery.\r
• Flag missing gates, weak evidence, or unsafe release assumptions.\r
• Produce a release-readiness recommendation grounded in verifiable checks.\r \r

Workflow\r

\r

1. Read the scope, changed surfaces, and required release confidence level.\r
2. Review which validation steps are mandatory for merge or release.\r
3. Confirm that unit, route, E2E, WLS, and documentation checks are covered where needed.\r
4. Check that commands used for validation are repeatable and automation-safe.\r
5. Identify missing gates, flaky prerequisites, or environment-specific assumptions.\r
6. Summarize release readiness and blocking items.\r
7. Coordinate with QA and implementation roles if gaps remain.\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 in release validation flows.\r
• Always stop dedicated WLS instances after validation.\r
• Update architecture docs or API docs when release-impacting contracts changed.\r \r

Inputs Required\r

\r

• The changed scope and intended release or merge target.\r
• Returned validation evidence from implementation and QA roles.\r
• Any CI or automation constraints for the branch.\r
• Required confidence level and known blockers.\r \r

Expected Output\r

\r

• A release-gate decision or recommendation.\r
• A list of mandatory checks satisfied and missing.\r
• A concise statement of blockers, environment risks, or follow-up actions.\r \r

Validation\r

\r

• Check that every required gate has repeatable evidence.\r
• Check that no step depends on manual hidden state that CI cannot reproduce.\r
• Check that runtime validation followed dedicated-instance rules where applicable.\r
• Check that contract or documentation changes are represented in release evidence.\r \r

Constraints\r

\r

• Do not approve release readiness on local intuition alone.\r
• Do not ignore flaky validation prerequisites.\r
• Do not bypass missing evidence because a change appears low risk.\r
• Do not collapse QA and CI gate responsibilities into one vague signoff.\r \r