Ci

CI Check

Use this skill when the user asks to check CI, build status, failing checks, or whether a branch is green. Prefer the separate ci-status pi package when it is installed because it gives the user an interactive TUI view. If the slash commands are unavailable, use get_ci_status and ci_fetch_job_logs only if the current harness exposes those tools; otherwise ask the user to install ci-status.

Tools available

Primary, when the ci-status package is installed:

• /ci — Quick status overview in the widget area with per-job breakdown.
• /ci-detail — Interactive TUI view: CI providers and workflow/cycles grouped separately, Tab and cycle switching, native pickers, in-place refresh, automatic focus on failing provider/cycle, sorted job list, detail view, log fetch, first-error jump, browser open, copy URL, jump to failures.
• /ci-logs — Pull logs for a specific failing job.

Fallback tools, when exposed by the current harness:

• get_ci_status — Fetch the latest CI status for the current git branch/PR. Returns a per-job breakdown with IDs, URLs, and durations. Uses gh CLI for GitHub Actions. Set CIRCLECI_TOKEN for CircleCI enrichment.
• ci_fetch_job_logs — Fetch failure logs for a specific CI job. Pass the job id from get_ci_status output, a GitHub run databaseId (for GH Actions), or a CircleCI job number. Returns the log output truncated to 500 lines.

Scope boundary

• This skill is for remote CI status: /ci, /ci-detail, /ci-logs,

get_ci_status, and ci_fetch_job_logs.

• If local-ci is on PATH and the repo root contains .local-ci.toml, treat

local-ci as the repo-owned local validation path instead of a CI-status replacement.

• Some repos may still show safety workflows or temporary compatibility stubs

in remote CI; missing local-ci contexts usually means local-ci has not been run on that exact SHA yet.

• Deploy helpers such as scripts/deploy/trigger_validated_backend_deploy.sh

belong to release/deploy workflows, not this status-check skill.

Process

1. Fetch status.

• Prefer /ci for a quick overview, then /ci-detail if there are failures or running jobs to inspect.
• If /ci or /ci-detail is unavailable, call get_ci_status with no arguments — it auto-detects the current branch.
• Status should include a per-job breakdown: job name, status (passing/failing/cancelled), URL, duration.
• If it returns no data or errors, confirm the branch is pushed and gh CLI is authenticated.

1. For every failing job, pull the logs:

• Prefer /ci-logs or the r log action inside /ci-detail.
• If using fallback tools, call ci_fetch_job_logs with the appropriate id from the status output.
• Use jobId for GitHub runs, runId for the databaseId, or jobNumber for CircleCI jobs.
• Logs may be truncated — focus on the tail (last 100-200 lines) where errors typically appear.

1. For each failure, determine: ours or flake?

• Ours — the failure is in code we touched or is clearly related to our changes. Examples: a test we modified now fails, a new import breaks lint, our code change causes a type error.
• Pre-existing flake — the same job fails intermittently on other branches/PRs, the error is in code we didn't touch, or the failure is a timeout/infra issue unrelated to our diff.
• Pre-existing (not flake) — a known failing test or build step that was broken before our branch. Note it but don't propose fixing it unless explicitly asked.

1. For each "ours" failure, propose a fix:

• Identify the root cause — what exactly broke?
• Propose the specific code change, test update, or config tweak.
• If the fix is non-trivial, outline the approach before editing.

1. For each flake, note it and move on:

• Mark it clearly as pre-existing so we don't waste time.
• If it's consistently flaky, suggest ignoring it. If it's clearly broken infrastructure, suggest reporting it.

1. Summarize at the end in a scannable format:

• Overall status: ✅ all green / ❌ X failing / ⚠️ Y flaky
• Per-job verdict table or list with ours/flake callout
• Actionable fixes (if any)

Output format

Prefer a clear, scannable summary. Example:

CI Status: ❌ 2 failing, ⚠️ 1 flaky

| Job | Status | Ours? | Action |
|-----|--------|-------|--------|
| backend-tests | ❌ | ✅ ours | Fix import in views.py |
| frontend-lint | ❌ | ✅ ours | Run prettier on App.tsx |
| e2e-safari | ❌ | 🚫 flake | Pre-existing — ignore |

Safety rules

• Do not edit code without understanding the failure first.
• Do not propose fixes for code we didn't touch unless it's clearly a side-effect cleanup.
• Do not mark a failure as a flake unless you can see evidence it also fails on other branches.
• If you cannot determine whether a failure is ours or a flake, flag it as "unclear" and ask the user.
• If CI is all green, confirm and stop — don't dig into passing jobs.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: DiversioTeam
• Source: DiversioTeam/agent-skills-marketplace
• License: MIT
• Homepage: https://engineering.diversio.com

Install and usage instructions live in the source repository linked above.