القائمة
Use when a tested release candidate needs a coordinated go/no-go decision, release window, communication path, and ownership model before deployment proceeds.
التثبيت باستخدام 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-release-management |
| description | Use when a tested release candidate needs a coordinated go/no-go decision, release window, communication path, and ownership model before deployment proceeds. |
| metadata | {"phase":"06-delivery","inputs":["delivery-decision-record","test-report","security-report","performance-report"],"outputs":["release-plan"],"prerequisites":["pc-testing-strategy"],"quality_gate":"Release scope, readiness decision, communication path, and execution ownership are explicit enough for deployment planning and stakeholder alignment","roles":["tech-lead","qa-engineer","devops-engineer"],"methodologies":["all"],"effort":"medium"} |
Turn a technically ready build into a deliberately coordinated release.
Release management decides whether the current candidate should ship now, under what constraints, and with which communication and ownership model.
See context and anti-pattern notes.
I/O contract notes define required inputs and authority.
Confirm what is in, what is out, which findings are accepted, and which conditions would block the release. If a delivery-decision-record exists, anchor the release scope to that recorded branch or PR outcome instead of reconstructing the completion state from memory. Do not carry unresolved scope ambiguity into the deployment window.
Summarize readiness across quality, security, performance, and operations. If the release is conditional, name the conditions in plain language instead of relying on implied tribal knowledge.
Define:
Produce a release plan that downstream deployment planning can execute. The plan should say what will ship, when, who coordinates, which checks gate expansion, and what happens if the release is paused.
Produce only declared outputs at their documented quality boundary.
