gitnexus-lfg について
gitnexus-lfgは、gitnexus-plan、gitnexus-work、gitnexus-reviewのスキルを順に実行します。計画と実装の間にユーザー承認のゲートを設け、独自のエンジニアリングロジックは追加しません。
主な機能
- 01計画・作業・レビューの順次実行
- 02実装前のユーザー承認ゲート
- 03小規模タスクの直接処理
- 04構造的なずれを再計画へ誘導
- 05完了した作業のレビュー
活用シーン
- 01計画からレビューまで工程を通して実行
- 02実装の承認がない場合に計画で停止
- 03レビュー指摘を修正または再計画へ回す
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/gitnexus-lfgを入力して読み込まれたか確認します。
同梱ファイルREADME.md
詳細
gitnexus-lfg — 計画 → ゲート → 作業 → レビュー
既存の 3 つのスキルを束ねる薄いオーケストレーターです。独自のエンジニアリングロジックは一切追加しません。gitnexus-plan、gitnexus-work、gitnexus-review を順に実行し、計画ゲートではユーザーが判断します。各レーンは、必ず名前を挙げたスキルを実際に呼び出して実行してください（その SKILL.md を読み、それに従ってください）。そのスキルが実行したであろう内容の要約をインラインで書いてはいけません。
/gitnexus-lfg <task description>
/gitnexus-lfg docs/plans/<existing-plan>.md # skip lane 1, start at the gate
レーン 1 — 計画
まず境界トリアージを行います。 タスクが明らかに計画の境界を下回る場合 — つまり、エージェントがおよそ 35 ターンをはるかに下回って完了できる些細な、または範囲の小さい作業（計画パスにかかるコストがその見返りを上回る、計測済みの領域。GitNexus リポジトリの eval/workflow_bench/ で計測） — は、その旨を伝え、計画レーンを消費する前に、完全なパイプラインの代替として gitnexus-work の直接モードを提案してください。ユーザーの選択を尊重してください。
このしきい値は、オフラインで計測された昇格済みのベンチマークポリシーであり、永遠に通用するヒューリスティックではありません — 実行中のタスクから自己編集してはいけません。その再評価のガバナンスは、このスキルの README にあります。
それ以外の場合は、タスクを指定して gitnexus-plan を呼び出してください（ノブのオーバーライドはそのまま渡されます。事前の深さに関する問い合わせは gitnexus-plan が担います — ここで再度尋ねてはいけません）。入力がすでに計画ファイルのパスである場合は、レーン 2 に進んでください。計画は docs/plans/ に配置されます — そのパスを記録してください。以降のすべてのレーンがそれを消費します。
レーン 2 — 計画ゲート（ユーザーの選択、ブロッキング）
計画のチャット要約（目的、提案する変更、順序、主なリスク、未解決の質問、計画パス）を提示し、その後ユーザーに尋ねてください — ブロッキングな質問として（Claude Code では AskUserQuestion、ブロッキングツールのない CLI ではチャット内の番号付きリスト）:
- 作業に進む — レーン 3 に進みます。
- ここで停止する — 計画ファイルが成果物です。パイプラインを終了します。
深さはレーン 1 でユーザーが事前に選択したものであるため、深掘りはデフォルトでは提供されません — ただし、ゲートでの明示的なリクエストは尊重してください。計画ファイルに対して gitnexus-plan の深掘りモードを実行し、強化された計画を持ってここに戻ります。ユーザーが求める回数だけ繰り返してください。明示的な選択なしにゲートを通過して進んではいけません — ゲートはパイプライン唯一のチェックポイントであり、実行の巻き戻しにはコストがかかるからこそ存在します。
ヘッドレス / 非対話実行: ゲートに回答できる人がいないため、レーン 1 の後にパイプラインを終了してください — 計画ファイルが成果物です（ゲートの選択肢 2） — そして最終レポートでその旨を伝えてください。実行に自動で進んではいけません。
レーン 3 — 作業
計画パスを指定して gitnexus-work を呼び出します。これは HEAD で計画を再アンカーし、実装順序を検証済みのアトミックコミットとして実行し、完了時にナレッジグラフを更新し（そのフェーズ 4）、逸脱を報告します。再計画のために差し戻された場合（構造的ドリフト）、押し通すのではなく、深掘りパスを実行してレーン 2 のゲートに戻ってください。
レーン 4 — レビュー
完了した作業に対して gitnexus-review を呼び出します。オープンな PR の URL / 番号がある場合はそれを渡し、なければ現在のブランチを渡します。対象の解決、正確な SHA のチェックアウト / インデックスの整合、マージベースの選択はレビュースキルが担います。そのロジックをここで重複させてはいけません。作業がローカルの変更を残した場合は、local を 2 つ目の、別途ラベル付けされたレビュー対象として渡してください。
レビューの判定と指摘をユーザーに提示してください。ユーザーが修正を望む指摘: gitnexus-work の直接モードの範囲内（1〜2 ファイル、アーキテクチャ上の判断なし）のもの → gitnexus-work の直接モードに渡します。それより大きいもの → 代わりに計画ゲートを提案します（指摘を踏まえて計画を深掘りする、または停止する）。その後、このレーンのレビューを 1 回再実行してください。その再実行では、指摘が残っていても別の修正サイクルを開始しないでください — それらを報告し、意図的に続行するようユーザーに /gitnexus-work（または計画ゲート）を指し示してください。
最終レポート
1 つのメッセージ: 計画パス、実行した深掘りサイクル、生成したコミット、検証ステータス、未解決の指摘を含むレビュー判定、および明示的に未完了のまま残したもの（ある場合）。パイプラインは自らプッシュしたり PR を開いたりしません — その両方を次のステップとして提案してください。