Chat依頼で設計からリリースまで進むCLI公開

magiは[graph]、[verify]、[merge]、[release]などのセクションに分かれた設定ファイルmagi.tomlを中心に構成される。実装前には既定で3人のアドバイザーがそれぞれ読み取り専用の設計案を作り、合成役が勝者を選ぶのではなく良い部分を1つの方針に統合する。この段階は[graph]のadviseでオンオフできる。実装は競争方式でも実行でき、候補にA、B、Cとラベルを付け、審査役が順位を付け、割れた場合は議論と投票に移る。[graph]のimplementersの既定値は1だが、magi initが書き出すmagi.tomlでは3に設定されるため、そのまま使うと3つの候補が競う。

レビューのループでは、各レビュアーにレビュー対象のコミットに固定した専用のdetachedワークツリーが割り当てられるため、作業ツリーは変化せず修正役とも衝突しない。[verify]のe2eに書いたコマンドはそのワークツリーで実行され、出力は修正役に渡る。修正役はブロッキング指摘を修正するか、根拠を示して却下できる。R2-1-3のような形式の指摘IDはエージェントではなくmagiが割り当てるため、レビュアーの精度を集計できると作者は述べる。タイムアウトでレビュアーが回答できなかったラウンドは「指摘なし」とは数えない。

作者によれば最大の利点は、依頼と承認の間を埋める作業から解放されたことだという。判断が必要な場面だけ通知が携帯に届き、それ以外は動き続ける。判定の仕組みなどはREADMEにまとめられている。