用途
gitnexus-work 用于执行由 gitnexus-plan 生成的工程实施计划，将其作为一系列经过验证、彼此独立的原子提交交付。计划第 11 节（implementation_context pack）是主要的机器可读输入，散文部分是其理由。该技能会实际编辑代码，是仅做规划的 gitnexus-plan 的执行对应方。
主要能力
- 输入分诊：支持计划路径模式（或留空以使用当前仓库根目录下最新的 docs/plans/gitnexus-plan.md）、直接模式（简单且有界、1–2 个文件、无架构决策的任务文本）。Schema-2 计划具有规范化的仓库相对路径 docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md 的 generated_plan_path。
- 计划加载与重锚定：通过脚本 scripts/evidence-provenance.mjs 的 read-plan 命令读取计划，拒绝外部、逃逸、符号链接或作用域不同的路径；从不直接读取或重新打开词法路径。解析第 11 节的 implementation_context pack，包括 acceptance_criteria、evidence_provenance、primary_symbols、related_symbols、files_to_modify、execution_path、pdg_constraints、architectural_patterns、tests、verification_commands、risks、assumptions、open_questions、avoid 等字段。执行双层漂移检查，重新计算全局脏摘要与被引用路径清单。
- 环境准备：在默认分支上创建以计划 slug 命名的功能分支；如计划文档尚未提交则先提交（docs(plans): add <slug> plan）；在开始前确认 verification_commands 可实际运行。
- Build-current/index-current 过程：这是 gitnexus-work 拥有的唯一图新鲜度过程，在计划模式与直接模式均适用；在每个依赖图的影响查询之前、以及最终图验证之前都要运行。读取 gitnexus://repo/<name>/context，比较 index.commit 与当前 HEAD，要求 schemaVersion: 4 及各项 receipt 字段完整，并要求 MCP index.incomplete_reasons: [] 等。
- 执行实施序列：按计划第 7 节逐步进行，每步包括：编辑前的新鲜影响检查、遵守约束、最小实现、按计划场景编写测试、验证、原子提交（提交前运行 detect_changes {scope: "staged"}）。
- 收尾：运行完整 verification_commands 套件，逐项核对计划第 13 节（Definition of Done）与 acceptance_criteria，执行最终知识图谱验证，并报告完成的步骤、提交、偏差、失败的假设、DoD 状态、最终索引提交与 runner 身份以及被推迟的事项。
使用方式
/gitnexus-work <plan path> # execute this plan
/gitnexus-work # newest docs/plans/*gitnexus-plan*.md here
/gitnexus-work <small task text> # direct mode, see Input triage
适用场景
- 执行 gitnexus-plan 生成的工程实施计划。
- 直接执行简单且有界的小任务（1–2 个文件、无架构决策），并保持同等纪律。
- 需要逐个原子提交交付、并在每步进行影响检查与验证的开发工作流。
限制
- 不得跳过第 3 阶段门禁：无影响检查不得编辑符号，无 detect_changes 不得提交。
- 不得将范围扩大到计划之外；第 12 节的推迟跟进事项保持推迟。
- 不得修改计划正文（在第 2 阶段原样提交文件不算修改）、削弱失败的测试，或把未经验证的工作呈现为已验证。
- 任何构建、刷新、元数据读取或身份验证失败都会阻止依赖图的影响工作与最终完成。
- 若第 1 阶段发现最新计划的所有第 7 节步骤均已完成，则停止并询问，而不是重新执行。
- 技能反馈仅限 GitNexus 仓库：可向 eval/workflow_bench/learnings.jsonl 追加一行 JSON，但不得从实时任务中编辑技能文件本身。
（以上内容均依据所提供资料整理，未提供的收费、价格、平台或效果信息暂未提供。）