github-automation

Rube MCP 経由の GitHub 自動化

リポジトリポリシー、正確なリビジョン識別、およびブランチ保護を維持しながら、Rube MCP を通じて Composio の GitHub ツールキットを使用します。

使用する場面

Rube MCP が利用可能な場合に、GitHub の issue、プルリクエスト、ブランチ、Actions、デプロイ、コラボレーター、または保護に関するタスクをプログラムから実行するために使用します。ローカルリポジトリのポリシーが要求する場合は、ネイティブの gh ワークフローまたはリポジトリ固有のメンテナーコマンドを優先してください。

セットアップ

1. RUBE_SEARCH_TOOLS が利用可能であることを確認します。
2. 呼び出しを構成する前に、現在の GitHub ツールスキーマを検索します。
3. ツールキット github を指定して RUBE_MANAGE_CONNECTIONS を使用し、接続がアクティブでない場合にのみ OAuth を完了します。
4. 正確な owner/repo を解決します。類似した名前のリポジトリに依存しないでください。

GitHub の認証情報をプロンプトや成果物内で要求、出力、または永続化しないでください。

リポジトリポリシーゲート

変更を行う前に、AGENTS.md、コントリビューションおよびメンテナー向けドキュメントを読み、次にデフォルトブランチと有効な保護を確認します。リポジトリネイティブのコマンドと必須チェックは、汎用的な Rube 操作よりも優先されます。

リポジトリがガード付きのマージまたはリリースコマンドを提供している場合は、汎用のマージツールではなくそれを使用してください。agentic-awesome-skills では、antigravity-maintainer-batch-release と npm run merge:batch を使用して、正確な SHA によるレビュー、新しいチェックスイートの紐付け、および保護された main が確実に適用されるようにします。

ワークフロー

Issue

1. 重複を作成する前に、既存の issue を一覧表示または検索します。
2. 混在した結果の中で issue とプルリクエストを区別します。
3. 状態を変更する前に、現在の項目、コメント、ラベル、およびリンクされた PR を読みます。
4. 作成、コメント、ラベル付け、アサイン、またはクローズは、ユーザーが要求した範囲内でのみ行います。
5. 項目を再度読み、結果の状態を検証します。

要求された結果セットが完了するまでページネーションします。ラベルまたはアサインの黙示的な省略は、成功ではなく権限の失敗として扱ってください。

プルリクエスト

1. PR を解決し、その番号、ベース、完全なヘッド SHA、ドラフト状態、作成者、フォークの識別情報、およびマージ可否を取得します。
2. 変更されたファイル、レビュー、会話、および必須チェックの実行を確認します。
3. すべてのレビューまたは承認の判断を、現在の完全なヘッド SHA に紐付けます。
4. PR の本文を正確に作成または更新します。保留中のテストやレビューを完了としてマークしないでください。
5. マージの直前に、ベース/ヘッドの識別情報、ブランチ保護、マージ可否、必須チェック、およびリポジトリポリシーを再度読みます。
6. リポジトリのガード付きマージパスを使用します。汎用のマージツールは、ポリシーが許可し、ユーザーがマージを承認した場合にのみ呼び出してください。
7. PR が MERGED を報告することを検証し、ターゲットブランチに意図したコミットが含まれていることを確認します。

自動マージを有効化する、または作業をキューに入れる API 呼び出しの成功を、即時のマージとして扱わないでください。

ブランチと参照

1. ソースコミット SHA とターゲット ref を明示的に解決します。
2. 保護された/デフォルトブランチを直接更新するのではなく、トピックブランチを作成します。
3. ユーザーが明示的に承認し、リポジトリポリシーが許可する場合を除き、非ファストフォワードまたは強制更新を拒否します。
4. 変更後にリモート ref を確認します。

削除、強制プッシュ、デフォルトブランチの変更、および保護の変更は、明示的な承認を必要とする破壊的または影響の大きい操作です。

Actions とデプロイ

1. 信頼できる ID またはパスでワークフローを解決し、ディスパッチ前に workflow_dispatch のサポートを確認します。
2. 実行の検査を、意図したイベント、ref、およびヘッド SHA に紐付けます。
3. queued、in_progress、action_required、completed、および skipped の状態を区別します。
4. ソースの変更を提案する前に、失敗したジョブのログを読みます。
5. 最終的な成功を待ち、デプロイまたは公開されたサーフェスを別途検証します。

リポジトリがガード付きの承認コマンドを提供している場合、生の実行 ID でフォークのワークフロー実行を承認しないでください。

権限と保護

1. 変更を提案する前に、コラボレーター、ロール、ブランチ保護、および該当するルールセットを確認します。
2. 404 保護レスポンスは、リポジトリとブランチの同一性を確認した後にのみ「未設定」として扱います。
3. 保護または権限を変更する前に、正確な変更前/変更後のポリシーと影響を提示します。
4. 変更後、有効な状態を再読み取りします。

失敗時のルール

• Rube がパラメーターの欠落または変更を報告した場合は、ツールスキーマを再解決します。
• リポジトリの曖昧さ、古い head/base SHA、権限の欠落、不完全なページネーション、または結論の出ない保護状態に遭遇した場合は停止します。
• 必須チェック、レビュー、マージキュー、メンテナーコマンド、またはサーバー側のブランチ保護を決してバイパスしません。
• 結果のリモート状態を読み取らずに、マージ、ワークフロー、デプロイ、または権限変更が成功したと主張しません。

例

ユーザーリクエスト:

Rube MCP を通じて GitHub の issue、プルリクエスト、ブランチ、チェック、ワークフロー、および権限を操作します。

制限事項

• 利用可能な Rube ツール名とスキーマは変更される可能性があります。実行時に検出してください。
• GitHub の権限、組織ポリシー、および外部チェックは、それ以外の点では有効な操作をブロックする可能性があります。
• このスキルは、明示的なユーザーの意図を超えたリポジトリの削除、強制プッシュ、保護の変更、マージ、デプロイ、またはリリースを承認するものではありません。