mcpField
M
mcp-gitlab-usage

mcp-gitlab-usage

github.com/nextstage-brasil開発0166 回インストール1 週間前に更新
リポジトリ

mcp-gitlab-usage について

要件整理、計画、イシュー実行、納品における GitLab MCP ツールの利用手順を定めるスキルです。事前計画、確認ゲート、プロジェクトの特定、重大なエラー時の停止を重視します。

主な機能

  1. 01GitLab依頼前の計画必須化
  2. 02GitLabスキルのバージョン確認
  3. 03プロジェクト特定と確認ゲート
  4. 04イシューのステータス同期ルール
  5. 05納品報告とエラー処理

活用シーン

  1. 01GitLabの要件やイシューの計画
  2. 02明示的な確認後のイシュー作成
  3. 03実行中のイシュー状態の同期

MCP 対応

必須引数、呼び出し前のスキーマ確認、ワークフローのゲートなど、GitLab MCP ツールの利用手順を示します。

インストール

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

$npx skills add https://github.com/nextstage-brasil/skills --skill mcp-gitlab-usage

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

同梱ファイル

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

evals/
evals.json
references/
flows.md
tool-catalog.md

詳細

MCP GitLab の使い方

GitLab MCP ツール呼び出しに関する拘束力のあるルールです。ツールのスキーマと詳細なフローはリファレンスに記載されています。ツールを呼び出す前に、それらを読んでください。

ハーネスの検出

../../ns-harness/references/harness-discovery.md を参照してください。GitLab の製品設定（ステータスラベル、プロジェクト ID）については、存在する場合は {product_root}/docs/context/gitlab-sync-config.md を読んでください。

最初のアクション（重要）

人間から GitLab の要件、計画、またはイシューについて依頼された場合：

  1. 最初のアクションとして、推定した引数を指定して start_execution_planning を呼び出してください。ツールの応答がある前に、計画の文章、RF の提案、イシューの説明を出力してはいけません。
  2. MCP ツールが利用できない場合： GitLab MCP はこのコンテキストでは利用できない、とそのまま伝えてください。実行できないペイロードを出力してはいけません。

初回アクセスとバージョン確認

get_mcp_gitlab_skill を公開している GitLab MCP サーバーに接続するとき：

  1. check_version: true のみを指定して呼び出してください。
  2. サーバーのバージョンを、存在する場合はローカルの MCP スキルのコピーと比較してください。
  3. 不足している場合、またはバージョンが異なる場合に限り、for_update: true を指定して呼び出してください。
  4. check_version と for_update を同時に渡してはいけません。

必須の実践事項

  • 常に arguments を渡してください — 必須フィールドが空のままツールを呼び出してはいけません。
  • 慣れていない呼び出しを行う前に、ツールのスキーマを読んでください。
  • 計画の手順を省略してはいけません — MCP のフローを完全に実行してください。「適用するためのペイロード」を返してはいけません。
  • プロジェクトの検出： git remote get-url origin → パスを MCP に送信 → 人間が完全な 3 項目（id、name、path_with_namespace）を確認した後に数値の project_id を使用します。

確認ゲート（必須）

コンテキストから推測してはいけません：

フラグ次の場合に限り true に設定
requirements_confirmed要件の検証を行うことに人間が「はい」と回答した場合
projects_confirmedすべてのプロジェクトの 3 項目（メイン、バックエンド、フロントエンド）を人間が確認した場合
issues_creation_confirmed「GitLab にイシューを作成しますか？」に人間が「はい」と回答した場合

「すべてやってください」のような広範な依頼は、確認ではありません。

実行の同期（ステータスラベル）

イシューごとに 3 ステップのサイクルを実行します — 中間のステップを決して省略してはいけません：

status_backlog → status_in_progress → status_done

ラベル名は gitlab-sync-config.md から読み取るか、list_project_labels で検出してください。完全なフローについては references/flows.md を参照してください。

イシュー実行時の SOURCE_BRANCH： ns-execution-gitlab-issue の Gate 1 で解決します — マイルストーン／バージョンの検出と、必須の develop フォールバック（../ns-execution-gitlab-issue/references/source-branch-resolution.md）。このスキルに処理を委任する場合、場当たり的にベースブランチを選んではいけません。

提出レポート

  1. イシューの対象（project_id + issue_iid または URL）を確認します。
  2. 合意したベースブランチとの差分を要約します。
  3. internal: true を指定して add_issue_comment を呼び出します。

SDD の提出単位

docs/versions/{version_san}/delivery-units.md が存在し、Gate 4 の公開が「はい」の場合：references/flows.md の SDD delivery-unit publish フローを実行します。単位ごとに 1 つのイシューを作成してください — task-NNN ごとに作成したり、バージョン全体で 1 つだけ作成したりしてはいけません。

関連スキル

  • 実装中のボード同期： ns-gitlab-board-sync（ここでステータス同期のルールを重複して記載しないでください）。
  • イシュー実行ワークフロー： ns-execution-gitlab-issue。

リファレンス

ファイル読むタイミング
references/tool-catalog.mdツール呼び出しの前 — 必須の引数と例
references/flows.md計画、イシュー作成、実行同期、提出レポート
../ns-spec-driven/references/gates.mdSDD の計画ゲート
../../ns-harness/references/artifact-layout.mdrequirements.md とバージョンのパス

エラー処理 — 停止

Plan limit exceeded または同様の重大な MCP エラーが発生した場合は、すべての GitLab 操作を停止し、人間に報告して、指示を待ちます。回避策はありません。

コメント

Markdown 対応