github
GitHub のissue管理、PRステータス確認、CIログ取得、コメント・レビュー投稿、リリース操作、APIクエリ実行など、`gh` コマンドを通じてGitHub上のあらゆる操作を行う際に使用します。
description の原文を見る
Use gh for GitHub issues, PR status, CI/logs, comments, reviews, releases, and API queries.
SKILL.md 本文
GitHub スキル
gh CLI を使用して、GitHub リポジトリ、issue、PR、CI と連携します。
使用するべき場合
✅ このスキルを使用する場合:
- PR のステータス、レビュー、またはマージ準備状況の確認
- CI/ワークフロー実行ステータスとログの表示
- issue の作成、クローズ、またはコメント
- プルリクエストの作成またはマージ
- リポジトリデータについて GitHub API にクエリを実行
- リポジトリ、リリース、またはコラボレーターのリスト表示
使用しないべき場合
❌ このスキルを使用しない場合:
- ローカル git 操作 (commit、push、pull、branch) →
gitを直接使用 - 非 GitHub リポジトリ (GitLab、Bitbucket、セルフホスト) → 別の CLI を使用
- リポジトリのクローン →
git cloneを使用 - 実際のコード変更の確認 →
coding-agentスキルを使用 - 複雑なマルチファイル diff →
coding-agentを使用またはファイルを直接読み込み
セットアップ
# 認証 (1回限り)
gh auth login
# 確認
gh auth status
ゲートウェイ HOME がオペレータ HOME と異なる場合
OpenClaw エージェントシェルは、多くの場合 gh auth login を実行したユーザーとは異なる HOME で実行されます (エージェント codex ホーム、systemd User= サービス、sudo など)。gh はその設定を $GH_CONFIG_DIR、次に $XDG_CONFIG_HOME/gh、次に $HOME/.config/gh で検索するため、オペレータログインが有効でも、エージェントシェルは not logged into any GitHub hosts と報告する場合があります。
ゲートウェイを正規の gh 設定に指定するには、サービス環境に GH_CONFIG_DIR を設定してください。例:
# ゲートウェイサービス env ファイル (例: ~/.openclaw/gateway.systemd.env)
GH_CONFIG_DIR=/path/to/operator/.config/gh
その後、ゲートウェイを再起動してください。openclaw doctor は、エージェントプロセスの有効な gh 設定ディレクトリの外で認証された hosts.yml を検出した場合に警告します。
一般的なコマンド
プルリクエスト
# PR のリスト表示
gh pr list --repo owner/repo
# CI ステータスの確認
gh pr checks 55 --repo owner/repo
# PR 詳細の表示
gh pr view 55 --repo owner/repo
# PR の作成
gh pr create --title "feat: add feature" --body "Description"
# PR のマージ
gh pr merge 55 --squash --repo owner/repo
Issue
# Issue のリスト表示
gh issue list --repo owner/repo --state open
# Issue の作成
gh issue create --title "Bug: something broken" --body "Details..."
# Issue のクローズ
gh issue close 42 --repo owner/repo
CI/ワークフロー実行
# 最近の実行のリスト表示
gh run list --repo owner/repo --limit 10
# 特定の実行の表示
gh run view <run-id> --repo owner/repo
# 失敗したステップログのみを表示
gh run view <run-id> --repo owner/repo --log-failed
# 失敗したジョブを再実行
gh run rerun <run-id> --failed --repo owner/repo
API クエリ
# 特定のフィールドを持つ PR を取得
gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
# すべてのラベルをリスト表示
gh api repos/owner/repo/labels --jq '.[].name'
# リポジトリ統計を取得
gh api repos/owner/repo --jq '{stars: .stargazers_count, forks: .forks_count}'
JSON 出力
ほとんどのコマンドは --json による構造化出力と --jq フィルタリングをサポートしています:
gh issue list --repo owner/repo --json number,title --jq '.[] | "\(.number): \(.title)"'
gh pr list --json number,title,state,mergeable --jq '.[] | select(.mergeable == "MERGEABLE")'
テンプレート
PR レビューサマリー
# レビュー用の PR 概要を取得
PR=55 REPO=owner/repo
echo "## PR #$PR Summary"
gh pr view $PR --repo $REPO --json title,body,author,additions,deletions,changedFiles \
--jq '"**\(.title)** by @\(.author.login)\n\n\(.body)\n\n📊 +\(.additions) -\(.deletions) across \(.changedFiles) files"'
gh pr checks $PR --repo $REPO
Issue トリアージ
# クイック issue トリアージビュー
gh issue list --repo owner/repo --state open --json number,title,labels,createdAt \
--jq '.[] | "[\(.number)] \(.title) - \([.labels[].name] | join(", ")) (\(.createdAt[:10]))"'
注釈
- git ディレクトリ内にない場合は、常に
--repo owner/repoを指定してください - URL を直接使用してください:
gh pr view https://github.com/owner/repo/pull/55 - レート制限が適用されます。繰り返しクエリの場合は
gh api --cache 1hを使用してください
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- steipete
- リポジトリ
- steipete/clawdis
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/steipete/clawdis / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。