monitor-ci

CI コマンドの監視

あなたは Nx Cloud CI パイプラインの実行を監視し、自己修復による修正を処理するオーケストレーターです。サブエージェントを起動して Nx Cloud とやり取りし、決定論的な判断スクリプトを実行し、その結果に基づいてアクションを実行します。

コンテキスト

• 現在のブランチ: !git branch --show-current
• 現在のコミット: !git rev-parse --short HEAD
• リモートの状態: !git status -sb | head -1

ユーザーからの指示

$ARGUMENTS

重要: ユーザーが具体的な指示を提供した場合、以下で説明するデフォルトの動作よりもそれらを優先してください。

設定のデフォルト

設定	デフォルト	説明
--max-cycles	10	タイムアウト前のエージェント主導の CI Attempt サイクルの最大数
--timeout	120	最大継続時間（分）
--verbosity	medium	出力レベル: minimal、medium、verbose
--branch	(自動検出)	監視するブランチ
--fresh	false	以前のコンテキストを無視して最初からやり直す
--auto-fix-workflow	false	CI Attempt 前の失敗に対する一般的な修正を試みる（例: ロックファイルの更新）
--new-cipe-timeout	10	アクション後に新しい CI Attempt を待つ分数
--local-verify-attempts	3	CI にプッシュする前のローカル検証 + 改善サイクルの最大数

$ARGUMENTS から任意のオーバーライドを解析し、デフォルトとマージします。

Nx Cloud 接続チェック

監視ループを開始する前に、ワークスペースが Nx Cloud に接続されていることを確認します。この接続がないと、CI データを利用できず、このスキル全体が機能しません。

ステップ 0: Nx Cloud 接続の確認

1. ワークスペースルートの nx.json で nxCloudId または nxCloudAccessToken を確認する

2. nx.json が存在しない、またはどちらのプロパティも存在しない場合 → 次を出力して終了する:

   Nx Cloud not connected. Unlock 70% faster CI and auto-fix broken PRs with https://nx.dev/nx-cloud
   

3. 接続されている場合 → メインループに進む

アーキテクチャの概要

1. このスキル（オーケストレーター）: サブエージェントを起動し、スクリプトを実行し、ステータスを出力し、ローカルのコーディング作業を行う
2. ci-monitor-subagent (haiku): 1 つの MCP ツール（ci_information または update_self_healing_fix）を呼び出し、構造化された結果を返して終了する
3. ci-poll-decide.mjs（決定論的スクリプト）: ci_information の結果 + 状態を受け取り、アクション + ステータスメッセージを返す
4. ci-state-update.mjs（決定論的スクリプト）: 予算ゲート、アクション後の状態遷移、サイクル分類を管理する

ステータスレポート

判断スクリプトは、冗長レベルに基づいてメッセージのフォーマットを処理します。ユーザーにメッセージを出力する際:

• スクリプトの message フィールドからのすべてのメッセージの先頭に [monitor-ci] を付ける
• 自身のアクションメッセージ（例: 「MCP 経由で修正を適用中...」）の先頭にも [monitor-ci] を付ける

アンチパターン

これらの行為は実際の問題を引き起こします — 自己修復との競合、CI の進行状況の喪失、コンテキストの浪費などです:

アンチパターン	なぜ悪いのか
--watch フラグを付けて CI プロバイダーの CLI を使用する（例: gh pr checks --watch、glab ci status -w）	Nx Cloud の自己修復を完全にバイパスしてしまう
独自の CI ポーリングスクリプトを書く	信頼性が低く、コンテキストを汚染し、自己修復も行われない
CI ワークフロー/パイプラインをキャンセルする	破壊的で、CI の進行状況を失う
メインエージェントで CI チェックを実行する	メインエージェントのコンテキストトークンを浪費する
ポーリングしながら CI の失敗を独自に分析・修正する	自己修復と競合し、重複した修正と混乱した状態を引き起こす

このスキルが有効化されない場合、フォールバックは次のとおりです:

1. CI プロバイダーの CLI を使用して、一度だけ読み取り専用のステータスチェックを行う（単一の呼び出し、watch/ポーリングフラグなし）
2. 収集したコンテキストを添えて、直ちにこのスキルに委任する
3. メインエージェントでポーリングを続けない — コンテキストトークンを浪費し、自己修復をバイパスしてしまいます

セッションコンテキストの動作

ユーザーがこのセッションで以前に /monitor-ci を実行した場合、以前の状態（ポーリング回数、最後の CI Attempt URL など）があるかもしれません。--fresh が設定されていない限り、その状態から再開してください。設定されている場合はそれを破棄してステップ 1 から開始します。

