一键在 Manus 中运行任何 Skill

debug-github-ci

星标36

分支4

更新时间2026年2月6日 03:46

Debug GitHub Actions and CI failures using gh CLI: watch PR checks, fetch run logs, analyze failures, reproduce locally, and suggest fixes. Use when CI fails, when the user wants to watch or verify CI, or when debugging workflow runs.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

ericmjl

ericmjl/skills

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Debug GitHub CI

This skill guides systematic debugging of GitHub Actions (and other CI) failures and gives a clear way to "pay attention to CI" using the GitHub CLI.

Usage

Use this skill when:

A GitHub Actions (or other CI) workflow has failed and the user wants to fix it
The user says they want to "watch CI," "make sure CI passes," or "pay attention to checks"
The user shares a workflow run URL or asks to debug a failed run

Inputs: the user may give a link to a failing job/run or a link to the PR. Also accepted: PR number, branch name, or run ID. Repo can be overridden with -R owner/repo when not in a git checkout.

Requirements

GitHub CLI (gh) installed and authenticated (gh auth status)
Optional: act for running workflows locally (brew install act)

What It Does

Watch CI — When the user wants to pay attention to CI, run gh pr checks --watch so status updates in the terminal.
Inspect failures — Fetch run metadata and logs for failed jobs.
Analyze — Identify failed job(s), step, and root cause (deps, permissions, timeouts, etc.).
Reproduce — Checkout the same commit, run the same commands (or use act), compare with CI.
Fix — Suggest concrete changes, commands, and preventive steps.

How It Works

1. Watching CI (paying attention to checks)

When the user wants to ensure CI is working or to monitor checks (e.g. after pushing or opening a PR), run:

gh pr checks --watch --interval 5

Run from the repo root. If the current branch is not a PR branch, use:

gh pr checks <PR> --watch --interval 5

Tell the user you're watching CI so they know checks will be monitored. --interval is in seconds (default 10). Optional: --fail-fast to exit watch as soon as any check fails.

2. Handling the user's link

User gives a link to a failing job or run

URLs look like: .../actions/runs/<run-id> or .../actions/runs/<run-id>/jobs/<job-id>
Parse the URL to get run-id (and job-id if present)
Use them directly:

gh run view <run-id> -R owner/repo
gh run view <run-id> --log-failed -R owner/repo

To fetch logs for one specific job:

gh run view <run-id> --job <job-id> --log -R owner/repo

Omit -R owner/repo when already in that repo.

User gives a link to the PR

URL looks like: .../pull/<number> (e.g. .../pull/42)
Get the PR's head commit, then list runs for that commit to find the failed run:

gh pr view <PR> -R owner/repo --json headRefOid -q .headRefOid
gh run list --commit <sha> -R owner/repo

Optionally filter to failed runs only: gh run list --commit <sha> --status failure -R owner/repo. Note the run ID from the output (first column), then fetch logs as below.
Then fetch logs as above: gh run view <run-id> --log-failed
To watch checks for this PR: gh pr checks <PR> --watch --interval 5

3. Extracting workflow information

From the run (and URL), identify: repository owner/name, run ID, workflow name, branch or commit that triggered the run.

4. Fetching logs with GitHub CLI

gh run list --limit 20
gh run view <run-id>
gh run view <run-id> --log
gh run view <run-id> --log-failed

Use --log-failed to focus on failed job logs first.

5. Analyzing the failure

