仕組み
エンドツーエンドの自動化ワークフロー:- トリガー: mainブランチにコードがマージされる
- 探索: Droid execがコードベース構造(プロジェクトタイプ、技術スタック)を探索
- 分析: 変更されたファイルとその目的を特定
- 発見: docs/ディレクトリ内の関連ドキュメントを検索
- 更新: 影響を受けるドキュメントセクションを更新
- コミット: ワークフローがコミットを作成
- PR: Botがチームレビュー用のプルリクエストを開く
前提条件
開始するには、以下が必要です:- Droidのインストール
- Factory APIキー
- Actions が有効化されたGitHub リポジトリ
- リポジトリシークレット内の
FACTORY_API_KEY(Settings → Secrets → Actions) - 既存のドキュメントディレクトリ
Droid Execのセットアップはこちらを参照してください。
完全なGitHub Actions ワークフロー
このワークフローはプルリクエストを自動作成します。正確性を確保するため、生成されたPRはマージ前に慎重に確認してください。
.github/workflows/update-docs.ymlを作成:
- ファイル変更のみに
--auto lowを使用(クックブックパターンに従う) - 明示的な指示:「コミットやプッシュは行わない」(関心事の分離)
- ワークフローが別ステップでgit操作を処理
- Droid が自律的にコードベースを探索し、関連ドキュメントを発見(マッピングファイル不要)
ベストプラクティス
1
トリガー範囲を慎重に設定
意味のあるコード変更でのみトリガーします:
2
安全のため--auto lowを使用
クックブックのパターンに従います:
3
自律的な検出を信頼する
手動マッピングを管理するのではなく、droidに探索させて関連ドキュメントを見つけさせます:
4
常に要約を生成する
レビュー担当者が変更を理解しやすくします:
5
レート制限を考慮する
更新頻度の高いリポジトリでは、スケジュールされたバッチ更新を使用します:
バリエーション
週次包括レビュー
頻繁に変更があるリポジトリの場合、更新を週次レビューにバッチ処理:複数のドキュメントディレクトリ
ドキュメントが複数の場所に分散している場合:言語固有のターゲティング
特定のファイルタイプに焦点を当てる:トラブルシューティング
コードが変更されたのにPRが作成されない
コードが変更されたのにPRが作成されない
Droidがドキュメント更新は不要と判断した可能性があります。ワークフローログを確認するか、プロンプトにより具体的な検索指示を追加してください。
doc-update-summary.mdが作成されている場合は、Droidが分析した内容を確認できます。誤ったセクションが更新される
誤ったセクションが更新される
探索プロンプトを改善し、何を探すかをより具体的にします。どのドキュメントセクションを変更すべきか、または変更すべきでないかを明示することを検討してください。
Droidが関連ドキュメントを見つけられない
Droidが関連ドキュメントを見つけられない
Droid Execに特定のディレクトリ、ファイル名、キーワードを示して、検索指示をより明確にします。候補となるドキュメントの短いリストを提供すると、精度が大きく向上します。
ワークフローがタイムアウトする
ワークフローがタイムアウトする
大規模リポジトリでは以下を検討してください:
- ワークフローのタイムアウトを長くする
- ドキュメント更新をバッチで処理する
- すべてのマージでトリガーする代わりにスケジュール更新を使用する
関連項目
- Droid Exec概要 - 自律性レベルと機能
- GitHub Actionsクックブック - より多くのワークフロー例
- ドキュメント同期フック - 予防的アプローチ
