菜单
Use when a change may affect rollout, deployment, migrations, or operational stability and needs a higher-confidence validation pass.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use the Codex Kit CLI to initialize, update, or inspect a Codex-ready project scaffold in the current workspace.
Review patches, branches, or implementations for correctness, regressions, security, and missing tests. Use when the task is to inspect a diff or code change and identify concrete risks before merge.
Reproduce, isolate, and explain bugs before fixing them. Use when the task is about a bug, regression, failure, flaky behavior, unexpected output, or unclear runtime behavior that must be narrowed to a concrete cause.
Produce implementation plans that are decision-complete and execution-ready. Use when the task needs decomposition, sequencing, acceptance criteria, explicit assumptions, risk handling, or a concrete plan before coding or operational work starts.
Use when a bug is real but poorly scoped and you need a disciplined pass to reproduce it, bound it, and isolate the most likely root cause before fixing.
Use when documentation needs to be published, refreshed, or aligned with the actual product behavior, commands, and failure cases instead of sounding generally correct.
| name | release-readiness |
| description | Use when a change may affect rollout, deployment, migrations, or operational stability and needs a higher-confidence validation pass. |
Review whether a change is safe to merge, deploy, and roll back. Focus on concrete release risk, missing safeguards, and validation gaps rather than general code quality.
Check the change for:
Identify the release surface. Determine what is changing in runtime behavior, data shape, deployment sequencing, operator workflow, or external integrations.
Look for ordering assumptions. Check whether deploy, migrate, backfill, flag flip, cache warmup, or client rollout must happen in a specific order.
Test backward and forward compatibility. Ask whether the previous version can run against the new system state and whether the new version can tolerate partially migrated state.
Evaluate rollback realistically. Do not stop at "can revert the code." Check whether data, config, or one-way side effects make rollback unsafe or incomplete.
Inspect observability and blast radius. Verify that failure would be detectable quickly and contained to a narrow scope when possible.
Check validation depth. Prefer targeted release checks over generic confidence language. Name the missing test, rehearsal, or verification step.
Prioritize findings that could block or complicate release. For each issue, state:
Keep summaries brief. Lead with the highest-severity release risks first.
Apply extra scrutiny when changes involve:
Do not turn this into a general architecture review or style review unless those issues create release risk. Stay focused on deployment safety, compatibility, rollback, and operational confidence.
