Hacker Newsに投稿：AI エージェントがプルリクエストのマージ準備ができたかどうかを判断するためのツールを作成しました。

AI コーディングエージェント向けの決定論的 PR 準備検出

Good To Go

AI 補助開発に欠けていた要素 ― いつ実際に完了したかを知ること。

誰も語らない問題

AI コーディングエージェントはソフトウェア開発を変革しています。コードを書き、バグを修正し、レビューコメントに応答し、プルリクエスト（PR）を作成できます。しかし、すべてのエージェントが共通して抱える根本的な問題があります。

「PR がマージ準備完了かどうか」を確実に判断できないこと。

想像してください。「CI を修正し、レビューコメントにも対処する」ように AI エージェントに頼んだとき、何が終了したと判断するのでしょう？

• CI が走っている… 完了？ もう一度確認します。さらに…
• CodeRabbit が 12 件のコメントを残しました… 実際に修正が必要なのはどれで、単なる提案か？
• レビュアーが「X を使うことを検討してください」と書いたとき、それはブロック要因か単なる思考か？
• 未解決スレッドがある… しかしコードは最後のコミットで修正済み。

決定論的な答えが無ければ、エージェントは次のように振る舞います：

1. 無限ループで CI ステータスをポーリングし、トークンを消費する
2. 早期に諦める ― 「変更をプッシュした」(CI が失敗しているにもかかわらず)
3. 行動可能なフィードバックを見逃す ― 情報コメントの海に埋もれる
4. 常に質問し続ける ― 「今は準備できた？ 今度はどう？」

解決策：決定論的 PR 分析

Good To Go は、1 つのコマンドで問題を確実に回答します：

これがすべて。1 コマンド、1 答え。

READY

ACTION_REQUIRED

UNRESOLVED

CI_FAILING

ERROR

曖昧さゼロ。推測不要。無限ループなし。

仕組み

Good To Go は PR を以下の3次元で分析します：

1. CI ステータス集約
   GitHub のチェックランとコミットステータスを統合し、単一の Pass/Fail/Pending 状態にまとめます。複数 CI システム、必須 vs 任意チェック、進行中ランの複雑さを扱います。

2. レビューコメント分類
   すべてのコメントが同じではありません。Good To Go は各コメントを次のように分類します：

   • ACTIONABLE

     – マージ前に修正が必要（ブロッキング課題、重大バグ）

   • NON_ACTIONABLE

     – 無視しても安全（称賛、細かい指摘、既解決項目）

   • AMBIGUOUS

     – 人間の判断が必要（提案・質問）

   事前に組み込まれたパーサは人気自動レビュアーのパターンを理解します：

   • CodeRabbit – Severity 指標 (

     Critical/Major/Minor/Trivial

     )、細かい指摘、解決マーカー
   • Greptile – Severity マーカー、PR 要約検出、行動可能数
   • Claude Code – ブロッキングマーカー、承認パターン、タスク完了サマリー
   • Cursor – バグ severity レベル (

     Critical/High/Medium/Low

     )

3. スレッド解決追跡
   実際に未解決の議論と、技術的には「未解決」だが後続コミットで既に対処済みのスレッドを区別します。

AI エージェント向けに設計

Good To Go は AI エージェントの動作に合わせて設計されています：

• 意味ある終了コード
  デフォルトモードは「解析可能な状態なら必ず

  0

  」を返します。AI エージェントは JSON 出力をパースし、終了コードをエラーと解釈しません。

  # AI フレンドリー（デフォルト）：exit 0 + parse JSON
  gtg 123 --format json
  
  # シェルスクリプト向け：意味ある終了コード
  gtg 123 -q   # 静かモード、終了コードのみ
  

• 構造化された出力
  すべての応答はエージェントがアクションを起こすために必要な情報だけを含みます：

  {
    "status": "ACTION_REQUIRED",
    "action_items": [
      "Fix CRITICAL comment from coderabbit in src/db.py:42",
      "Resolve thread started by @reviewer in api.py"
    ],
    "actionable_comments": [...],
    "ci_status": {...},
    "threads": {...}
  }
  

• 状態永続化
  エージェントセッション間で既に処理済みの項目を追跡します：

  gtg 123 --state-path .goodtogo/state.db   # キャンセルしたコメントを記憶
  gtg 123 --refresh                         # 強制的に再分析
  

ユースケース

• CI ゲートとして –

  gtg

  を必須ステータスチェックに設定し、PR が本当に準備できるまでマージをブロックします。

  - name: Check PR readiness
    run: gtg $ --semantic-codes
  

• エージェントワークフロー内で – 無限ポーリングの代わりに確実な答えを AI エージェントへ渡します。

  result = subprocess.run(["gtg", pr_number, "--format", "json"], ...)
  data = json.loads(result.stdout)
  
  if data["status"] == "READY":
      merge_pr()
  elif data["status"] == "ACTION_REQUIRED":
      for item in data["action_items"]:
          address_feedback(item)
  

• PR シェパード – PR のライフサイクル全体を監視します。

  while true; do
    gtg 123 -q
    case $? in
      0) echo "Ready to merge!"; break ;;
      1) handle_comments ;;
      2) resolve_threads ;;
      3) wait_for_ci ;;
    esac
    sleep 60
  done
  

クイックスタート

# インストール
pip install gtg

# GitHub トークンを設定
export GITHUB_TOKEN=ghp_...

# PR をチェック（git origin からリポジトリ自動検出）
gtg 123

# 明示的にリポジトリ指定
gtg 123 --repo owner/repo

# 人間が読める形式で表示
gtg 123 --format text

フィロソフィー

Good To Go は PR ワークフローに関して以下の意見を持ちます：

• ヒューリスティックより決定論 – どんな PR も常に1つのステータスしか持たない
• 完全性より行動可能性 – 必要なアクションだけを提示し、すべてではなく
• エージェント第一設計 – 構造化出力・意味あるデフォルト・状態永続化
• 不確実時はオープンにする – 人間レビューへフラグを立て、ブロックにはしない

リンク集

• GitHub リポジトリ
• PyPI パッケージ
• 完全ドキュメント
• コントリビューションガイド

Claude Code で作成：David Sifry