フック

組織レベルの自動化処理で、プラットフォームのイベントに応じてユーザーが記述した指示を実行します。

「フックは Coroid 内で発生した事象に反応します。イベントを選択し、平易な言葉で指示を記述すれば、そのイベントが発生した際にフックが実行されます。

設定場所は設定 → 自動化 → 自動化処理.

反応可能なイベント

カテゴリ	例
タスク	作成、ステータス変更、フェーズ変更、完了、失敗
エージェント	開始、イテレーション、ツール呼び出し、完了、エラー
リポジトリ	コミットプッシュ、ブランチ作成、pull request 開封、pull request マージ
分析	依存関係検出、セキュリティ問題、分析完了
同期	外部ソースの更新
デプロイ	開始、完了、失敗

フックは分析と報告を行います。後続の作業を作成することはできますが、コードを直接変更することはありません。

このデフォルト設定により、安全に導入できます。イベントに応じてコードを編集する自動化処理は、監視が最も行われにくいタイミングで動作します。一方、フックがタスクを開封する場合、通常のプロセス — 仕様策定、計画、検証、レビュー、pull request — を経て同じ結果が得られます。

フックの指示はモデルによって処理されるため、コードではなく同僚への指示のように記述されます。品質基準は仕様と同様です：何を確認すべきか、何が重要か、そして何をすべきかを明記します。

「何もしない」ケースについても具体的に記述してください。これが欠けると、フックは実行されるたびに何かを報告し続け、常に発火するフックは誰も読まなくなります。

イベント駆動型の自動化処理が予測可能な形で失敗するため、3つの保護機能が備わっています。

レート制限分単位、時間単位、日単位で設定可能で、各フックごとに調整できます。頻繁に発生するイベントに対するフックは、繁忙なマージ作業中に何百回も発火する可能性があります。

チェーン深さフックがイベントを発火させ、それが別のフックを呼び出すことがあります。最大チェーン深さにより、ループが発生するのを防ぎます。

ツール権限フックがアクセスできる範囲は制御されており、読み取り専用アクセス、MCP呼び出し、タスク作成などは個別に管理されます。

フックの管理は管理者のみが行えますが、全メンバーがフックとその実行履歴を確認できます。フックが組織レベルで影響を及ぼすことを考慮すると、この非対称性は意図的な設計です。

各フックには配信ログと分析データが保存されます。新しいフックを有効にした後はログを確認してください。失敗の原因はエラーではなく、絶えず発火して誰も対応しない状態です。