mcpField
G
gitlab-cli-skills

gitlab-cli-skills

github.com/vince-winkintel開発491.9k 回インストール1 日前に更新
リポジトリ

gitlab-cli-skills について

開発者やエージェント向けの GitLab CLI(glab)リファレンススキルです。ドメイン別のワークフローを整理し、書き込み前にアカウントを確認する手順を重視しています。

主な機能

  1. 01ドメイン別の glab スキル案内
  2. 02マージリクエストとイシューの手順
  3. 03CI/CD とリポジトリ操作
  4. 04書き込み前の本人確認
  5. 05コマンド選択のガイダンス

活用シーン

  1. 01イシューやマージリクエストの作成
  2. 02コードレビューとディスカッション管理
  3. 03CI/CD パイプライン障害の調査
  4. 04クローンまたはフォークの選択

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vince-winkintel/gitlab-cli-skills --skill gitlab-cli-skills

インストール後、Claude Code で/gitlab-cli-skillsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

scripts/
ci-debug.sh
create-mr-from-issue.sh
post-inline-comment.py
sync-fork.sh

詳細

GitLab CLI スキル

GitLab CLI(glab)の包括的なコマンドリファレンスとワークフローです。

クイックスタート

# First time setup
glab auth login

# Common operations
glab mr create --fill              # Create MR from current branch
glab issue create                  # Create issue
glab ci view                       # View pipeline status
glab repo view --web              # Open repo in browser

マルチエージェントの識別情報に関する注意

異なるエージェントを異なる GitLab ユーザーとして表示したい場合は、各エージェントに専用の GitLab ボット/サービスアカウントを用意してください。同じ GitLab ユーザーの複数のパーソナルアクセストークンを使っても、表示される識別情報は同じです。

エージェントが作成する GitLab のコメント、返信、承認、その他の書き込みには、実行者の識別情報を使用してください。エージェントの識別情報を使うのは、GitLab での操作がそのエージェント自身の成果物である場合に限ります。最初の GitLab への書き込みより前に、表示する実行者を決めてください。

シェルの識別情報は切り替わらずに残るものであり、デフォルトでは安全でないものとして扱ってください。同じシェル/セッションで別の環境ファイルを先に読み込んでいる場合、意図的に切り替えて確認しない限り、glab は以前に読み込んだ識別情報で書き込む可能性があります。

実用的な方法として、実行者ごとに環境ファイルを用意します。たとえば、~/.config/openclaw/env/gitlab-actor.env、~/.config/openclaw/env/gitlab-reviewer.env、~/.config/openclaw/env/gitlab-release.env のようにします。これらの環境ファイルはバージョン管理の対象外にし、アクセス権を制限し(たとえば chmod 600)、バックアップへの露出に注意し、最小権限のボット/サービスアカウントトークンを使用してください。再利用するシェルでは、古い GitLab 認証変数を先にクリアするか、新しいシェルを開始してください。これらのファイルで通常の KEY=value 形式の行を使用している場合は、glab の実行前に変数をエクスポートして読み込みます。

unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST
set -a
source ~/.config/openclaw/env/gitlab-<actor>.env
set +a

通常の source は現在のシェルを更新しますが、glab などの子プロセスには変数がエクスポートされないことがあります。トークン/ホストの変数がエクスポートされていない場合、glab は有効なグローバル glab 設定ファイルに保存されている共通の認証情報に、気付かれないままフォールバックする可能性があります。その結果、誤ったアカウントが操作を実行したように表示されることがあります。

GitLab への書き込み前に必ず実施する確認

glab mr note、レビューへの返信/承認、glab api の POST/PATCH/PUT/DELETE 呼び出しなど、GitLab に書き込む操作の直前に、必ず次を実行してください。

glab auth status --hostname "$GITLAB_HOST"
glab api --hostname "$GITLAB_HOST" user

これは、対象の実行者用環境ファイルで、変更対象として意図した GitLab インスタンスの GITLAB_HOST が設定されていることを前提としています。両方のコマンドで、そのホスト上の意図した表示名が明確に確認できるまで、書き込みを行わないでください。

誤った識別情報で書き込んだ場合の対処

誤った識別情報でコメントまたは返信を投稿した場合:

  1. 投稿を停止します。
  2. 必要であれば、誤ったコメントまたは返信を削除します。
  3. unset GITLAB_TOKEN GITLAB_ACCESS_TOKEN OAUTH_TOKEN GITLAB_HOST を実行するか、新しいシェルを開始します。
  4. set -a; source ...; set +a で正しい環境ファイルを読み込みます。
  5. glab auth status --hostname "$GITLAB_HOST" と glab api --hostname "$GITLAB_HOST" user を再実行します。
  6. 正しい実行者として再投稿します。
  7. 置き換えたメッセージで、スレッドに誤った表示名が残っていないことを確認します。

