Skip to content
Back to skills

Ci:Status

ASecurity

Check PR CI status - all checks, failures, test results, and artifacts

  • 299 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 20, 2026
devopsgobashgitapi

Works with

  • api

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add rossoctl/rossoctl --skill ci:status --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ci:Status?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ci:Status
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/rossoctl-ci-status/badge)](https://www.skillsdirectory.com/skills/rossoctl-ci-status)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ci:status
description: Check PR CI status - all checks, failures, test results, and artifacts
---

# CI Status

Check the current CI status for a PR and create task items for any failures.

## Context-Safe Execution (MANDATORY)

**CI log output MUST go to files.** `gh pr checks` is small and OK inline.
`gh run view --log-failed` and artifact downloads MUST redirect:

```bash
export LOG_DIR="${LOG_DIR:-${WORKSPACE_DIR:-/tmp}/rossoctl-ci}"
mkdir -p "$LOG_DIR"

# Small output OK inline:
gh pr checks <PR-number>

# Large output MUST redirect:
gh run view <run-id> --log-failed > $LOG_DIR/ci-run-<run-id>.log 2>&1; echo "EXIT:$?"
# Analyze in subagent: Task(subagent_type='Explore') with Grep on the log file
```

## When to Use

- After pushing changes to a PR
- When asked "what's the CI status?"
- Before deciding whether to push more changes
- After CI completes to summarize results

## Workflow

### 1. Get PR Status

```bash
gh pr checks <PR-number>
```

### 2. Summarize Results

Present as a table:

| Check | Status | Details |
|-------|--------|---------|
| CodeQL | pass/fail | N alerts |
| Deploy & Test (Kind) | pass/fail | N passed, N failed |
| E2E HyperShift | pass/fail/pending | N passed, N failed |
| Build | pass | - |
| Linting | pass | - |

### 3. For Failures - Get Details

```bash
# Kind CI test results
gh run download <run-id> -n e2e-test-results -D /tmp/ci-results
grep -oE 'errors="[0-9]+" failures="[0-9]+" skipped="[0-9]+" tests="[0-9]+"' /tmp/ci-results/e2e-results.xml

# Failed test names
grep '<failure' /tmp/ci-results/e2e-results.xml

# HyperShift logs
gh run view <run-id> --log-failed | tail -30

# CodeQL alerts
gh api repos/<owner>/<repo>/check-runs/<check-id>/annotations --jq '.[] | {path, line: .start_line, message: .message[:100]}'
```

### 4. Create Tasks for Failures

For each distinct failure, create a task:

```
TaskCreate: "<worktree> | <PR> | <topic> | RCA | <failure description>"
```

## Task Tracking

On invocation:
1. TaskList - check for existing CI-related tasks
2. TaskCreate for each new failure found
3. Link to plan doc if failures relate to planned work
4. Metadata: `plan: "ad-hoc"`, `runner: "main-session"`

## Troubleshooting

### CI check not appearing
- Push may not have triggered the workflow
- Check workflow trigger conditions in `.github/workflows/`
- HyperShift E2E requires manual `/test` comment

### Stale results
- CI runs on the commit at push time, not current HEAD
- Check `headSha` matches expected commit

## Related Skills

- `ci:monitoring` - Wait for and monitor running CI jobs
- `rca:ci` - Root cause analysis of CI failures
- `tdd:ci` - TDD iteration using CI as test environment

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.