gitnexus-lfg 是 GitNexus 工程流水线的编排技能，定位为“plan → gate → work → review”的轻量编排器。它建立在三个已有技能之上：gitnexus-plan、gitnexus-work 和 gitnexus-review。它自身不包含任何工程逻辑，只负责按顺序调用这些技能，并在计划闸口把决定权交给用户。使用时要求真正调用被点名的技能（读取其 SKILL.md 并遵循），不得用摘要代替实际执行。
用途与调用方式
该技能用于让 GitNexus 工程流水线端到端地跑完一个任务。调用形式有两种：
- /gitnexus-lfg <任务描述>
- /gitnexus-lfg docs/plans/<已有计划>.md（跳过第一段，直接从闸口开始）
流水线分为四段。
第一段：规划（Plan）
先做边界判断。如果任务明显低于规划边界——即琐碎或小范围、代理可在远低于约 35 轮内完成的工作（该阈值是在 GitNexus 仓库的 eval/workflow_bench/ 中测得的、规划成本高于收益的区间）——技能会说明这一点，并在消耗规划段之前提供 gitnexus-work 直接模式作为完整流水线的替代方案，并尊重用户的选择。该阈值是离线测得的、被提升为基准的策略，不是永恒不变的启发式规则，不得在实时任务中自行修改；其重新评估的治理方式记录在该技能的 README 中。
否则，用任务调用 gitnexus-plan（旋钮覆盖参数原样透传；规划深度的前置问题由 gitnexus-plan 负责，此处不再重复询问）。如果输入本身已是计划文件路径，则跳到第二段。计划落在 docs/plans/ 目录，需记录其路径，后续每一段都消费它。
第二段：计划闸口（用户选择，阻塞式）
展示计划的聊天摘要（目标、拟议变更、顺序、主要风险、待决问题、计划路径），然后以阻塞式问题询问用户（在 Claude Code 中使用 AskUserQuestion；在没有阻塞工具的 CLI 上使用聊天中的编号列表）：
- 继续执行——进入第三段。
- 就此停止——计划文件即交付物，结束流水线。
深度是用户在规划阶段的前置选择，因此默认不提供加深选项；但若用户在闸口明确要求，则对计划文件运行 gitnexus-plan 的 Deepen 模式，带着强化后的计划回到此处，用户要求多少次就执行多少次。没有明确选择就不得越过闸口——闸口是流水线唯一的检查点，其存在正是因为执行一旦展开就代价高昂、难以回退。
无头/非交互运行：无人能回答闸口，因此在第一段之后结束流水线——计划文件即交付物（闸口选项 2）——并在最终报告中说明这一点。绝不自动进入执行。
第三段：执行（Work）
用计划路径调用 gitnexus-work。它会在 HEAD 处重新锚定计划，把实现序列执行为经过验证的原子提交，完成后刷新知识图谱（其 Phase 4），并报告偏差。如果它因结构性漂移而路由回重新规划，则运行 Deepen 流程并回到第二段闸口，而不是硬推下去。
第四段：评审（Review）
对已完成的工作调用 gitnexus-review。存在打开的 PR URL/编号时传入；否则传入当前分支。目标解析、精确 SHA 检出/索引对齐以及合并基选择由评审技能负责，此处不重复该逻辑。如果工作留下了本地变更，则把 local 作为第二个、单独标注的评审面传入。
把评审结论与发现项呈现给用户。用户希望修复的发现项：若在 gitnexus-work 直接模式的范围内（1–2 个文件、无架构决策），交给 gitnexus-work 直接模式；更大的则改为提供计划闸口（用发现项加深计划，或停止）。然后重新运行本段评审一次。在该次重跑中，即使仍有发现项，也不要再启动另一轮修复循环——报告它们并指引用户使用 /gitnexus-work（或计划闸口）来有意识地继续。
最终报告
用一条消息给出：计划路径、运行的加深循环次数、产生的提交、验证状态、评审结论及未解决的发现项，以及（如有）明确未完成的事项。流水线不会自行推送或创建 PR——把这两项作为后续步骤提供。
适用场景与限制
适用于希望按 GitNexus 既定流程完成一个工程任务的场景，尤其是需要先规划、再人工确认、然后执行与评审的工作。限制包括：不添加自身工程逻辑；闸口为阻塞式，无交互环境不会自动执行；不自行推送或创建 PR；规划深度阈值不可在实时任务中自行修改；评审重跑后不再自动开启新的修复循环。