background-deploy-monitor
Skill4 starsChanged 8 months agoMITView on GitHub
Watch a running deployment or CI job in the background, polling until it finishes, so you can keep working and still get told what happened. Use it right after pushing a branch that triggers a long CI or deploy pipeline; when watching a Render, Vercel, or Amplify deployment that takes several minutes to go live; when a test suite on a large repo runs long enough that you would otherwise sit and watch it; when a deploy needs a post-deploy smoke check and you want the failure logs pulled automatically.
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
If I gave you a run ID, use it.
- Very specific: line 23
Run: gh run view <run-id> --json status,conclusion,jobs
- Distinctive: line 24
If status is queued or in_progress, wait 60 seconds and poll again.
- Distinctive: line 25
If status is completed, stop polling and go to step 3.
- Distinctive: line 28
Stop conditions, whichever comes first:
- Distinctive: line 34
If the conclusion is success:
- Distinctive: line 38
If the conclusion is failure, cancelled, or timed_out:
- Distinctive: line 42
Do not attempt a fix and do not re-run the job.
- Distinctive: line 45
Never push, re-run, cancel, or deploy anything.
- Distinctive: line 46
Keep the polling output to one line per check.
- Distinctive: line 47
If the run does not exist or the CLI is not authenticated, fail fast with that message instead of polling a missing run.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- Generated from recipes/devops/background-deploy-monitor.md by scripts/build-skills.sh. Edit the recipe, then rerun the script. -->Background Deploy Monitor
Monitor a running job until it reaches a terminal state, then report what happened. Poll; do not block on a single long-running command.
1. IDENTIFY THE RUN
If I gave you a run ID, use it. If I did not, find the most recent run for the current branch: gh run list --branch $(git branch --show-current) --limit 1 --json databaseId,status,workflowName
Report which run you are watching before you start polling, so I can correct you if it is the wrong one.
2. POLL
Loop:
- Run: gh run view
<run-id>--json status,conclusion,jobs - If status is queued or in_progress, wait 60 seconds and poll again.
- If status is completed, stop polling and go to step 3.
- Print one short line per poll: elapsed time, status, and which job is currently running. Nothing more. Do not narrate.
Stop conditions, whichever comes first:
- The run reaches a terminal status.
- 30 minutes of polling have elapsed. Report a timeout and the last known status rather than polling forever.
3. REPORT
If the conclusion is success:
- Report the total duration and the per-job durations.
- Name the slowest job, so it is visible when it starts creeping up.
If the conclusion is failure, cancelled, or timed_out:
- Identify which job and which step failed: gh run view
<run-id>--log-failed - Quote only the relevant failing output, not the whole log.
- State in one sentence what broke and the most likely cause.
- Do not attempt a fix and do not re-run the job. Report and stop.
Rules:
- Never push, re-run, cancel, or deploy anything. This job only observes.
- Keep the polling output to one line per check. The point of running in the background is that it stays quiet.
- If the run does not exist or the CLI is not authenticated, fail fast with that message instead of polling a missing run.
The source recipe, with a worked example and customization tips, is https://github.com/Sagargupta16/agent-recipes/blob/main/recipes/devops/background-deploy-monitor.md
In this repository22 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- api-docs-generatorSkill
- architecture-reviewSkill
- changelog-writerSkill
- ci-cd-pipelineSkill
- cjs-to-esmSkill
- class-to-hooksSkill
- coverage-gap-finderSkill
- dependency-auditSkill
- dockerfile-generatorSkill
- e2e-test-writerSkill
- generate-unit-testsSkill
- input-validationSkill
- js-to-tsSkill
- monitoring-setupSkill
- multi-repo-pr-checkSkill
- owasp-auditSkill
- performance-reviewSkill
- pr-reviewSkill
- readme-generatorSkill
- secret-scannerSkill
- upgrade-dependenciesSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.