github

GitHub

gh CLI を使って、認証、イシュー、PR のライフサイクル、イシューから PR への対応、コードレビュー、リポジトリ管理まで、GitHub の一連の作業を行います（記載箇所では REST にフォールバックします）。このスキルは、以前の 6 つのスキルを統合したものです。各ワークフローの全手順は対応するリファレンスファイルに記載されています。ワークフローを開始する前に、必ず対応するリファレンスを読んでください。以下は参照先を案内するだけです。

参照先

タスク	最初に読むファイル
認証の問題／新しいマシン／トークンまたは SSH の設定／gh login	references/auth.md
イシューの作成、トリアージ、ラベル付け、担当者の割り当て、クローズ	references/issues.md
ブランチ作成、コミット、PR の作成、CI の監視、マージ	references/pr-workflow.md
イシューを検証済みの PR まで対応（全デリバリーループ）	references/issue-to-pr.md
他の人の PR をレビュー：差分、インラインコメント、判定	references/code-review.md
リポジトリのクローン／作成／フォーク、リモート、リリース	references/repo-management.md

補助アセット：scripts/gh-env.sh と scripts/git-credential-token.py （認証ヘルパー）、templates/（PR 本文、バグ報告、機能リクエスト）、 references/ci-troubleshooting.md、references/conventional-commits.md、 references/github-api-cheatsheet.md、references/review-output-template.md。

基本方針（すべてのワークフローに適用）

• セッションごとに事前確認を行います：gh auth status。失敗した場合は、ほかのことをする前に references/auth.md を参照してください。
• 生の REST より gh を優先し、gh api は porcelain にないエンドポイントでのみ使用してください（該当するものはチートシートに記載されています）。
• gh pr checks を自分で確認せずに CI が成功したと報告してはいけません。また、 state,mergedAt を検証せずにマージ済みと主張してはいけません。
• 書き込みを行う前に、全体の文脈を確認してください：gh issue view --comments / gh pr view --comments。判断はタイトルではなくスレッドに記録されています。
• 何かを作成する前に、重複がないか確認してください： gh pr list --search / gh issue list --search。

検証

• タスクの完了条件は、そのワークフローに対応するリファレンスファイルで定義されています。
• 横断的な要件：リモートの状態（CI、マージ、リリース、イシューの状態）に関するすべての主張は、記憶ではなく、最新の gh による読み取りで裏付けてください。