gh-fix-ci
Gh Pr Checks Plan Fix
Overview
Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix plan and implement after explicit approval.
- If a plan-oriented skill (for example
create-plan) is available, use it; otherwise draft a concise plan inline and request approval before implementing.
Prereq: authenticate with the standard GitHub CLI once (for example, run gh auth login), then confirm with gh auth status (repo + workflow scopes are typically required).
Inputs
repo: path inside the repo (default.)pr: PR number or URL (optional; defaults to current branch PR)ghauthentication for the repo host
Quick start
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"- Add
--jsonif you want machine-friendly output for summarization.
Workflow
- Verify gh authentication.
- Run
gh auth statusin the repo. - If unauthenticated, ask the user to run
gh auth login(ensuring repo + workflow scopes) before proceeding.
- Run
- Resolve the PR.
- Prefer the current branch PR:
gh pr view --json number,url. - If the user provides a PR number or URL, use that directly.
- Prefer the current branch PR:
- Inspect failing checks (GitHub Actions only).
- Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"- Add
--jsonfor machine-friendly output.
- Manual fallback:
gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow- If a field is rejected, rerun with the available fields reported by
gh.
- If a field is rejected, rerun with the available fields reported by
- For each failing check, extract the run id from
detailsUrland run:gh run view <run_id> --json name,workflowName,conclusion,status,url,event,headBranch,headShagh run view <run_id> --log
- If the run log says it is still in progress, fetch job logs directly:
gh api "/repos/<owner>/<repo>/actions/jobs/<job_id>/logs" > "<path>"
- Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
- Scope non-GitHub Actions checks.
- If
detailsUrlis not a GitHub Actions run, label it as external and only report the URL. - Do not attempt Buildkite or other providers; keep the workflow lean.
- If
- Summarize failures for the user.
- Provide the failing check name, run URL (if any), and a concise log snippet.
- Call out missing logs explicitly.
- Create a plan.
- Use the
create-planskill to draft a concise plan and request approval.
- Use the
- Implement after approval.
- Apply the approved plan, summarize diffs/tests, and ask about opening a PR.
- Recheck status.
- After changes, suggest re-running the relevant tests and
gh pr checksto confirm.
- After changes, suggest re-running the relevant tests and
Bundled Resources
scripts/inspect_pr_checks.py
Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet. Exits non-zero when failures remain so it can be used in automation.
Usage examples:
python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --jsonpython "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40
More from mizchi/chezmoi-dotfiles
empirical-prompt-tuning
agent 向けテキスト指示(skill / slash command / task プロンプト / CLAUDE.md 節 / コード生成プロンプト)を、バイアスを排した実行者に動かしてもらい、両面(実行者の自己申告 + 指示側メトリクス)で評価して反復改善する手法。改善が頭打ちになるまで回す。プロンプトや skill を新規作成・大幅改訂した直後、またはエージェントの挙動が期待通りにならない原因を指示側の曖昧さに求めたいときに使う。
90retrospective-codify
タスク完了時に「最初に失敗した内容」と「最終的に通った解法」を対応付け、最初に知っておくべきだった知見を ast-grep ルール / skill / CLAUDE.md ルールのいずれかに言語化する。試行錯誤の末にたどり着いた解や、同じ落とし穴を将来の自分(または別エージェント)に繰り返させたくないときに使う。ユーザーから「今回の学びをルール化して」「skill にして」「lint に落として」と指示されたとき、またはタスク終了時に学びを棚卸しする場面で起動する。
17conventional-changelog
Conventional Commits 規約と CHANGELOG 自動生成の横断リファレンス。commit 書式、Keep a Changelog 形式、semver タグ運用、release-please / changesets / git-cliff / towncrier 等の生成ツール比較を含む。新規リポジトリで release フローを整備するとき、既存 repo の commit 規約を統一するとき、言語に合った changelog ツールを選ぶとき、release-please 以外の選択肢を検討するときに使う。
14playwright-test
Playwright Test (E2E) のベストプラクティスとリファレンス。テストの書き方、固定 wait 回避、ネットワークトリガー、DnD、GitHub Actions での shard/retry 設定など。Playwright テストを書く・レビュー・CI 設定するときに使用。
13ast-grep-practice
ast-grep をプロジェクト lint ツールとして運用するためのガイド。sgconfig.yml 設定、fix/rewrite ルール、constraints、transform、テスト、CI 統合、既存 linter との使い分けを扱う。汎用 linter で表現できないルールを ast-grep で書くときに使用。
13devbox
devbox 開発環境管理ツールのリファレンス。Nix ベースの再現可能な開発環境、GitHub Actions での使用例を提供。
9