octocat

使用するタイミング

次の場合にこのスキルを使用します。

• 「GitHub」「issue」「PR」「repo」などの語句がなくても、github.com の URL が貼り付けられたプロンプト
• issue、プルリクエスト、コミット、比較ページ、Actions の実行、リリース、ディスカッション、リポジトリへの GitHub リンク
• Fix https://github.com/owner/repo/issues/123 のようなタスク
• プルリクエストや GitHub issue の作成、レビュー、管理
• リポジトリのセキュリティアドバイザリ（GHSA）、非公開の脆弱性レポート、アドバイザリのコメントの閲覧やトリアージ、トリアージメモの追加や編集
• GHSA の一時的な非公開フォークの作成、およびフォーク内でのエンバーゴ対象の修正 PR の作成
• マージコンフリクトの解決と履歴の書き換え
• pre-commit フックのデバッグと修正
• ブランチの管理と整理
• GitHub Actions のワークフローの最適化
• git コマンドや GitHub ワークフローに関する質問全般

指示

呼び出された場合：

1. プロンプトに GitHub URL が含まれている場合、その URL だけでこのスキルを呼び出す十分な理由とし、まず gh／git で確認します
2. git／GitHub の状況をただちに評価します
3. プロンプトに github.com の URL が含まれている場合、このスキルをただちに有効にし、その URL を該当する gh／git ワークフローに置き換えます
4. GitHub の操作にはすべて gh CLI を使用します（ウェブインターフェースは決して提案しません）
5. 複雑な git 操作は細心の注意を払って実行します
6. pre-commit フックの問題を修正するか、TypeScript のリンティングを typescript-magician に委任します
7. git の署名キー設定は決して変更しません。署名がすでに有効で設定済みの場合はそれを使用します。それ以外の場合は、署名せずに進めます
8. 「Co-Authored-By: Claude」など、AI による帰属表示は絶対に含めません
9. セキュリティアドバイザリの作業では、トリアージの判断を下す前に rules/security-advisory-comments.md を読み、アクセス可能なディスカッションを取得します。アドバイザリの本文だけでは重要な背景が分からない場合があります
10. アドバイザリの状態に関する質問や変更（triage → draft → published、または closed）では、rules/security-advisory-lifecycle.md を読みます。ユーザーから明示的に依頼されない限り、アドバイザリを公開してはいけません
11. エンバーゴ対象のセキュリティ修正では、rules/security-advisory-private-fork-prs.md を読みます。プッシュ先はアドバイザリの一時的な非公開フォークに限定し、PR は gh pr create --repo <fork> を使用してそのフォーク内に作成します。公開リポジトリに対して作成してはいけません

有効化の例

• Fix https://github.com/mercurius-js/mercurius/issues/1227
• Review https://github.com/nodejs/node/pull/12345
• What changed in https://github.com/org/repo/compare/v1.0.0...v1.1.0?
• Check https://github.com/org/repo/actions/runs/123456789
• Investigate https://github.com/org/repo/commit/abcdef1234567890
• Triage https://github.com/org/repo/security/advisories/GHSA-xxxx-xxxx-xxxx, including the discussion
• Add a triage note to the private vulnerability report's advisory
• Open a fix PR in the private fork of https://github.com/org/repo/security/advisories/GHSA-xxxx-xxxx-xxxx

機能

高度な git 操作：

• 履歴を整理するためのインタラクティブリベース（コミットの分割、スカッシュ）
• チェリーピック、二分探索、ワークツリー
• 高度なマージ戦略
• サブモジュールとサブツリーの管理
• Git フックの設定とメンテナンス
• git log/blame/show によるリポジトリの調査

gh CLI を使用した GitHub 操作：

• 適切なテンプレートを使用した PR の作成と管理
• ベースとヘッドを明示し、簡潔でわかりやすい内容で PR を開きます。例：gh pr create --base main --head <branch> --title "<title>" --body-file <file>
• PR を開いた後、gh pr checks <num> --watch 2>&1 で CI を待ち、失敗があれば積極的に修正します
• 慣れていない gh コマンドをガイダンスで使用する前に、gh help <command> で有効性を確認します
• アドバイザリの状態をトリアージからドラフト、公開済み、またはクローズへ変更・追跡します（ライフサイクル）
• リポジトリのセキュリティアドバイザリとコメントを読み取り、REST 経由でアドバイザリのコメントを追加・編集します（ワークフローと制限）
• アドバイザリの一時的なプライベートフォークを作成し、その中で修正 PR を開きます（ワークフロー）
• Issue とプロジェクトボードを処理します
• リリースとアーティファクトを管理します
• リポジトリの設定を行います
• ワークフローと通知を自動化します

PR 本文の書式

gh pr create で PR を作成するときは、--body フラグで改行をエスケープする際の問題を避けるため、--body-file を使用します。

PR の説明はシンプルにします：

• 変更内容を平易な文章で簡潔に記述します
• ## Summary や ## Testing などの小見出しや見出しは追加しません
• テストのセクションは含めません
• アーキテクチャの変更では、追加の背景説明が必要な場合、説明を少し長くしてもかまいません

cat > /tmp/pr-body.md << 'EOF'
Refactor plugin loading so skills are discovered from the registry instead of being hardcoded.
EOF
gh pr create --body-file /tmp/pr-body.md

一時ファイルを使うと、よりすっきりとして信頼性が高く、デバッグも簡単になります。

複雑な操作の検証チェックポイント

インタラクティブリベース： git rebase -i <base> → git log --oneline -n 10 で確認 → コンフリクトが発生した場合：解決し、git add <file> を実行してから git rebase --continue を実行 → git rebase --abort でいつでも中止できます。

マージコンフリクトの解決： git status（コンフリクトを確認） → git diff で調べるかファイルを開く → すべてのマーカーを解決 → git add <resolved-file> → git merge --continue（または git rebase --continue） → git status でクリーンな状態であることを確認します。

ブランチの整理： git branch --merged main → git branch -d <branch> → git push origin --delete <branch> → git fetch --prune。

コミット署名と帰属に関するルール

• git 署名キーの設定（user.signingkey）や、ユーザー／リポジトリ設定の署名モードを絶対に変更しないでください
• コミット署名がすでに有効で正しく設定されている場合は、既存の設定を使って署名付きコミットを作成してください
• 署名が有効になっていない、または設定されていない場合は、署名を強制したり設定したりせず、そのまま署名なしで進めてください
• AI の共同著者表記（例：「Co-Authored-By: Claude」）を絶対に追加しないでください