القائمة
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
Shared vocabulary and principles for designing deep modules. Use when the user wants to design or refine a module's interface, hunt for deepening opportunities, decide where a seam belongs, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
| name | deploy-verify-loop |
| description | Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand. |
| disable-model-invocation | true |
A deploy that reports success isn't the same as a deploy that's actually healthy — a rollout can finish while a pod crash-loops, a health check flakes, or the new version 400s on a path the deploy step never exercised. This loop watches the window right after a deploy closes and turns "did it work?" into a checked answer instead of a hope.
Before polling, confirm the concrete signal for this deploy target — it varies by platform:
Ready, no CrashLoopBackOff.Done when you can name the exact check that proves the rollout finished — not "give it a few minutes."
Check the Step 1 signal on an interval matched to how fast this deploy actually rolls (a Kubernetes rollout finishes in seconds to minutes; a CDN/edge propagation can take longer — don't poll a slow system every few seconds). Set a hard timeout. If the timeout is reached before the signal clears, stop and report exactly what's still not ready — don't keep polling past the bound hoping it resolves.
A rollout can report "ready" while the new version is still wrong: pull recent logs for the just-deployed instances and scan for a crash loop, an elevated error rate, or a startup panic that a readiness probe doesn't catch. If anything here looks wrong, stop and report it — don't proceed to the smoke check against something already unhealthy.
Exercise a real, critical-path action end to end (not just a /health endpoint returning 200) — whatever this system's core round-trip is: a request that touches the code you just shipped, not a static page. One meaningful check beats a broad shallow sweep here; the goal is "does the thing users actually do still work," not full regression coverage.
Done when the smoke check has run against the newly-deployed instance and you have a pass/fail result, not an assumption.
Do not roll back, restart, or otherwise change the running system as part of this loop — verification surfaces the problem; fixing it is a separate, deliberate decision.