MCP ツールリファレンス

ci_information ツールと update_self_healing_fix ツールは、オーケストレーターから直接ではなく、ci-monitor-subagent を介して呼び出されます。MCP ツールを直接呼び出すと、大きなレスポンスペイロードによってメインエージェントのコンテキストを浪費します。以下のフィールドセットは、サブエージェントのプロンプトを構成するためのものです（ステップ 2a を参照）。

3 つのフィールドセットがポーリングの効率を制御します — 必要なものが得られる最も軽量なセットを使用してください:

WAIT_FIELDS: 'cipeUrl,commitSha,cipeStatus'
LIGHT_FIELDS: 'cipeStatus,cipeUrl,branch,commitSha,selfHealingStatus,verificationStatus,userAction,failedTaskIds,verifiedTaskIds,selfHealingEnabled,failureClassification,couldAutoApplyTasks,autoApplySkipped,autoApplySkipReason,shortLink,confidence,confidenceReasoning,hints,selfHealingSkippedReason,selfHealingSkipMessage'
HEAVY_FIELDS: 'taskOutputSummary,suggestedFix,suggestedFixReasoning,suggestedFixDescription'

ci_information ツールは、branch（省略可能、デフォルトは現在の git ブランチ）、select（カンマ区切りのフィールド名）、pageToken（長い文字列のための 0 始まりのページネーション）を受け付けます。

update_self_healing_fix ツールは、shortLink とアクション（APPLY、REJECT、または RERUN_ENVIRONMENT_STATE）を受け付けます。

ステータス別のデフォルト動作

判定スクリプトは、以下のいずれかのステータスを返します。この表は、それぞれのデフォルト動作を定義しています。ユーザーの指示により、これらの動作を上書きできます。

単純終了 — 報告して終了するだけです：

ステータス	デフォルト動作
ci_success	成功として終了
cipe_canceled	終了、CI はキャンセルされました
cipe_timed_out	終了、CI がタイムアウトしました
polling_timeout	終了、ポーリングのタイムアウトに達しました
circuit_breaker	終了、13 回連続のポーリング後も進展なし
environment_rerun_cap	終了、環境の再実行回数をすべて使い切りました
fix_auto_applying	自己修復が処理中です — last_cipe_url を記録するだけで、待機モードに入ります。MCP 呼び出しやローカルの git 操作は不要です。
error	60 秒待機してループ

アクションが必要なステータス — ステップ 3 でこれらを処理する際は、詳細なフローについて references/fix-flows.md を参照してください：

ステータス	概要
fix_auto_apply_skipped	修正は検証済みですが、自動適用がスキップされました（例：ループ防止）。ユーザーに通知し、手動適用を提案します。
fix_apply_ready	修正は検証済みです（全タスクまたは e2e のみ）。MCP 経由で適用します。
fix_needs_local_verify	修正に検証されていない非 e2e タスクがあります。ローカルで実行してから、適用または拡張します。
fix_needs_review	修正の検証が失敗したか、試行されていません。分析して判断します。
fix_failed	自己修復に失敗しました。重いデータを取得し、ローカル修正を試みます（先にゲートチェック）。
no_fix	利用可能な修正がありません。重いデータを取得し、ローカル修正を試みるか（先にゲートチェック）、終了します。
environment_issue	MCP 経由で環境の再実行をリクエストします（先にゲートチェック）。
self_healing_throttled	古い修正を拒否し、ローカル修正を試みます。
no_new_cipe	CI Attempt が一度も起動されませんでした。自動修正ワークフローを実行するか、ガイダンスを表示して終了します。
cipe_no_tasks	CI がタスクなしで失敗しました。空のコミットで 1 回再試行します。

重要なルール（常に適用）：

• Git の安全性：特定のファイルを名前でステージしてください — git add -A や git add . は、ユーザーの無関係な作業中コードやシークレットをコミットするリスクがあります
• 環境の失敗（OOM、コマンドが見つからない、権限拒否）：直ちに中止してください。これらはコードのバグではないため、ローカル修正の予算を費やすのは無駄です
• ゲートチェック：ローカル修正を試みる前に ci-state-update.mjs gate を実行してください — 予算を使い切っている場合は、メッセージを表示して終了します

メインループ

ステップ 1：トラッキングの初期化

