Skip to content
Back to skills

Ci Status

ASecurity

Check the CI pipeline status for the current branch after pushing changes. Reports pass/fail with failure details. Use this after every push to confirm your changes are truly done — CI must be green. TRIGGER when: after git push, after committing changes, when asked to check CI, or when verifying that work is complete.

  • 40 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added June 11, 2026
ai-agentsgoshellbashtestinggitapisecurity

Works with

  • cli
  • api

Security analysis

A92/100
  • mediumInstalls packages at runtime which could introduce malicious dependencies

Pro scans all 2 files and shows the line behind each finding

Scanned September 24, 2026

npx -y skills add mifunedev/openharness --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/mifunedev-ci-status/badge)](https://www.skillsdirectory.com/skills/mifunedev-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 the CI pipeline status for the current branch after pushing changes.
  Reports pass/fail with failure details. Use this after every push to confirm
  your changes are truly done — CI must be green.
  TRIGGER when: after git push, after committing changes, when asked to check CI,
  or when verifying that work is complete.
---

# CI Status

Monitor the GitHub Actions CI pipeline for the current branch. A feature is not done until CI passes.

## Instructions

1. **Identify the current branch, commit, and target repo:**

```bash
BRANCH=$(git branch --show-current)
SHA=$(git rev-parse --short HEAD)
echo "Branch: $BRANCH | Commit: $SHA"

# Repo: explicit --repo owner/name, else derive from the current checkout's origin.
# gh repo view resolves the checkout's origin remote — the repo where the branch/PR lives.
# To override (e.g. when testing against a different fork), set REPO_OVERRIDE=owner/name.
if [ -n "$REPO_OVERRIDE" ]; then
  case "$REPO_OVERRIDE" in
    */*) REPO="$REPO_OVERRIDE" ;;
    *) echo "ERROR: --repo must be owner/name format (got '$REPO_OVERRIDE')"; exit 1 ;;
  esac
else
  REPO=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
fi
[ -n "$REPO" ] || { echo "ERROR: could not derive repo — is gh authenticated? Try: gh auth login"; exit 1; }
echo "Repo: $REPO"
```

2. **Prefer an open PR's checks (PR-first path):**

Derive the PR number for the current branch. When multiple open PRs share the head branch (stacked PRs), the first/most-recent is used. An empty `PR_NUMBER` means no open PR and routes to the branch-runs fallback in steps 3–6.

```bash
PR_NUMBER=$(gh pr list --head "$BRANCH" --state open --repo "$REPO" \
  --json number --jq '.[0].number')

if [ -n "$PR_NUMBER" ]; then
  echo "Open PR found: #$PR_NUMBER — checking PR checks directly"
  gh pr checks "$PR_NUMBER" --repo "$REPO"
  # Also available: gh pr view "$PR_NUMBER" --repo "$REPO" --json statusCheckRollup
  # If gh pr checks returns no rows, report NO-RUN (see step 7 — no checks were triggered).
  # Exit here if the PR checks output is definitive (pass/fail visible).
  # Otherwise fall through to the branch-runs fallback below for more detail.
else
  echo "No open PR for branch $BRANCH — using branch-runs fallback"
fi
```

3. **No-PR fallback: find the latest CI run for this branch:**

```bash
gh api "repos/$REPO/actions/runs?branch=$BRANCH&per_page=1" \
  --jq '.workflow_runs[0] | {id: .id, status: .status, conclusion: .conclusion, head_sha: .head_sha[:7], name: .name}'
```

4. **If the run is still in progress, poll every 15 seconds (max 5 minutes):**

```bash
RUN_ID=<id from step 3>
for i in $(seq 1 20); do
  STATUS=$(gh api "repos/$REPO/actions/runs/$RUN_ID" --jq '.status')
  if [ "$STATUS" = "completed" ]; then
    break
  fi
  echo "Still running... ($i/20)"
  sleep 15
done
```

5. **Check the result:**

```bash
gh api "repos/$REPO/actions/runs/$RUN_ID" \
  --jq '{status: .status, conclusion: .conclusion, url: .html_url}'
```

6. **If failed, get the failure details:**

```bash
# Get the failed job ID
JOB_ID=$(gh api "repos/$REPO/actions/runs/$RUN_ID/jobs" \
  --jq '.jobs[] | select(.conclusion == "failure") | .id')

# Get the failure context (15 lines before the error)
gh api "repos/$REPO/actions/jobs/$JOB_ID/logs" 2>&1 \
  | grep -B 15 "Process completed with exit code" | head -25
```

For Eval Probe Regression Gate failures, immediately inspect the failed probe name from the log and run that probe locally. If the product behavior intentionally changed, patch the probe to assert the durable invariant instead of an obsolete exact literal; otherwise fix the product/skill/docs that regressed. Then amend/commit, push, and re-run PR checks.

7. **Report the result:**

- **PASS**: Report "CI green" with the run URL
- **FAIL**: Report the failing step, error message, and suggest a fix. Then fix the issue, commit, push, and run `/ci-status` again
- **NO RUN**: No workflow's `on:` filter matched the push, or `PR_NUMBER` was set but `gh pr checks` returned no rows (the PR exists but no workflows were triggered yet). *(Note: the workflow names below reflect this harness's layout and may differ in other checkouts.)*
  - `ci-harness.yml` — `.agro/**`, `docs/**`, `.devcontainer/**`, `package.json`, `pnpm-lock.yaml`, itself
  - `sandbox-boot-guard.yml` — `.devcontainer/**`, `.agro/cli/**`, `.agro/scripts/**`, `.agro/install/**`
  - Docs site CI/deploy lives in `mifunedev/agro-web`; this repo has no `docs.yml` Docusaurus workflow.
  - `release.yml` — every push to `main` or `master`; validation precedes automatic release publication

  Diagnose with: `git diff --name-only HEAD~1 HEAD` and compare against each workflow's `on:` block.

## CI Pipeline Steps

This project's CI (`CI: Harness`) runs these steps in order:

1. Security audit (`pnpm run security:audit`)
2. Install (`pnpm install --frozen-lockfile`)
3. Typecheck (`pnpm run typecheck`)
4. Build (`pnpm run build:harness`)
5. Test (`pnpm test:scripts`)

Sibling jobs: Boot Path Lint (shellcheck + hadolint) and Eval Probe Regression Gate.

## Local Pre-flight

Before pushing, you can run the same checks locally to catch issues early:

```bash
pnpm run typecheck && pnpm run build:harness && pnpm test
```

Files in this skill

  • LICENSE1.1 KB
  • SKILL.md3.3 KB

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…