菜单
Use when a release candidate is ready and the team must choose the safest rollout pattern, verification checkpoints, and rollback path for the current risk, blast radius, and operational constraints.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a bug, failing test, regression, or unexpected behavior needs a root-cause-first debugging loop before code changes, especially when brownfield seams, recent releases, or historical defect matches make guesswork unsafe.
Use when E2E tests must go beyond shallow happy-path checks — multi-step user journeys, stateful sessions, cross-boundary state consistency, failure-mode edges — or when the suite passes but production still breaks. Platform- and framework-agnostic (web, mobile, desktop; Playwright, XCUITest, Cypress).
Use when discovery has narrowed an idea enough that the team must make a go/no-go, pivot, or scope-down decision based on technical, economic, operational, or timeline viability before requirements, architecture, or major implementation.
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
Use when discovery needs evidence about market demand, competitors, pricing pressure, or underserved segments for a new product or expansion idea before feasibility, user research, or requirements are finalized.
Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
| name | pc-deployment-strategy |
| description | Use when a release candidate is ready and the team must choose the safest rollout pattern, verification checkpoints, and rollback path for the current risk, blast radius, and operational constraints. |
| metadata | {"phase":"06-delivery","inputs":["ci-cd-pipeline","build-artifacts","release-plan"],"outputs":["deployment-runbook"],"prerequisites":["pc-ci-cd"],"quality_gate":"Rollout pattern, rollback path, verification checkpoints, and ownership are explicit and rehearsable for the current release","roles":["devops-engineer","tech-lead"],"methodologies":["all"],"effort":"medium"} |
Decide how the release reaches production, how it is verified, and how it is reversed if reality disagrees with the plan.
CI/CD automates the path to deployment; deployment strategy decides how much risk to take on each step of that path.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
Assess user impact, data migration risk, trust-boundary change, reversibility, and observability quality. Decide whether the release is low risk, staged-risk, or high risk.
Match the pattern to the risk:
If the release cannot be observed or rolled back safely, the strategy is wrong.
Specify what must be checked before traffic increases:
Tie each checkpoint to an owner and a stop/continue decision.
Document the exact release sequence, rollback trigger conditions, rollback commands, communication path, and post-deploy observation window. A rollout plan without a concrete rollback path is incomplete.
Produce only declared outputs at their documented quality boundary.
