イベントループ

ツールで何かが起きたときに動くループです。プルリクエストが開かれた、課題が割り当てられた、ラベルが付いた。自動コードレビューの正体はこれ — あなたのものであり、書き換えも停止もできるループです。

イベントループは、接続済みのツールで何かが起きたときに動きます。スケジュールも、割り当ての儀式も、プロンプトを打つ人も要りません。プルリクエストが開かれた時点で、誰かがタブを切り替える前にレビューはもう走っています。

その指示は、イベントがすでに運んでいる情報の上に重ねる恒常的なガイドです。マージリクエストや課題は自動的に文脈として渡されます。指示が伝えるのは、それに対してあなたが何をしてほしいかです。

ループを仕掛けられるイベント

イベント 提供元 発火するタイミング
マージリクエストのオープン GitLab MRが開かれた、再オープンされた、新しいコミットで更新された
課題の割り当て GitLab 課題が @taskgoblin ボットに割り当てられた
プルリクエストのオープン GitHub PRが開かれた、再オープンされた、新しいコミットで更新された
課題へのラベル付与 GitHub 課題に taskgoblin ラベルが付いた
課題の割り当て Linear 課題がTaskGoblinエージェントに割り当てられた
課題の割り当て Jira 課題がTaskGoblinアカウントに割り当てられた

「オープン」系のイベントは更新も含むため、レビューのループは繰り返すのではなく突き合わせます。二度目の走行では前回残した指摘を読み、あなたが直したものを解決済みにし、本当に新しいものだけを投稿します。

すでに持っているループ

白紙から始める必要はありません。プロバイダーが組織に存在した瞬間、TaskGoblinはそのプロバイダーの既定ループを入れます。

  • GitLabマージリクエストのレビュー割り当てられた課題の対応
  • GitHubプルリクエストのレビューラベル付き課題の対応
  • Linear割り当てられた課題の対応
  • Jira割り当てられた課題の対応

箱から出したコーディングエージェントに期待される動きを、そのまま再現したものです。違うのは、それがあなたのものである点です。Loopsページに実在するループで、指示は読めますし変えられます。

導入は一度きり、永久にです。既定ループを削除すれば削除されたままで、プロバイダーを再接続しても黙って復活したりはしません。

指示を書き換えることこそ本題

既定のレビュー指示は、正しさ・セキュリティ・保守性を求め、変更が妥当なら黙るよう伝えます。妥当な出発点であって、縛られる方針ではありません。チームは日常的に狭めたり広げたりします。

  • 「セキュリティ問題とデータ損失リスクだけ指摘して。それ以外は不要」
  • 「テストの網羅性に厳しく — 挙動を変えるなら必ずテスト。無ければそう言って」
  • 「新しいエンドポイントがレート制限ミドルウェアを通っているかも確認して」

指示は自由な文章なので、リンターには表現できないものを書けます。あなたたちの規約、過去のインシデント、このチームが何度もやってしまう間違い。

既定版と、その強化版

出荷時はこれです。

このマージリクエストをレビューしてください。正しさ、セキュリティ、保守性に集中し、リンターが拾うようなスタイルの些細な指摘ではなく本当の問題を挙げてください。価値のある箇所にだけインラインコメントを残し、具体的で実行可能な内容にし、変更が妥当なら黙っていてください。

意図的に控えめです。何にでもコメントするレビュアーはミュートされるからです。次は、あるチームがひと月使い、インシデントを一度経験したあとの同じループです。

このマージリクエストを正しさ、セキュリティ、保守性の観点でレビューしてください。スタイルの些細な点ではなく本当の問題を挙げてください。

加えて必ず確認すること: 挙動を変える変更にはテストがあるか。新しいエンドポイントがレート制限ミドルウェアなしで出ていないか。既存のマイグレーションファイルを書き換えていないか。リクエストボディ全体をログに出していないか。他の部分が問題なくても、これらは重大として挙げてください。

MRが400行を超える場合は要約でその旨を述べ、全体を流し読みするのではなくリスクの高いファイルから先にレビューしてください。変更が妥当なら黙っていてください。

二つ目に特別なものは何もありません。誰も開かないWikiに眠っていた組織の知識が、効いてくる瞬間に貼り付いただけです。受け継いだループと、自分のものであるループの違いはそこにあります。

オフスイッチ

ここは二度読む価値があります。そうでなければ不具合に見える挙動を説明しているからです。

ループ管理下のイベントに合致する有効なループがなければ、実行は始まりません。 レビューのループを一時停止すれば、マージリクエストはレビューされなくなります。削除しても同じです。TaskGoblinはWebhookを受け取り続けますが、拠り所となる恒常的な指示がないので、ゴブリンは起きず、課金も発生しません。

挙動を「されるもの」ではなく「持つもの」にした代償です。自動レビューが止まったなら、まず見るべきはそのループがまだ有効かどうかです。

決してループ管理下に置かれないもの

人からの明示的な依頼は、ループの有無にかかわらず必ず実行されます。

  • マージリクエスト、プルリクエスト、課題コメントでの @taskgoblin メンション
  • SlackやMicrosoft Teamsでのメッセージやメンション
  • ゴブリンがすでに取り組んでいるLinear課題への追いコメント
  • Jira課題コメントでのメンション
  • 自身のレビューコメントへの @taskgoblin fix という返信

人が直接頼んだなら、ゴブリンは答えます。ループが司るのは頼まれていない仕事だけです。

複数のループが合致したとき

同じイベントに複数のループを走らせても構いません。一般的なレビュー用と、セキュリティ用の厳しめのもの、といった具合です。複数が合致した場合、ゴブリンには候補の指示がすべて示され、どれが当てはまるかを判断し、その選択を実行に記録します。履歴が正直であり続けるためです。作業自体は単一の実行のままで、ループが増えても一つのマージリクエストに重複レビューが並ぶことはありません。

次に読むもの

  • スケジュールループ — もう一方のトリガー。どんなイベントも知らせてくれない作業のために。
  • 連携を接続する — どのプロバイダーでループを組めるか、それぞれ何が使えるようになるか。
  • 単発の実行 — ループを完全に迂回する直接の依頼。