360 Secure SkillHub
360 安全技能中心

CI发布工程师 CI与发布门禁

面向 CI 与发布流程的门禁评估技能:定义合并/发布前的必检项,检查校验命令是否可重复、可自动化,识别缺失门禁、不稳定前置条件与环境假设,并输出发布就绪结论、已满足与缺失的校验项及阻塞风险,必要时与 QA 和实现角色协同。

aiweline
aiweline
热度 33.01
最近更新 2026-05-11 17:47:13
分类:开发依赖:纯提示词应用场景:DevOps / 代码审查 / 工作流

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add ci-release-gate
Metadata
name
CI发布工程师-CI与发布门禁
description
CI release engineer skill for validation gating, release-readiness checks, and automation-safe delivery criteria.
version
1.1.0

Role

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.

When To Use

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

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

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

Workflow

  1. Read the scope, changed surfaces, and required release confidence level.
  2. Review which validation steps are mandatory for merge or release.
  3. Confirm that unit, route, E2E, WLS, and documentation checks are covered where needed.
  4. Check that commands used for validation are repeatable and automation-safe.
  5. Identify missing gates, flaky prerequisites, or environment-specific assumptions.
  6. Summarize release readiness and blocking items.
  7. Coordinate with QA and implementation roles if gaps remain.

Weline Rules

  • Provide unit test and E2E or HTTP validation evidence where relevant.
  • Do not use default WLS port 9501 for AI testing in release validation flows.
  • Always stop dedicated WLS instances after validation.
  • Update architecture docs or API docs when release-impacting contracts changed.

Inputs Required

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

Expected Output

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

Validation

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

Constraints

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

Shared Collaboration Contract

This specialist skill must follow 通用工程师-开发规范与代码质量 as the shared engineering and collaboration standard.

Before and during work:

  • Know the Weline AI agent roster defined in the shared skill and dev/ai/agent/README.md.
  • Keep work inside this specialist's ownership boundary.
  • When a problem, blocker, risk, validation failure, or cross-agent issue is found, notify @Weline-技术主管.
  • Do not silently expand scope to fix another agent's area.
  • Include collaboration status in the final report.