NambaAI - Codexの作業をSPEC、検証、PR handoffの流れで整理するCLIツール
(github.com/Nam-Cheol)Codexを使う際、曖昧な依頼がそのままコード変更につながる流れに不便さを感じており、これをより構造化された開発手順として整理するCLIツールを作っています。
NambaAIはCodexを置き換えるツールではなく、Codexの周辺で動くワークフローレイヤーに近いものです。
基本的なアイデアは次のとおりです。
request → SPEC → execution → validation → PR handoff
つまり、ユーザーの依頼をすぐに実装へ渡すのではなく、まず目標、範囲、制約事項、受け入れ基準を整理し、それをSPECファイルとして残したうえで作業を進められるよう支援します。
現在は次の流れを中心に構成されています。
namba project
namba plan "作業依頼"
namba run SPEC-XXX
namba sync
namba pr
namba land
複数のSPECを順番に処理するためのqueueフローも試験しています。
このツールを作ることになった理由は、AIコーディングが便利になるほど変更過程が追跡されなかったり、どのような基準で実装されたのかを後から確認しにくいケースが多かったためです。特にCodexを繰り返し使っていると、「何をすることになっていたのか」「どこまでが範囲だったのか」「検証をどう行ったのか」「PRで何を見るべきか」が曖昧になりうると感じました。
NambaAIはこの点を次の方法で減らそうとする試みです。
- 作業前に目標と範囲を先に整理
- 実装前にSPECファイルを生成
- 実行結果と検証evidenceを記録
- PR handoff文書を生成
- Codexが作成した変更点を人がレビューしやすいよう整理
- 単発のプロンプトではなく、再現可能な開発プロセスとして管理
既存のAI agent frameworkのような汎用自律エージェントを作ろうとしているわけではありません。現時点ではCodexを中心に置き、開発者がレビューできる単位に作業を分割して記録することに焦点を当てています。
まだ初期段階のため、不足している部分も多くあります。
- 実際の使用例が不足
- オンボーディング文書の改善が必要
- eval packが不足
- installer/hookのセキュリティレビューが必要
- macOS、Linux、Windowsのクロステストが必要
- 既存のAI coding harnessとの比較が不足
- 実プロジェクトでの検証が不足
自作の初期オープンソースプロジェクトであり、まだ完成度の高い製品というよりは、方向性を検証している段階です。
Codexを業務や個人プロジェクトで使っている方々から、特に以下の点についてフィードバックをいただきたいです。
- このようなSPECベースのCodex workflowが実際の開発プロセスで有用そうか
- どの部分が過剰設計に見えるか
- 実プロジェクトに適用するにはどのような信頼の仕組みがさらに必要か
- 比較してみる価値のある既存ツールやパターンがあるか
- インストール/利用フローで不便または危険に見える部分があるか
批判的な意見でも歓迎です。まだ初期段階なので、今は良い言葉よりも、実際にどこが弱いのかを知ることのほうが役に立ちます。
1件のコメント
CLI を目標に作りましたが、私は最近 codex desktop で使っています！ Codex desktop の内蔵ハーネスと衝突しないか心配していましたが、幸いにも互換性はとてもスムーズです（笑）
このほかにも今回の 0.131.0 codex アップデート内容も反映しないといけませんし、ハーネスはこれしか使っていないので足りない部分も引き続き見えていますが、いちばん足りないのは自分の体ですね……