code/investigate-ci/SKILL.md
Investigates GitHub Actions workflow failures for any repo. Fetches recent runs, identifies failures, extracts error logs, diagnoses root causes, and suggests fixes. Use when a deploy or CI workflow fails and you need to understand why.
npx skillsauth add mostafa-drz/claude-skills investigate-ciInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Investigate GitHub Actions failures — fetch logs, diagnose root causes, suggest fixes.
Read ~/.claude/skills/investigate-ci/preferences.md using the Read tool. If not found, no preferences are set.
On startup, use Bash to detect: current repo (gh repo view --json nameWithOwner -q .nameWithOwner) and default org (gh repo view --json owner -q .owner.login). Skip any that fail.
Check $ARGUMENTS for subcommands:
helpIf $ARGUMENTS is "help" (case-insensitive), display:
Investigate CI — diagnose GitHub Actions failures
Usage:
/investigate-ci <workflow-url> Investigate a specific workflow
/investigate-ci <run-url> Investigate a specific run
/investigate-ci <repo> [workflow] Investigate by repo name
/investigate-ci config Set preferences
/investigate-ci reset Clear preferences
/investigate-ci help This help
Examples:
/investigate-ci https://github.com/org/repo/actions/workflows/deploy.yml
/investigate-ci https://github.com/org/repo/actions/runs/12345678
/investigate-ci ai-stacks deploy.yml
/investigate-ci ai-stacks All failing workflows
/investigate-ci 12345678 Run ID (uses current/default repo)
Current preferences:
[show from preferences.md or "defaults"]
Then stop.
configIf $ARGUMENTS is "config" or "configure", use AskUserQuestion:
Question 1 — "Default organization?" (multiSelect: false)
Question 2 — "How many recent runs to check?" (multiSelect: false)
Question 3 — "Default branch filter?" (multiSelect: false)
Save to ~/.claude/skills/investigate-ci/preferences.md. Display summary. Then stop.
resetIf $ARGUMENTS is "reset", delete preferences.md. Confirm: "Preferences cleared. Using defaults." Then stop.
If $ARGUMENTS is anything else, proceed below.
Extract from $ARGUMENTS:
Full workflow URL — e.g., https://github.com/org/repo/actions/workflows/deploy.yml
Full run URL — e.g., https://github.com/org/repo/actions/runs/12345678
Repo + workflow — e.g., ai-stacks deploy.yml
/), prepend the detected orgRepo only — e.g., ai-stacks
Run ID only — e.g., 12345678
If ambiguous, use AskUserQuestion to clarify.
gh run list --repo <org/repo> --workflow <workflow> --limit <N> --json databaseId,status,conclusion,headBranch,event,createdAt,displayTitle,headSha
If no workflow specified, list all workflows first:
gh workflow list --repo <org/repo> --json name,id,state
Then fetch runs for workflows with recent failures.
Workflow: deploy.yml (org/repo)
Recent runs (last N):
[FAIL] #123 — "Deploy to prod" — main — 2h ago
[PASS] #122 — "Deploy to staging" — main — 5h ago
[FAIL] #121 — "Deploy to prod" — main — 1d ago
[PASS] #120 — "Feature X" — feature/x — 1d ago
If multiple failures, use AskUserQuestion:
If only one failure, investigate it directly.
gh run view <run-id> --repo <org/repo> --json jobs,conclusion,headBranch,headSha,event,createdAt,updatedAt,displayTitle
For each failed job, fetch logs:
gh run view <run-id> --repo <org/repo> --log-failed 2>&1
This returns only the logs from failed steps — much more targeted than full logs.
From the failed step logs, extract:
error, Error, FAILED, fatal, Exception, exit codesgh api repos/<org>/<repo>/commits/<sha> --jq '{message: .commit.message, author: .commit.author.name, date: .commit.author.date, files: [.files[].filename]}'
Analyze the error and categorize:
| Category | Signals | Common fixes |
|---|---|---|
| Dependency | ModuleNotFoundError, npm ERR!, Could not resolve | Lock file out of sync, missing package |
| Build | tsc, SyntaxError, TypeError, compilation errors | Type errors, syntax issues in changed files |
| Test | FAIL, AssertionError, test file paths | Failing tests, snapshot mismatches |
| Deploy | AccessDenied, timeout, connection refused | Permissions, infra issues, env vars |
| Config | invalid workflow, yaml, secrets references | Workflow syntax, missing secrets |
| Flaky | Same commit passed before, timing-related errors | Re-run, increase timeout |
Cross-reference with:
CI Investigation: <workflow> — Run #<id>
Trigger: <event> on <branch> by <author> (<relative time>)
Commit: <sha_short> "<commit message>"
Duration: <time>
Failed job: <job name>
Failed step: <step name>
Error:
<extracted error message, formatted>
Root cause:
<one-paragraph diagnosis>
Changed files in trigger commit:
- file1.py
- file2.ts
Related:
- [Previous run on same branch: PASS/FAIL]
- [Main branch status: PASS/FAIL]
Use AskUserQuestion (multiSelect: true):
Options based on diagnosis:
gh run rerun <id> --repo <org/repo> --failedgh run view <id> --repo <org/repo> --loggh run view <id> --repo <org/repo> --webFor code-related failures, also suggest:
--repo flags.development
--- name: triage-board description: >- Generates a structured triage artifact from the current conversation's findings — a self-contained Desktop folder with a JSON Schema, schema-conformant report.json, prose markdown, and a single-file HTML viewer. Viewer ships with MD / CSV / JSON download buttons in the header and a per-finding "Copy as Markdown" action that produces a GitHub/Linear/Notion-ready ticket block. Stateless — triage state lives in the user's ticket system, not in the
development
Runs a beginner-mind end-to-end UI audit of any running app — local dev server, staging, production, or a specific URL. Drives Chrome through every interactive element on the target surface, collects structured findings (severity, category, where, symptom, impact, repro, triage), and hands the result off to `/triage-board` which produces the Desktop folder (schema + JSON + Markdown + single-file HTML viewer with MD/CSV/JSON exports and a per-finding Copy as Markdown button). Use when you want fresh-eyes verification of a feature, page, modal, flow, branch, or whole app — before shipping, before review, before a demo, or any time the UI deserves a careful poke.
development
Reviews the user's past Claude Code conversations from a wellbeing perspective — sentiment, tone, emotional arc, recurring patterns — and generates a supportive, science-grounded report in both Markdown and HTML. Default lookback is 48 hours across all projects. Uses recognised emotion frameworks (Plutchik, Ekman, Russell's circumplex, Pennebaker linguistic markers) and cites the science behind every observation. Learns the user's baseline tone over time so future reports flag genuine shifts, not noise. Use when the user asks for an emotional/wellbeing recap, mood check, sentiment review, or wants to understand their own ups and downs across recent work sessions.
development
--- name: workflow-advisor description: >- Analyzes recent Claude Code conversations and local Claude state (skills, settings, memory files, CLAUDE.md), researches the latest Claude Code features and best practices online, and suggests one workflow improvement at a time with reasoning and a concrete action item. Can save accepted suggestions to memory for tracking. Use when you want to discover underused Claude Code features, improve your development workflow, stay current with the lat