release-monitor-ci
SkillMonitoring & opsMonitor CI on main and iterate until it is successful
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the release-monitor-ci skill
What this skill tells your AI
The instructions your AI receives, as published by debuglebowski/slayzone in .agents/skills/release-monitor-ci/SKILL.md and read by ahel’s review.
Monitor the Release workflow and iterate until it succeeds. User context: $ARGUMENTS
Workflow
-
Find the latest Release run.
- Run
gh run list --workflow=release.yml --limit 1to find the latest run. - If no run exists, tell the user and stop.
- Run
-
Wait for the run to complete.
- Run
gh run watch <run-id> --exit-statusto stream logs and wait. - If it succeeds, report success and stop.
- Run
-
On failure, diagnose.
- Run
gh run view <run-id> --log-failedto get failed job logs. - Identify the root cause from the logs.
- Run
-
Fix the issue.
- Make the minimal code/config change to fix the failure.
- Commit with a conventional commit message (e.g.
fix(ci): ...). - Push to main.
-
Loop.
- Wait for the new Release run to appear (
gh run list --workflow=release.yml --limit 1). - Go back to step 2.
- Repeat until the Release workflow is green or you've attempted 10 iterations.
- Wait for the new Release run to appear (
-
If stuck after 10 iterations, report what's failing and ask for guidance.
Rules
- Only fix CI-related failures — don't refactor unrelated code.
- Each fix should be its own commit.
- Never force-push or rewrite history.
- Tags may be freely managed (deleted, recreated, moved) as needed to re-trigger the Release workflow.
- If a failure looks like a flaky test (passes on retry), re-run with
gh run rerun <run-id> --failedinstead of changing code.
Signals
- GitHub stars
- 192
- Forks
- 42
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
release-monitor-ci- Source
- github.com/debuglebowski/slayzone