購買チームは、NocoBase Core で構築した仕入先管理アプリに、評価とランク分けを追加したいと考えています。購買リーダーの Jordan が業務ルールを確認し、結果を検収します。設計、開発、テスト、レビューはエージェントチームが担います。
納期遵守、品質、価格で仕入先を評価し、A、B、C のランクに分けたい。ランク C の仕入先への発注には、購買マネージャーの承認を必須にする。
- 要件JordanRunner Agent
評価のルールを確認し、検収シナリオを含むタスクにします。
- 割り当てコーディネーターエージェント
タスクとエージェントの得意分野に応じて、設計、続いて開発を割り当てます。
- 確認Jordan
ランク C の仕入先への少額の注文にも承認が必要かを確認します。
- 開発実行エージェント
Core の上に構築し、テストを追加して、PR を作成します。
- チェックとレビューCI実行エージェント
チェックを実行し、独立したレビューを依頼して、問題を修正します。
- 検収Jordan
レポートと検収基準を確認し、マージするか修正を依頼します。
- リリースプロジェクト責任者
チームが本番にデプロイしたあと、バージョンをリリースして Studio に記録します。
- 記憶実行エージェント
確認済みのルールと経験をプロジェクトメモリーに保存します。
要件と検収基準を決める
Jordan は My sessions で Runner Agent と要件を相談します。エージェントは既存の仕入先モジュールを確認し、2 つのルールを確定します。
- 評価の重み：納期遵守 40%、品質 40%、価格 20%。
- 新規の仕入先：ランク B から始め、3 か月後に算出されたランクを付与する。
エージェントは、ルールと検収シナリオを含む PUR-23「仕入先の評価とランク分け」 を作成します。Jordan がタスクを開始し、実行をコーディネーターエージェントに引き渡します。
タスク責任者として、Jordan はセッションで相談を続けることも、タスクに要件を追加することもできます。タスクを作成するほかの方法は 要件を出す を参照してください。
設計を割り振る
この変更は仕入先のデータと発注の承認に影響します。コーディネーターエージェントはまず Claude に方針の設計を依頼します。引き継ぎには、要件、購買規程、評価シート、検証すべき業務シナリオが含まれます。
設計では、スコアの計算方法、ランクの保存方法、既存の承認フローへの組み込み方を説明する必要があります。コーディネーターエージェントは、以降の開発とレビューのステップを各エージェントの得意分野に応じて割り振ります。
承認ルールを確認する
現在の規程では、50,000 ドルを超える発注に承認が必要です。エージェントは、ランク C の新しいルールがそのしきい値未満にも適用されるのかを知る必要があります。
コーディネーターエージェントはタスクを Blocked にし、Needs you で質問します。Jordan は My issues から返信します。
ランク C の仕入先への発注は、金額にかかわらずすべて承認が必要です。ほかの仕入先は、これまでどおり金額のしきい値に従います。
ルールが確定したので、コーディネーターエージェントは開発を Codex に割り振ります。
機能を開発する
Codex はランタイム上で作業します。Core のデータと権限を使って仕入先モジュールを拡張し、発注の承認を更新し、テストを追加します。タスクブランチにコミットして PR を作成し、Studio がそれを PUR-23 にひも付けます。
チェックとレビューを実行する
リポジトリの CI がチェックとテストを実行します。テストで、新規の仕入先に合意した既定のランク B ではなく、ランクが付いていないことがわかりました。コーディネーターエージェントはこの問題を Codex に戻し、Codex が修正してチェックを再実行します。
チェックを通過すると、Claude が評価、承認ルール、テストの網羅性をレビューします。開発、修正、レビューの結果はタスクのアクティビティに残ります。チェックとレビュー を参照してください。
引き渡しを検収する
チェックとレビューを通過すると、タスクは In review に移ります。コーディネーターエージェントは、変更内容、検証、残っている課題をまとめた引き渡しレポートを提出します。Jordan はそれを検収基準と照らし合わせます。
このプロジェクトでは CI と PR プレビューが設定されています。Jordan はプレビューを開き、ランク C の仕入先に 10,000 ドルの発注を作成します。発注には正しく購買マネージャーの承認が求められます。プレビューを使えば実際に操作して検証できます。チェックとプレビューを設定する を参照してください。
結果は要件を満たしています。Jordan が Merge をクリックすると、タスクは Done になります。満たしていなければ、Jordan は修正を依頼して問題を説明し、コーディネーターエージェントがそれを割り振ります。結果を検収する を参照してください。
リリースして本番を記録する
マージ後、プロジェクトの CI が変更をテスト環境にデプロイします。プロジェクトリーダーは Releases で未リリースの作業を確認し、仕入先の評価とランク分けを v1.4.0 に含めます。
チームは本番環境にデプロイし、Studio で v1.4.0 を本番バージョンとして記録します。Studio はバージョンをそのタスクにひも付け、変更を本番反映済みとして示します。リリースの概要 を参照してください。
プロジェクトの知識を残す
エージェントは確定した承認ルールを プロジェクトメモリー に追加し、評価の重みの出典を記録します。メモリーはコードと一緒にレビュー・マージされ、以降のタスクで使われます。
あとから仕入先のランクに応じて支払条件を変えたいという要件が来ても、これらのルール、資料、テストを再利用できます。責任者やエージェントが変わっても、コンテキストはプロジェクトに残ります。
Jordan が行ったこと
Jordan は要件を出し、評価ルールを確認し、承認に関する質問に答え、引き渡しレポートを確認し、結果を試して、マージしました。設計、コーディング、テスト、修正、レビューはエージェントが担いました。
実行中も、Jordan はいつでも要件を追加したり進捗を確認したりできました。進捗を追う を参照してください。