CI Monitor

Monitor and interact with CI/CD pipelines (Jenkins, GitHub Actions, GitLab CI). Check build status, trigger builds, analyze failed jobs, view logs. Use when:...

Security Scan

The skill's functionality (monitoring/triggerring CI) is coherent, but the SKILL.md requires credentials and additional tools that are not declared in the skill metadata, and the publisher/source is unknown—these mismatches deserve caution before installing.

Purpose & Capability

The declared purpose (Jenkins, GitHub Actions, GitLab CI monitoring and triggering) matches the runtime instructions: curl/REST and gh CLI commands for listing, viewing logs, and triggering builds. Requiring CI credentials is expected for this purpose.

Instruction Scope

The SKILL.md instructs the agent to use environment variables (JENKINS_URL, JENKINS_USER, JENKINS_TOKEN, GITLAB_TOKEN, PROJECT_ID) and tools (gh, jq, tail, grep) and to trigger builds/logs. Those env vars and binaries are not declared in the skill metadata; instructions therefore reference data and tools outside the skill's declared surface. The commands themselves are scoped to CI tasks and do not direct data to unexpected endpoints, but the omission of declared dependencies/credentials is risky.

Install Mechanism

Instruction-only skill (no install spec, no code files). That minimizes install-time risk since nothing is downloaded or written by the skill itself.

Credentials

The skill needs CI credentials (Jenkins/GitLab tokens, likely GitHub auth) to function, which is proportionate to the purpose. However the skill metadata lists no required env vars or primary credential, so it does not declare the sensitive secrets it will rely on. Also it references multiple credential variables and CLIs without justification or least-privilege guidance.

Persistence & Privilege

The skill does not request always:true and is user-invocable only. It does not attempt to modify other skills or system-wide settings. Autonomous invocation is enabled by default but not combined with other high-privilege requests here.

What to consider before installing

This skill appears to do what it says (monitor and trigger CI), but the metadata is incomplete: the runtime instructions require CI tokens and additional tools (gh, jq) that are not declared. Before installing, verify the source/publisher, and only provide tokens with minimal scopes (read-only where possible, short-lived or revocable). Ensure required CLIs (curl, gh, jq) are installed and that you understand which environment variable names to set (SKILL.md lists them). Test with non-production projects or tokens first. If you plan to let the agent invoke the skill autonomously, be especially careful about granting build-triggering permissions—prefer tokens that cannot modify infrastructure or access unrelated repos.

Monitor, trigger, and analyze CI/CD pipeline status.

When to Use

✅ USE this skill when:

• Checking build/pipeline status
• Analyzing why a CI job failed
• Triggering builds or test runs
• Monitoring deployment progress
• "Jenkins 构建状态怎么样" / "CI 挂了看看什么原因"

❌ DON'T use this skill when:

• Writing/editing Jenkinsfile or CI config → edit files directly
• Managing infrastructure → use DevOps tools
• Code review → use platform web UI or gh CLI directly

Jenkins

Setup

# Set environment variables
export JENKINS_URL="https://jenkins.example.com"
export JENKINS_USER="admin"
export JENKINS_TOKEN="your-api-token"

Common Operations

# List all jobs
curl -s "$JENKINS_URL/api/json?tree=jobs[name,color]" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | jq '.jobs[] | "\(.name): \(.color)"'

# Get last build status
curl -s "$JENKINS_URL/job/{job-name}/lastBuild/api/json" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | jq '{result,duration,timestamp,builtOn}'

# Get console output of last build
curl -s "$JENKINS_URL/job/{job-name}/lastBuild/consoleText" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | tail -50

# Trigger a build
curl -s -X POST "$JENKINS_URL/job/{job-name}/build" \
  --user "$JENKINS_USER:$JENKINS_TOKEN"

# Trigger with parameters
curl -s -X POST "$JENKINS_URL/job/{job-name}/buildWithParameters?BRANCH=develop&ENV=staging" \
  --user "$JENKINS_USER:$JENKINS_TOKEN"

# Get build queue
curl -s "$JENKINS_URL/queue/api/json" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | jq '.items[] | {task: .task.name, why}'

Failure Analysis

When a build fails:

1. Get build result and duration:

curl -s "$JENKINS_URL/job/{job}/lastBuild/api/json" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | jq '{result,duration,timestamp}'

2. Get failed test report:

curl -s "$JENKINS_URL/job/{job}/lastBuild/testReport/api/json" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | jq '{failCount,passCount,skipCount,suites[].cases[] | select(.status=="FAILED") | {name,errorDetails}}'

3. Get console log (last 200 lines):

curl -s "$JENKINS_URL/job/{job}/lastBuild/consoleText" \
  --user "$JENKINS_USER:$JENKINS_TOKEN" | tail -200 | grep -i -E "error|fail|exception" 

4. Summarize findings in this format:

🔴 Build #{number} FAILED
⏱️ Duration: Xm Ys
📋 Tests: X passed, Y failed, Z skipped
❌ Failed tests:
  - TestClass.testMethod: error message
  - TestClass.testMethod2: error message
🔍 Root cause: [analysis based on logs]
💡 Suggestion: [fix suggestion]

GitHub Actions

Uses gh CLI or REST API:

# List recent workflow runs
gh run list --repo owner/repo --limit 10

# View specific run
gh run view {run-id} --repo owner/repo

# View failed step logs
gh run view {run-id} --repo owner/repo --log-failed

# Re-run failed jobs
gh run rerun {run-id} --failed --repo owner/repo

# Trigger workflow
gh workflow run {workflow-name} --repo owner/repo --ref main

GitLab CI

# Set variables
export GITLAB_URL="https://gitlab.example.com"
export GITLAB_TOKEN="your-private-token"
export PROJECT_ID="123"

# List pipelines
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines?per_page=5" | jq '.[] | {id,status,ref,created_at}'

# Get pipeline jobs
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines/{pipeline-id}/jobs" | jq '.[] | {name,status,duration}'

# Get job log
curl -s -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/jobs/{job-id}/trace" | tail -100

# Retry failed pipeline
curl -s -X POST -H "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "$GITLAB_URL/api/v4/projects/$PROJECT_ID/pipelines/{pipeline-id}/retry"

Build Status Summary Format

When reporting build status, use:

📊 CI Status Report - {project}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Build #123 (main)    - PASSED  2m 30s
🔴 Build #122 (develop) - FAILED  5m 10s
🟡 Build #124 (feature) - RUNNING 1m 20s
⚪ Build #125 (hotfix)  - QUEUED