CI Check

Overview

Check remote CI status and investigate failing jobs for the current branch or PR.

This Pi-local skill ships 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.

may exist without published statuses; visible safety jobs do not replace the repository's required aggregate check.

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.
• Missing local-ci contexts leave validation/publication unknown. A local run may exist without published statuses; visible safety jobs do not replace the repository's required aggregate check.
• Deploy helpers such as scripts/deploy/trigger_validated_backend_deploy.sh belong to release/deploy workflows, not this status-check skill.

Process

to have inspected an unavailable tail.

independently of this change. Untouched code or a timeout alone is not proof.

infrastructure problem. Do not bypass a required gate because it is flaky.

• 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 contain only the first 500 lines. State truncation; do not claim to have inspected an unavailable tail.
• 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 — comparable runs show the same intermittent failure independently of this change. Untouched code or a timeout alone is not proof.
• 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.
• Cite the evidence and distinguish intermittent failure from a persistent infrastructure problem. Do not bypass a required gate because it is flaky.
• 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 | Cite comparable runs; gate still failing |

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.