CI Check

Overview

Check CI status for the current branch, analyze failures, distinguish failures caused by our changes from pre-existing flakes, and propose specific fixes. Use when the user asks about CI, build status, failing checks, failing jobs, test failures in CI, or whether the branch is ready after a push.

This is a Pi-local skill shipped inside the Dev Workflow package. Install the parent Pi package, reload Pi, and the skill becomes available alongside the package's extension surface.

Parent Surface

Tools available

Primary, when the ci-status package is installed:

Fallback tools, when exposed by the current harness:

• /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.
• 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

get_ci_status, and ci_fetch_job_logs.

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

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

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

• 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

• 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.
• 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.
• 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.
• 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.
• 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.
• 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 |

Resources

No extra references or helper scripts are documented for this skill.

Installation

Install the parent Pi package, then reload Pi so the skill is registered locally.

# From the agent-skills-marketplace repo root
pi install "$PWD/pi-packages/dev-workflow"

# From the Diversio monolith root
pi install "$PWD/agent-skills-marketplace/pi-packages/dev-workflow"

/reload

After install, see Dev Workflow for the parent package's commands and extension behavior.