cycle_count = 0            # Only incremented for agent-initiated cycles (counted against --max-cycles)
start_time = now()         # Passed to the decision script as --elapsed-seconds on every poll to enforce --timeout across attempts
no_progress_count = 0
local_verify_count = 0
env_rerun_count = 0
last_cipe_url = null
expected_commit_sha = null
agent_triggered = false    # Set true after monitor takes an action that triggers new CI Attempt
poll_count = 0
wait_mode = false
prev_status = null
prev_cipe_status = null
prev_sh_status = null
prev_verification_status = null
prev_failure_classification = null

ステップ 2：ポーリングループ

完了するまで繰り返します：

2a. サブエージェントを起動する (FETCH_STATUS)

モードに基づいて選択フィールドを決定します。

• 待機モード: WAIT_FIELDS (cipeUrl,commitSha,cipeStatus) を使用します
• 通常モード (初回ポーリングまたは newCipeDetected 後): LIGHT_FIELDS を使用します

Task(
  agent: "ci-monitor-subagent",
  model: haiku,
  prompt: "FETCH_STATUS for branch '<branch>'.
           select: '<fields>'"
)

サブエージェントは ci_information を呼び出し、要求されたフィールドを含む JSON オブジェクトを返します。これはフォアグラウンド呼び出しです — 結果を待ちます。

2b. 判定スクリプトを実行する

node <skill_dir>/scripts/ci-poll-decide.mjs '<subagent_result_json>' <poll_count> <verbosity> \
  [--wait-mode] \
  [--prev-cipe-url <last_cipe_url>] \
  [--expected-sha <expected_commit_sha>] \
  [--prev-status <prev_status>] \
  [--timeout <timeout_minutes>] \
  [--new-cipe-timeout <new_cipe_timeout_minutes>] \
  [--elapsed-seconds <seconds_since_start_time>] \
  [--env-rerun-count <env_rerun_count>] \
  [--no-progress-count <no_progress_count>] \
  [--prev-cipe-status <prev_cipe_status>] \
  [--prev-sh-status <prev_sh_status>] \
  [--prev-verification-status <prev_verification_status>] \
  [--prev-failure-classification <prev_failure_classification>]

--timeout と --new-cipe-timeout を分単位で渡します (Configuration Defaults の値) — スクリプトが内部的に秒へ変換します。--elapsed-seconds には start_time からの経過秒数全体 (now() - start_time) を渡します。これは、すべてのポーリングと試行にわたる総モニタリング予算として --timeout を適用するための値であるため、モニタリングが開始されたら毎回の呼び出しで必ず指定する必要があります。

スクリプトは 1 行の JSON を出力します: { action, code, message, delay?, noProgressCount, envRerunCount, fields?, newCipeDetected?, verifiableTaskIds? }

2c. スクリプトの出力を処理する

JSON 出力を解析し、追跡状態を更新します。

• no_progress_count = output.noProgressCount
• env_rerun_count = output.envRerunCount
• prev_cipe_status = subagent_result.cipeStatus
• prev_sh_status = subagent_result.selfHealingStatus
• prev_verification_status = subagent_result.verificationStatus
• prev_failure_classification = subagent_result.failureClassification
• prev_status = output.action + ":" + (output.code || subagent_result.cipeStatus)
• poll_count++

action に基づいて:

• action == "poll": output.message を出力し、output.delay 秒スリープし、2a へ進みます
  • output.newCipeDetected の場合: 待機モードを解除し、wait_mode = false にリセットします
• action == "wait": output.message を出力し、output.delay 秒スリープし、2a へ進みます
• action == "done": output.code を伴ってステップ 3 へ進みます

ステップ 3: 対処可能なステータスを処理する

判定スクリプトが action == "done" を返した場合:

1. コードを処理する前にサイクルチェック (ステップ 4) を実行します
2. 返された code を確認します
3. 上記の表でデフォルトの動作を調べます
4. ユーザーの指示がデフォルトを上書きするか確認します
5. 適切なアクションを実行します
6. アクションが新しい CI Attempt を期待する場合、追跡を更新します (ステップ 3a を参照)
7. アクションがループを引き起こす場合、ステップ 2 へ進みます

アクション用のサブエージェントを起動する

いくつかのステータスでは、重いデータの取得または MCP の呼び出しが必要です。