Which job(s) failed and at which step
Error messages, exit codes, stack traces
Common causes: dependency/version issues, permissions, timeouts, resource limits, env differences
Relevant workflow YAML (.github/workflows/*.yaml) and environment setup

6. Reproducing locally

Checkout the same commit or branch: git checkout <commit-sha> or git checkout <branch>
Read the workflow file to see exact commands and environment
Run the same sequence locally (e.g. same install and test commands: pixi install, pixi run test, npm ci && npm test)
Match environment versions (Python, Node, etc.) if specified in the workflow
Optionally use act for closer parity:
- act -j <job-name> or act to run jobs locally
- Note: act may not support every action or secret
Compare local vs CI output and note any environment differences

7. Providing fixes and follow-up

Explain what went wrong in plain terms
Suggest specific fixes: config changes, dependency updates, workflow edits
Give exact commands or code snippets where helpful
Recommend next steps (re-run, re-push, add checks) and how to avoid similar failures
Tailor advice to the project (e.g. Python/pixi vs Node/npm)

Quick reference

Goal	Command
User gave job/run URL	Parse run-id from URL → `gh run view <run-id> --log-failed`
User gave PR URL	`gh pr view <PR> --json headRefOid -q .headRefOid` `gh run list -c <sha> -s failure`
Watch PR checks	`gh pr checks --watch --interval 5`
Run summary	`gh run view <run-id>`
Full logs	`gh run view <run-id> --log`
Failed job logs only	`gh run view <run-id> --log-failed`
Single job log	`gh run view <run-id> --job <job-id> --log`

Focus on actionable, specific solutions. When the user wants to "pay attention to CI," start with gh pr checks --watch --interval 5 and then continue with the rest of the workflow as needed.

同仓库更多 Skills

同仓库

skill-creator

ericmjl/skills

Guide for authoring Agent Skills with strong YAML `description` triggers, progressive disclosure, and bundled resources. Use when creating or updating a skill, running init_skill.py or package_skill.py, or improving a bland skill description so agents load the skill on the right user tasks.

2026-07-0936

awesome-marimo-notebook

ericmjl/skills

Build an awesome marimo notebook that brings a research paper or dataset to life — for competitions, tutorials, demos, or blog companions. Use when asked to "make an awesome marimo notebook," "build a notebook for this paper," "create a competition submission," or pair-program an interactive research explainer on molab. Covers: what makes a notebook engaging (intuition game, real experiment, novel extension, design system), paper selection, narrative arc and proportions, custom anywidget patterns, wigglystuff CellTour, effective GPU usage, memory-efficient training (fused STE, gradient checkpointing), parallel review subagents, and a pre-publication polish checklist. CRITICAL: mo is auto-injected (import in ONE cell); every top-level name must be unique across ALL cells; custom anywidget needs model.save_changes(); use mo.output.replace() for live charts; guard all torch.cuda calls for CPU-only machines.

2026-07-0936

typewriter-video

ericmjl/skills

Create VS Code-style typewriter animation videos with mechanical keyboard sounds. Supports 4 typing speeds, ghost text autocomplete, strikethrough corrections, emoji picker, file tab switching, syntax highlighting (6 languages), Chinese IME (pinyin + direct mode), inline images, image stacks, animated checkboxes, Excalidraw hand-drawn diagrams, 8 visual themes, 4 sound packs, and A-roll narration sync. Built on Remotion (React-based video rendering). Use when the user wants to create code typing videos, explainer B-roll, or typewriter-style animations.

2026-06-1436

remotion-video

ericmjl/skills

Create animated videos using Remotion from topics, product URLs, Google reviews, talking-head videos, CSV data, or channel/brand URLs. Supports 6 video types: educational explainers, product launch demos, testimonial/social proof, avatar video overlays, data visualization dashboards, and lower third overlays. Each follows a 2-step workflow: research/scrape/analyze then design and animate with spring animations, SVG diagrams, and count-up effects. Requires the Remotion best practices skill (install with `npx skills add remotion-dev/skills`). Use when the user asks to create a Remotion video, explainer video, educational video, product demo video, testimonial video, video with animated overlays, data visualization video, animated dashboard, lower third, transparent overlay, short-form vertical video for mobile, or multi-product video from a website.

2026-06-0136

coherent-writing

ericmjl/skills

Improve coherence in drafts through a four-pass sub-agent workflow: resolve argument conflicts, smooth section transitions, smooth paragraph transitions, and run a final coherence audit. Use when a user says things like 'make this coherent', 'tighten the flow', 'this feels choppy', 'can you smooth transitions', or asks to revise prose in Markdown, notes, essays, blog posts, emails, or docs so ideas connect cleanly without adding new points.

2026-05-3036

stacked-pr-decomposition

ericmjl/skills

Break long-lived pull request branches into a mergeable stack of small PRs with clear dependency order and story flow. Use when a branch has grown too large, when the user asks to split a PR into stacked PRs, or when each PR must be reviewable in about 5 minutes while preserving logical narrative across the stack.

2026-05-1536

name	debug-github-ci
description	Debug GitHub Actions and CI failures using gh CLI: watch PR checks, fetch run logs, analyze failures, reproduce locally, and suggest fixes. Use when CI fails, when the user wants to watch or verify CI, or when debugging workflow runs.

Debug GitHub CI

This skill guides systematic debugging of GitHub Actions (and other CI) failures and gives a clear way to "pay attention to CI" using the GitHub CLI.

Usage

Use this skill when:

A GitHub Actions (or other CI) workflow has failed and the user wants to fix it
The user says they want to "watch CI," "make sure CI passes," or "pay attention to checks"
The user shares a workflow run URL or asks to debug a failed run

Requirements

GitHub CLI (gh) installed and authenticated (gh auth status)
Optional: act for running workflows locally (brew install act)

What It Does

Watch CI — When the user wants to pay attention to CI, run gh pr checks --watch so status updates in the terminal.
Inspect failures — Fetch run metadata and logs for failed jobs.
Analyze — Identify failed job(s), step, and root cause (deps, permissions, timeouts, etc.).
Reproduce — Checkout the same commit, run the same commands (or use act), compare with CI.
Fix — Suggest concrete changes, commands, and preventive steps.

How It Works

1. Watching CI (paying attention to checks)

When the user wants to ensure CI is working or to monitor checks (e.g. after pushing or opening a PR), run:

gh pr checks --watch --interval 5

Run from the repo root. If the current branch is not a PR branch, use:

gh pr checks <PR> --watch --interval 5

Tell the user you're watching CI so they know checks will be monitored. --interval is in seconds (default 10). Optional: --fail-fast to exit watch as soon as any check fails.

2. Handling the user's link

User gives a link to a failing job or run

URLs look like: .../actions/runs/<run-id> or .../actions/runs/<run-id>/jobs/<job-id>
Parse the URL to get run-id (and job-id if present)
Use them directly:

gh run view <run-id> -R owner/repo
gh run view <run-id> --log-failed -R owner/repo

To fetch logs for one specific job:

gh run view <run-id> --job <job-id> --log -R owner/repo

Omit -R owner/repo when already in that repo.

User gives a link to the PR

URL looks like: .../pull/<number> (e.g. .../pull/42)
Get the PR's head commit, then list runs for that commit to find the failed run:

gh pr view <PR> -R owner/repo --json headRefOid -q .headRefOid
gh run list --commit <sha> -R owner/repo

Optionally filter to failed runs only: gh run list --commit <sha> --status failure -R owner/repo. Note the run ID from the output (first column), then fetch logs as below.
Then fetch logs as above: gh run view <run-id> --log-failed
To watch checks for this PR: gh pr checks <PR> --watch --interval 5

3. Extracting workflow information

From the run (and URL), identify: repository owner/name, run ID, workflow name, branch or commit that triggered the run.

4. Fetching logs with GitHub CLI

gh run list --limit 20
gh run view <run-id>
gh run view <run-id> --log
gh run view <run-id> --log-failed

Use --log-failed to focus on failed job logs first.

5. Analyzing the failure

Which job(s) failed and at which step
Error messages, exit codes, stack traces
Common causes: dependency/version issues, permissions, timeouts, resource limits, env differences
Relevant workflow YAML (.github/workflows/*.yaml) and environment setup

6. Reproducing locally

Checkout the same commit or branch: git checkout <commit-sha> or git checkout <branch>
Read the workflow file to see exact commands and environment
Run the same sequence locally (e.g. same install and test commands: pixi install, pixi run test, npm ci && npm test)
Match environment versions (Python, Node, etc.) if specified in the workflow
Optionally use act for closer parity:
- act -j <job-name> or act to run jobs locally
- Note: act may not support every action or secret
Compare local vs CI output and note any environment differences

7. Providing fixes and follow-up

Explain what went wrong in plain terms
Suggest specific fixes: config changes, dependency updates, workflow edits
Give exact commands or code snippets where helpful
Recommend next steps (re-run, re-push, add checks) and how to avoid similar failures
Tailor advice to the project (e.g. Python/pixi vs Node/npm)

Quick reference

Goal	Command
User gave job/run URL	Parse run-id from URL → `gh run view <run-id> --log-failed`
User gave PR URL	`gh pr view <PR> --json headRefOid -q .headRefOid` `gh run list -c <sha> -s failure`
Watch PR checks	`gh pr checks --watch --interval 5`
Run summary	`gh run view <run-id>`
Full logs	`gh run view <run-id> --log`
Failed job logs only	`gh run view <run-id> --log-failed`
Single job log	`gh run view <run-id> --job <job-id> --log`

Focus on actionable, specific solutions. When the user wants to "pay attention to CI," start with gh pr checks --watch --interval 5 and then continue with the rest of the workflow as needed.