# Ci

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

- **Type:** Skill
- **Install:** `agentstack add skill-diversioteam-agent-skills-marketplace-ci`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [DiversioTeam](https://agentstack.voostack.com/s/diversioteam)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [DiversioTeam](https://github.com/DiversioTeam)
- **Source:** https://github.com/DiversioTeam/agent-skills-marketplace/tree/main/pi-packages/dev-workflow/skills/ci
- **Website:** https://engineering.diversio.com

## Install

```sh
agentstack add skill-diversioteam-agent-skills-marketplace-ci
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

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

2. **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.

3. **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.

4. **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.

5. **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.

6. **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](https://github.com/DiversioTeam)
- **Source:** [DiversioTeam/agent-skills-marketplace](https://github.com/DiversioTeam/agent-skills-marketplace)
- **License:** MIT
- **Homepage:** https://engineering.diversio.com

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

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-diversioteam-agent-skills-marketplace-ci
- Seller: https://agentstack.voostack.com/s/diversioteam
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.