/loopdevopsmedium riskintermediatesafety D · 50 · open-endedClaude Directorypre-dates current gate · under review

Deploy-poll loop

A hands-free ops loop that polls your deploy every two minutes, runs the smoke test the moment it goes live, and stops with a report if any check fails.

prompt
→ Claude
/loop every 2 minutes: check deploy status; when it's live, run the smoke test and summarize; if smoke test fails, report the failing check and stop
claude-code

Implementation note

When to use: you have kicked off a deploy and the next twenty minutes are otherwise dead time — waiting to see it go live, then remembering to run the smoke test against it. How it works: every two minutes the loop checks deploy status. The moment the deploy is live it runs the smoke test and summarizes the results; if the smoke test fails, it reports the failing check and stops rather than continuing to poll or attempting fixes. Safety: the stop-on-failure clause is the notable rail — a failed smoke test halts the loop with a report, leaving the response decision (rollback, hotfix, investigate) to you instead of the loop improvising remediation against production. Everything it does is read-and-report: status checks and test runs, no code or infrastructure changes. It is cheap at a two-minute cadence, but kill it once the deploy is confirmed rather than leaving it polling.

Source: Claude Directory blog

More devops loops

Check whether the deploy finished and summarize what changed

/loopnew

A 5-minute watch loop that polls whether a deploy has finished and, once it lands, summarizes what changed. It is a read-only status watcher rather than an agent driving toward a finish condition.

prompt
→ Claude
/loop 5m check whether the deploy finished and summarize what changed
devopshigh risk

Docker image slimming

/goalloopreponew

Iteratively shrink a Docker image under a size target using multi-stage builds, smaller base images, and layer cleanup, verifying the container still boots each turn.

prompt
→ Claude
/goal `docker images` shows the app image under 300 MB — apply one slimming change per turn (multi-stage build, slimmer base image, prune build deps, consolidate layers), rebuild, and verify the container starts and passes its healthcheck before the next change; stop at the target or after 8 turns
devopslow risk

Capture a post-release baseline

Run the standard benchmarks against a finished release and record a reproducible baseline for future comparison.

prompt
→ Claude
After current releases finish, run the standard benchmarks and record the results as the new baseline.
devopshigh risk