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
  • 0 views
  • Added October 7, 2026
ai-agentsgoshellbashgitapisecurity

Works with

  • cli
  • api

Security analysis

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

Pro shows the line behind each finding and how to fix it

Scanned October 7, 2026

npx -y skills add mifunedev/agro --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-agro/badge)](https://www.skillsdirectory.com/skills/mifunedev-ci-status-agro)

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

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

# Set REPO_OVERRIDE=owner/name to target another fork; otherwise use the checkout's origin.
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):**

With stacked PRs on one head branch, the most recent is used. No open PR routes to 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"
  # If gh pr checks returns no rows, report NO-RUN (step 7). Stop if pass/fail is visible;
  # otherwise continue to steps 3–6 for 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
```

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/**`
  - `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 job: Boot Path Lint (shellcheck + hadolint).

Run the checks locally before pushing: `pnpm run typecheck && pnpm run build:harness && pnpm test`.

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…