gitnexus-lfg

gitnexus-lfg — 计划 → 门禁 → 执行 → 审查

对三个既有 skill 的轻量编排器。它本身不添加任何工程逻辑——它负责串联 gitnexus-plan、gitnexus-work 和 gitnexus-review，由用户在计划门禁处做决定。每一条通道都要通过实际调用所指定的 skill 来运行（阅读其 SKILL.md 并遵循它）；绝不要内联该 skill 本应完成之事的摘要。

/gitnexus-lfg <task description>
/gitnexus-lfg docs/plans/<existing-plan>.md    # skip lane 1, start at the gate

通道 1 —— 计划

先做边界分诊。 如果任务明显低于规划边界——即 Agent 能在远低于约 35 轮内完成的琐碎或小范围工作（这是实测得出的区间，在此区间内，一次规划所付出的成本超过其回报；测量于 GitNexus 仓库的 eval/workflow_bench/）——那就说明这一点，并在耗费计划通道之前，提供 gitnexus-work 直接模式作为完整流水线的替代方案。尊重用户的选择。

该阈值是一项经离线测量并晋升为基准的策略，而非永恒的启发式规则——绝不要根据实时任务自行修改它。其重新评估的治理机制位于本 skill 的 README 中。

否则，用该任务调用 gitnexus-plan（knob 覆盖参数原样透传；gitnexus-plan 负责前置的深度问题——绝不要在此处再次询问）。如果输入本身已经是计划文件路径，则跳到通道 2。计划会落在 docs/plans/ ——记录其路径；之后的每一条通道都会消费它。

通道 2 —— 计划门禁（用户选择，阻塞式）

展示计划的聊天摘要（目标、拟议变更、顺序、首要风险、待决问题、计划路径），然后向用户提问——作为阻塞式问题（在 Claude Code 中用 AskUserQuestion；在不具备阻塞式工具的 CLI 上，用聊天中的编号列表）：

1. 继续执行 —— 进入通道 3。
2. 就此停止 —— 计划文件即为交付物；结束流水线。

深度是用户在通道 1 中前置做出的选择，因此默认不提供加深——但在门禁处应尊重用户明确的加深请求：对计划文件运行 gitnexus-plan 的 Deepen 模式，然后带着强化后的计划返回此处，用户要求多少次就做多少次。没有明确选择就不要越过门禁——门禁是流水线唯一的检查点，其存在正是因为执行一旦展开就代价高昂、难以回退。

无头 / 非交互式运行： 没有人能回答门禁，因此在通道 1 之后结束流水线——计划文件即为交付物（门禁选项 2）——并在最终报告中说明这一点。绝不要自动进入执行。

通道 3 —— 执行

用计划路径调用 gitnexus-work。它会在 HEAD 处重新锚定计划，将 Implementation Sequence 作为经过验证的原子提交来执行，完成后刷新知识图谱（其 Phase 4），并报告偏差。如果它因结构性漂移而回退以重新规划，请运行 Deepen 流程并返回到通道 2 的门禁，而不是强行推进。

通道 4 —— 审查

对已完成的工作调用 gitnexus-review。存在打开的 PR URL/编号时传入它；否则传入当前分支。审查 skill 负责目标解析、精确 SHA 的检出/索引对齐以及 merge-base 的选择。不要在此处重复该逻辑。如果工作留下了本地更改，将 local 作为第二个、单独标注的审查面传入。

向用户呈现审查结论与发现项。用户希望修复的发现项：属于 gitnexus-work 直接模式范围之内的（1–2 个文件，无架构决策）→ 交给 gitnexus-work 直接模式；更大的 → 改为提供计划门禁（根据发现项 Deepen 计划，或停止）。然后重新运行本通道的审查一次。在该次重新运行中，即使仍有发现项，也不要再启动另一轮修复循环——报告它们，并指引用户使用 /gitnexus-work（或计划门禁）来有意识地继续。

最终报告

一条消息：计划路径、运行的 deepen 循环次数、产生的提交、验证状态、带未解决发现项的审查结论，以及（如有）被明确搁置未做的事项。流水线不会自行推送或打开 PR——将二者作为后续步骤提供给用户。