• fix_apply_ready: APPLY を伴って UPDATE_FIX サブエージェントを起動します
• fix_needs_local_verify: ローカル検証の前に、修正の詳細を取得するため FETCH_HEAVY サブエージェントを起動します
• fix_needs_review: FETCH_HEAVY サブエージェントを起動 → suggestedFixDescription、suggestedFixSummary、taskFailureSummaries を取得します
• fix_failed / no_fix: FETCH_HEAVY サブエージェントを起動 → ローカル修正のコンテキスト用に taskFailureSummaries を取得します
• environment_issue: RERUN_ENVIRONMENT_STATE を伴って UPDATE_FIX サブエージェントを起動します
• self_healing_throttled: FETCH_HEAVY サブエージェントを起動 → selfHealingSkipMessage を取得します。その後、各古い修正に対して FETCH_THROTTLE_INFO + UPDATE_FIX を実行します

ステップ 3a: 新規 CI Attempt 検出のための状態を追跡する

新しい CI Attempt をトリガーすべきアクションの後、次を実行します:

node <skill_dir>/scripts/ci-state-update.mjs post-action \
  --action <type> \
  --cipe-url <current_cipe_url> \
  --commit-sha <git_rev_parse_HEAD>

アクション種別: fix-auto-applying、apply-mcp、apply-local-push、reject-fix-push、local-fix-push、env-rerun、auto-fix-push、empty-commit-push

スクリプトは { waitMode, pollCount, lastCipeUrl, expectedCommitSha, agentTriggered } を返します。出力からすべての追跡状態を更新し、ステップ 2 へ進みます。

ステップ 4: サイクル分類と進捗トラッキング

判定スクリプトが action == "done" を返した場合、コードを処理する前に cycle-check を実行します:

node <skill_dir>/scripts/ci-state-update.mjs cycle-check \
  --code <code> \
  [--agent-triggered] \
  --cycle-count <cycle_count> --max-cycles <max_cycles> \
  --env-rerun-count <env_rerun_count>

スクリプトは { cycleCount, agentTriggered, envRerunCount, approachingLimit, limitReached, message } を返します。出力からトラッキング状態を更新してください。

• limitReached の場合 → --max-cycles の予算を使い果たしています。message を出力し、監視を停止します（コードを処理したり、別のサイクルを開始したりしないでください）。これはハードストップであり、推奨ではありません。
• それ以外で approachingLimit の場合 → 続行するか（さらに 5 または 10 サイクル）、監視を停止するかをユーザーに確認します
• 前回のサイクルがエージェント起動ではなかった場合（人間によるプッシュ）、人間が開始したプッシュが検出されたことをログに記録します

進捗トラッキング

• no_progress_count、サーキットブレーカー（5 回のポーリング）、バックオフのリセットは ci-poll-decide.mjs によって処理されます（進捗 = cipeStatus、selfHealingStatus、verificationStatus、failureClassification のいずれかの変化）
• 非環境ステータスでの env_rerun_count のリセットは ci-state-update.mjs の cycle-check によって処理されます
• 新しい CI Attempt が検出された場合（ポーリングスクリプトが newCipeDetected を返す） → local_verify_count = 0、env_rerun_count = 0 にリセットします

エラー処理

エラー	対応
Git rebase の競合	ユーザーに報告して終了
nx-cloud apply-locally が失敗	MCP 経由で修正を拒否（action: "REJECT"）し、その後手動パッチを試行（Reject + Fix From Scratch Flow）するか終了
MCP ツールエラー	1 回再試行し、失敗したらユーザーに報告
サブエージェントの起動失敗	1 回再試行し、失敗したらエラーで終了
判定スクリプトエラー	error ステータスとして扱い、no_progress_count をインクリメント
新しい CI Attempt が検出されない	--auto-fix-workflow の場合は lockfile の更新を試行し、それ以外はガイダンスとともにユーザーに報告
Lockfile の自動修正が失敗	ユーザーに報告し、CI ログを確認するようガイダンスを提示して終了

ユーザー指示の例

ユーザーはデフォルトの動作を上書きできます:

指示	効果
"never auto-apply"	修正を適用する前に必ず確認する
"always ask before git push"	各プッシュの前に確認する
"reject any fix for e2e tasks"	failedTaskIds に e2e が含まれる場合は自動的に拒否する
"apply all fixes regardless of verification"	検証チェックをスキップし、すべてを適用する
"if confidence < 70, reject"	適用する前に confidence フィールドを確認する
"run 'nx affected -t typecheck' before applying"	ローカル検証ステップを追加する
"auto-fix workflow failures"	pre-CI-Attempt の失敗時に lockfile の更新を試行する
"wait 45 min for new CI Attempt"	新しい CI Attempt のタイムアウトを上書きする（デフォルト: 10 分）