誤った識別情報での書き込みが、コメントや返信以外の状態も変更している場合は、コメントの削除手順だけで十分だと考えないでください。上記のとおり再認証したうえで、正しい実行者とホストを使って、その書き込みに対応する GitLab の取り消し操作を行います。たとえば、MR の承認を取り消すか、変更したリソースに対して補償となる glab api --hostname "$GITLAB_HOST" の変更操作を送信します。

スキルの構成

このスキルは、GitLab の領域ごとに専用のサブスキルへ振り分けます。各サブスキルは同階層のディレクトリにある独立したスキルです。詳細については、それぞれの SKILL.md を開いてください。

コアワークフロー:

  • glab-mr - マージリクエスト:作成、レビュー、承認、マージ
  • glab-issue - イシュー:作成、一覧表示、更新、クローズ、コメント
  • glab-ci - CI/CD:パイプライン、ジョブ、ログ、アーティファクト
  • glab-repo - リポジトリ:クローン、作成、フォーク、管理 プロジェクト管理:
  • glab-milestone - リリース計画とマイルストーンの追跡
  • glab-iteration - スプリント/イテレーションの管理
  • glab-label - ラベルの管理と整理
  • glab-release - ソフトウェアのリリースとバージョン管理
  • glab-packages - プロジェクトのパッケージレジストリの一覧表示、フィルタリング、汎用パッケージのアップロード

認証と設定:

  • glab-auth - ログイン、ログアウト、Docker レジストリの認証
  • glab-config - CLI の設定とデフォルト値
  • glab-ssh-key - SSH キーの管理
  • glab-gpg-key - コミット署名用の GPG キー
  • glab-token - 個人用およびプロジェクト用のアクセストークン
  • glab-todo - 個人用 GitLab ToDo のトリアージと完了

CI/CD 管理:

  • glab-job - 個別のジョブ操作
  • glab-schedule - スケジュールされたパイプラインと cron ジョブ
  • glab-variable - CI/CD 変数とシークレット
  • glab-securefile - パイプライン用のセキュアファイル
  • glab-runner - Runner の管理:一覧表示、割り当て/割り当て解除、ジョブ/マネージャーの調査、一時停止/再開、削除
  • glab-runner-controller - Runner コントローラー、スコープ、トークンの管理(EXPERIMENTAL、管理者専用)

コラボレーション:

  • glab-user - ユーザープロフィールと情報
  • glab-snippet - プロジェクトまたは個人用のコードスニペットを作成
  • glab-incident - インシデント管理
  • glab-workitems - 作業項目:タスク、OKR、主要成果、次世代エピック

高度な機能:

  • glab-api - REST API を直接呼び出す
  • glab-artifact-registry - 実験的な短期間有効の Artifact Registry トークン交換とアクセス確認
  • glab-cluster - Kubernetes クラスターとの統合
  • glab-container-registry - コンテナレジストリのリポジトリとタグ
  • glab-dependency-firewall - 実験的な Dependency Firewall のパッケージチェック、パッケージマネージャー用ラッパー、ローカルアクティビティの概要
  • glab-deploy-key - 自動化用のデプロイキー
  • glab-govern - 実験的な AI エージェントのガバナンスフック、診断、トランスクリプト監査の同期
  • glab-orbit - リモートのグラフのステータス確認/クエリ/検出と、ローカルのコードグラフのインデックス作成/検索を行う、管理対象の Orbit CLI ワークフロー。リモートの Orbit ラッパースキルをインストールするには glab-skills を使用してください(EXPERIMENTAL)
  • glab-quick-actions - 状態変更をまとめて実行する GitLab のスラッシュコマンドによるクイックアクション
  • glab-security - プロジェクトのセキュリティスキャンプロファイルの有効化/無効化/ステータス管理(EXPERIMENTAL)
  • glab-stack - ローカルのスタック型/依存型マージリクエストのメタデータを作成、並べ替え、同期、削除
  • glab-opentofu - Terraform/OpenTofu の状態管理 ユーティリティ:
  • glab-alias - カスタムコマンドエイリアス
  • glab-completion - シェルの自動補完
  • glab-help - コマンドのヘルプとドキュメント
  • glab-version - バージョン情報
  • glab-check-update - 更新の確認
  • glab-whatsnew - 最後に閲覧した時点またはアップグレード後の基準時点からのリリースノート
  • glab-changelog - 変更履歴の生成
  • glab-attestation - ソフトウェアサプライチェーンのセキュリティ
  • glab-duo - GitLab Duo AI アシスタント
  • glab-mcp - 非推奨の glab MCP 互換機能。新しい統合にはGitLab MCP Serverを使用してください
  • glab-skills - バンドルされたスキルの確認、バンドル済みまたは厳選されたリモートスキル(Orbit ラッパースキルを含む)のインストール、一覧表示、更新(実験的)

glab と Web UI の使い分け

