| name | lgtm-loop |
| description | 実装・レビュー (Codex MCP / GPT)・修正の反復ループ。 ユーザーの意図する機能が動くこと (= 機能ゲート pass) と Codex の LGTM を AND で満たすまで回す。 タスク説明 / plan ファイル / 既存 diff のいずれを起点にしてもよい。 実装フェーズは Karpathy 4 原則 (think before / simplicity / surgical / goal-driven) に従う。 "lgtm loop", "LGTMまで回す", "実装してレビューして直して", "実装と修正をループで" などで呼び出す。
|
| user-invocable | true |
| argument-hint | [task description | plans/foo.md | empty for review-only] |
| allowed-tools | Bash(*), Read, Edit, Write, Grep, Glob, Skill, mcp__codex__codex, mcp__codex__codex-reply |
LGTM Loop: 実装・レビュー・修正の反復
ユーザーが意図する機能を実装し、Codex (GPT) によるレビュー → 修正 → 再レビューを LGTM 達成まで反復する。
最終ゴールは ユーザーの意図する機能が動くこと。LGTM はそれを補強するコード品質の安全網であり、ゴール自体ではない。
Context: $ARGUMENTS
定数
モデルと reasoning effort は ~/.codex/config.toml の値を継承する (現状 model = gpt-5.6-sol / model_reasoning_effort = xhigh)。
mcp__codex__codex / mcp__codex__codex-reply 呼び出しで model / config は 指定しない こと。
Codex の最高モデルを切り替えたいときは config.toml の 1 箇所だけを更新すればよい (単一ソース)。
前提
- Codex MCP Server が登録済み (
./nanokit codex-install で自動登録)
mcp__codex__codex / mcp__codex__codex-reply が利用可能karpathy-guidelines skill が同居していると望ましい (Step 1b で auto-invoke 想定)。なければ本文 4 原則を inline 参照
継続レビューは threadId が必要なため MCP 経路を使う。公式プラグイン (/codex:review) は
threadId を返さないので、1 ショットレビューにのみ使い、本ループでは使わない。
Step 0: 起点モード判定
$ARGUMENTS から 3 モードを分岐:
| 引数の形 | モード | 開始ステップ |
|---|
| 空 | review-only | Step 2 から (既存 diff を REVIEW へ) |
plans/*.md のパス | plan-driven | Step 1a から (plan を読んで CRITERIA + IMPLEMENT) |
| それ以外のテキスト | task-driven | Step 1a から (引数を要件に CRITERIA + IMPLEMENT) |
review-only モードでは Step 1a / 1b を skip。既存の uncommitted/branch diff にループ (GATE → REVIEW → FIX) をかける。
Step 1a: CRITERIA — 受け入れ基準を確定
ループの最終ゴールは「ユーザーの意図する機能が動くこと」。タスクから具体的に何が動けば成功かを最初に書き出す。
抽出すべき内容:
- 機能の入出力例 / 受け入れシナリオ (例: 「ログインフォームに不正な email で 422 が返る」)
- 検証手段 (新規 test / 既存 test / 手動確認手順)
- 失敗条件 (どうなったら未完了とみなすか)
曖昧なときは Karpathy 「Think Before Coding」に従い、ユーザーに 1 度確認する。仮定したまま実装に入らない。
Step 1b: IMPLEMENT — 実装
review-only モードでは skip。karpathy-guidelines skill (4 原則) を必ず適用:
- Think Before Coding — 仮定を明示し、不明点はユーザに確認してから書き始める
- Simplicity First — 要求された分だけ書く (speculative な抽象化禁止)
- Surgical Changes — 触れる必要のある行だけ変更、既存スタイル踏襲
- Goal-Driven Execution — Step 1a の受け入れ基準を成功条件として実装。
「test を先に書いてから実装を通す」を基本動作とする
(例: "Add validation" → 不正入力に対する test を書く → make them pass)
実装の進め方:
- task-driven: 引数のタスクを 5–15 個の小さな Edit に分けて実装
- plan-driven: plan の phase ごとに実装し、各 phase 後に Step 2 を回す
- 「前置き 1 文 + 実装 + 軽い確認」のリズムを保つ
Step 2: GATE — 機能ゲート + 品質ゲート
ゲートは 2 段階。両方 pass しなければ Step 3 (REVIEW) に進まない。Codex を呼ぶのは GATE green が前提。
2a. 機能ゲート
Step 1a で立てた受け入れ基準を満たしているか:
- 新規 test を実行し pass を確認
- 受け入れシナリオを手動 / 自動でなぞる
- fail → Step 1b に戻って実装を直す (Karpathy "Surgical Changes" 厳守)
2b. 品質ゲート
リポジトリ標準のチェックを順に試行:
pixi run check が定義されていれば最優先- なければ
pixi run lint + pixi run typecheck + pixi run test-unit を順に
- pixi 不在なら
make test / npm test / pytest をフォールバック
- プロジェクトのチェックコマンドが特定できなければ、ユーザーに 1 度確認
fail → 修正してから再実行。
Step 3: REVIEW — Codex によるレビュー
1 ラウンド目: mcp__codex__codex 直叩き (新規 thread)
mcp__codex__codex:
prompt: |
以下のコード変更をレビューしてください。
## プロジェクト概要
[1-2 文でプロジェクトの目的を説明]
## 変更の意図
[Step 1a の受け入れ基準の要約]
## Diff
```diff
[git diff の出力]
```
## レビュー観点
1. バグ・ロジックエラー (境界条件、off-by-one、null/undefined)
2. エッジケースの見落とし
3. セキュリティ上の問題 (入力検証、インジェクション、認証)
4. パフォーマンス上の懸念
5. エラーハンドリングの不足
6. API 設計・インターフェースの問題
各指摘に 重要度 (CRITICAL / HIGH / MEDIUM / LOW)・該当箇所 (ファイル名:行)・
問題の説明・修正案 (コード付き) を付けてください。
問題がない場合は「LGTM」と明記してください。
応答に含まれる threadId をローカル変数に保持 し、2 ラウンド目以降の mcp__codex__codex-reply で再利用する。
2 ラウンド目以降: mcp__codex__codex-reply で継続レビュー
mcp__codex__codex-reply:
threadId: <Step 3 ラウンド 1 で得た threadId>
prompt: |
前ラウンドの指摘について以下のとおり修正しました。
## 修正サマリ
- [HIGH N]: <対応内容>
- [MEDIUM M]: <対応内容>
...
## 最新 diff
```diff
<git diff の出力>
```
変更全体を再レビューし、残存する問題があれば指摘してください。
すべて解消されていれば「LGTM」と明記してください。
plan-driven モードのときは prompt に 1 行追加: 「plans/foo.md からの逸脱があれば併せて指摘してください」。
Step 4: FIX — 指摘の整理と修正
- Codex 応答から
CRITICAL / HIGH / MEDIUM / LOW を抽出し、TaskCreate で 1 件 1 タスクに分解
- CRITICAL がある場合は自動修正前にユーザーに確認 (重大変更は人間が判断)
- HIGH / MEDIUM / LOW は AUTO で順次修正 (ただし Karpathy "Surgical Changes" 厳守、無関係な refactor 禁止)
- Edit / Write で修正を適用
- 修正後は必ず Step 2 (GATE) に戻って機能ゲート + 品質ゲートを再実行
Step 5: ループ判定
成功終了条件は AND (3 点すべて満たす):
- 機能ゲート (Step 2a) pass — 受け入れ基準を満たしている
- 品質ゲート (Step 2b) pass — リポジトリ標準チェックが green
- Codex 応答に "LGTM" を含む — コード品質に重大な指摘なし
どれか 1 つでも未達なら Step 2 → 3 → 4 をもう 1 周。
反復回数 >= MAX_ITERATIONS (=10) に達したら現状を整理してユーザーに判断委ね。
注意:
- Codex が LGTM を返しても機能ゲート fail なら未完了 (機能未実装の可能性)。実装に戻る。
- 機能が動いていても Codex の CRITICAL/HIGH が残っていれば未完了。修正に戻る。
ルール
- Codex の指摘を勝手に却下しない (反論はしてよいが threadId 経由で再議論する)
- Claude のレビューと Codex のレビューは混ぜない — Codex の指摘をそのまま提示し対応する
- threadId は session 内で保持。別セッションへ持ち越さない
- diff が 500 行を超える場合はファイル単位で分割レビュー
- 各 FIX 後は GATE 通過を確認してから Codex を再度呼ぶ (失敗ゲートのまま re-review しない)
- IMPLEMENT 中は Karpathy 4 原則を最優先。speculative な機能追加・無関係 refactor は禁止
- Codex の提案でも Karpathy 原則違反 (新機能追加・余計な抽象化等) なら却下を検討し、ユーザーに判断仰ぐ
終了時の出力
成功時:
## LGTM Loop 完了
- 反復回数: N ラウンド
- 機能ゲート: pass (受け入れ基準すべて満たす)
- 品質ゲート: pass (lint + typecheck + test green)
- Codex: LGTM
- 総修正件数: M 件 (CRITICAL 0 / HIGH a / MEDIUM b / LOW c)
中断時 (MAX_ITERATIONS 到達 or ユーザー判断要):
## LGTM Loop 中断
- 反復回数: N ラウンド (上限 10)
- 機能ゲート: pass / fail
- 品質ゲート: pass / fail
- Codex: 残存指摘 K 件 (CRITICAL a / HIGH b / ...)
- 最終 Codex 応答: <要約>
ユーザーの判断を仰ぎます。
使い方の例
/lgtm-loop # 既存 diff をループ (review-only)
/lgtm-loop add JWT auth to /login # タスク説明から (task-driven)
/lgtm-loop refactor parse_url to use urllib # task-driven
/lgtm-loop plans/auth-jwt.md # plan ファイル駆動 (plan-driven)
関連 skill
karpathy-guidelines : IMPLEMENT 中の行動規範 (4 原則)/codex:review (公式プラグイン) : 1 ショットレビュー (loop 不要時)。--background でターンを塞がないcodex-discuss : 実装前の設計議論git-commits : LGTM 後のコミット粒度整理
補足: レビュー経路の使い分け
レビュー観点プロンプトは本 skill の Step 3 に内蔵している (旧 codex-review skill から移設)。
公式プラグイン /codex:review は threadId を返さず継続レビューができないため、本ループでは MCP 経路を維持する。
プラグイン側に thread 継続 API が入ったら、REVIEW ステップの背景実行化を再検討する
(論点整理: <nanokit>/docs/2026-07-13_codex-plugin-integration.html 論点 3)。
