Files
skills/skills/kvb-ci-observe/SKILL.md
T
Kevin Veen-BirkenbachandClaude Opus 5.5 8b0c287ada fix(skills): trim 22 descriptions back under the listing budget
The skill listing stood at 1498 of 1500 words; the trimmed descriptions bring it to 1420, so the new kvb-check-ansible description fits without pushing others out.

🎯 Fix: 95 %
💥 Break: 1 %
💸 Cost: 99 %
⏱️ Time: 100 %
🛡️ Security: 100 %
🏆 Score: 95
🚦 Gate: ✅ 90/5, cost and time <= 100, security 100 %

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-07 10:47:08 +00:00

3.0 KiB

name, description
name description
kvb-ci-observe Watch a CI run, pipeline, build or log on a cadence, triaging and fixing new failures. Trigger when asked to keep monitoring.

Keep a target under watch and act only when it degrades: the loop watches, triage responds. Never re-investigate a failure already resolved this session, and never poll work the harness will notify you about.

Before you start: fix the target

The operator names one concrete target: a CI run id or url, a pipeline, a branch's checks, a build, or a log file. Restate it in one line and record the current failure set (known or already fixed this session) as the baseline. Every observation is diffed against it; a stale baseline re-triages solved failures.

The loop

Drive it with /loop in dynamic mode (no fixed interval unless the operator gave one): after each observation, schedule the next wake-up and pass this skill's prompt back unchanged.

  1. Poll the target: its job list, check conclusions or log tail; for a GitHub Actions run, the kvb-ci-artifacts skill's ci_failures.py <run>. Enumerate failures as the kvb-ci-triage skill's step 1 does: failure, cancelled, timed-out; a downstream aggregate that fails only because an upstream did is not its own failure.
  2. Diff against the baseline. A failure is new only if it is neither in the baseline nor triaged this session. Nothing new: log one short line ("still green" / "N known failures, no change") and reschedule.
  3. Triage each new failure with the kvb-ci-triage skill on the new set only; it applies kvb-think-dialectic per failing job to a ~99% root cause and a real fix. Never mask (no retry-until-pass, disabled check or soft skip). A new failure and its verdict go to peers by radio, never with a wake: ${CLAUDE_SKILL_DIR}/../kvb-org-radio/scripts/radio.py post "<target>: <job> <failing line> -> <verdict>". Fold each newly fixed failure into the baseline.
  4. Reschedule by what you wait on: an active run that changes every few minutes gets a check matched to its cadence, a quiet or long-running target a long fallback (1200s+). Stop once the target reaches a terminal state (run completed, pipeline finished) AND every failure it produced has a verified fix.

Rules

  • The loop is a fallback timer, not a busy-wait: for tracked work the harness reports (a background task, a spawned agent), wait for that notification; reserve the timed wake-up for state the harness cannot see (a remote CI run, a deploy queue).
  • Executed evidence beats reasoning: read the failing log line and the artifact, not the job title.
  • One baseline, updated in place: dedup every observation against all failures seen so far, or a flaky-then-fixed failure reappears every cycle and the watch never converges.
  • Report only on change: a new failure and its triage verdict, or a terminal "target is green, watch closed". Silence between changes is correct.
  • Never invent results for a run still in progress; report what the poll returned.