glab を使う場合:

  • スクリプトで GitLab の操作を自動化する
  • ターミナル中心のワークフローで作業する
  • 複数の MR/イシューを一括操作する
  • 他の CLI ツールと連携する
  • CI/CD パイプラインのワークフローで使用する
  • ブラウザーに切り替えず、すばやく移動する

Web UI を使う場合:

  • インラインコメントを使って複雑な差分をレビューする
  • マージコンフリクトを視覚的に解決する
  • リポジトリの設定や権限を構成する
  • プロジェクト横断で高度な検索やフィルタリングを行う
  • セキュリティスキャンの結果を確認する
  • グループ/インスタンスレベルの設定を管理する

一般的なワークフロー

日常的な開発
# Start work on issue
glab issue view 123
git checkout -b 123-feature-name

# Create MR when ready
glab mr create --fill --draft

# Mark ready for review
glab mr update --ready

# Merge after approval
glab mr merge --when-pipeline-succeeds --remove-source-branch
コードレビュー
# List your review queue
glab mr list --reviewer=@me --state=opened

# Review an MR
glab mr checkout 456
glab mr diff
npm test

# Approve
glab mr approve 456
glab mr note 456 -m "LGTM! Nice work on the error handling."
CI/CD のデバッグ
# Check pipeline status
glab ci status

# View failed jobs
glab ci view

# Get job logs
glab ci trace <job-id>

# Retry failed job
glab ci retry <job-id>

判断フロー

「最初に MR を作成すべきですか、それともイシューに取り組むべきですか?」
Need to track work?
├─ Yes → Create issue first (glab issue create)
│         Then: glab mr for <issue-id>
└─ No → Direct MR (glab mr create --fill)

コーディング前に議論や承認が必要な場合は、glab issue create + glab mr for を使います:

  • コーディング前に議論や承認が必要な作業
  • 機能リクエストやバグの追跡
  • スプリント計画や担当者の割り当て
  • MR のマージ時にイシューを自動的にクローズしたい場合

以下の場合は glab mr create を直接使います:

  • 簡単な修正や誤字の修正
  • 既存のイシューに基づく作業
  • 緊急修正や至急の変更
「どの CI コマンドを使えばよいですか?」
What do you need?
├─ Overall pipeline status → glab ci status
├─ Visual pipeline view → glab ci view
├─ Specific job logs → glab ci trace <job-id>
├─ Download build artifacts → glab ci artifact <ref> <job-name>
├─ Validate config file → glab ci lint
├─ Trigger new run → glab ci run
└─ List all pipelines → glab ci list

クイックリファレンス:

  • パイプラインレベル:glab ci status、glab ci view、glab ci run
  • ジョブレベル:glab ci trace、glab job retry、glab job view
  • アーティファクト:glab ci artifact(パイプライン単位)、または glab job でジョブのアーティファクトを確認
「クローンとフォーク、どちらを選ぶべきですか?」
What's your relationship to the repo?
├─ You have write access → glab repo clone group/project
├─ Contributing to someone else's project:
│   ├─ One-time contribution → glab repo fork + work + MR
│   └─ Ongoing contributions → glab repo fork, then sync regularly
└─ Just reading/exploring → glab repo clone (or view --web)

以下の場合はフォークします:

  • 元のリポジトリへの書き込み権限がない
  • オープンソースプロジェクトに貢献する
  • 元のリポジトリに影響を与えずに試したい
  • 長期的な作業のために自分用のコピーが必要

以下の場合はクローンします:

  • 書き込み権限を持つプロジェクトメンバーである
  • 組織やチームのリポジトリで作業する
  • 個人用のコピーが不要
「プロジェクトラベルとグループラベル、どちらを使うべきですか?」
Where should the label live?
├─ Used across multiple projects → glab label create --group <group>
└─ Specific to one project → glab label create (in project directory)

グループレベルのラベル:

  • 組織全体で一貫したラベル付けができる
  • 例:priority::high、type::bug、status::blocked
  • 一元管理され、プロジェクトに継承される

プロジェクトレベルのラベル:

  • プロジェクト固有のワークフローに使う
  • 例:needs-ux-review、deploy-to-staging
  • プロジェクトのメンテナーが管理する

関連スキル

MR とイシューのワークフロー:

  • glab-issue から始めて、作業を作成/追跡する
  • glab-mr を使って、イシューをクローズする MR を作成する
  • スクリプト:scripts/create-mr-from-issue.sh でこれらを自動化する

CI/CD のデバッグ:

  • パイプラインレベルの操作には glab-ci を使う
  • 個々のジョブの操作には glab-job を使う
  • スクリプト:scripts/ci-debug.sh で失敗をすばやく診断する

リポジトリの操作:

  • リポジトリの管理には glab-repo を使う
  • 認証の設定には glab-auth を使う
  • スクリプト:scripts/sync-fork.sh でフォークを同期する

設定:

  • 初回の認証には glab-auth を使う
  • デフォルトや設定項目の指定には glab-config を使う
  • カスタムショートカットには glab-alias を使う

コメント