メニュー
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 ページを確認してインストールできます。
SOC 職業分類に基づく
| 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. |
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.
Use this skill when:
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.
gh) installed and authenticated (gh auth status)act for running workflows locally (brew install act)gh pr checks --watch so status updates in the terminal.act), compare with CI.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.
.../actions/runs/<run-id> or .../actions/runs/<run-id>/jobs/<job-id>run-id (and job-id if present)gh run view <run-id> -R owner/repo
gh run view <run-id> --log-failed -R owner/repo
gh run view <run-id> --job <job-id> --log -R owner/repo
-R owner/repo when already in that repo..../pull/<number> (e.g. .../pull/42)gh pr view <PR> -R owner/repo --json headRefOid -q .headRefOid
gh run list --commit <sha> -R owner/repo
gh run list --commit <sha> --status failure -R owner/repo. Note the run ID from the output (first column), then fetch logs as below.gh run view <run-id> --log-failedgh pr checks <PR> --watch --interval 5From the run (and URL), identify: repository owner/name, run ID, workflow name, branch or commit that triggered the run.
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.
.github/workflows/*.yaml) and environment setupgit checkout <commit-sha> or git checkout <branch>pixi install, pixi run test, npm ci && npm test)act for closer parity:
act -j <job-name> or act to run jobs locallyact may not support every action or secret| 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 .headRefOidgh 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.
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.
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.
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.
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.
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.
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.