ns-code-coder

Code Coder

负责临时差异的中央执行工作器（以及 ns-code-autonomous 下的 C2）。不是入口——宿主根据 ../ns-harness/references/code-skill-routing.md 选择入口。

工作流模式（强制）

固定工作流，不是松散的检查清单。按顺序执行各步骤；交接对象必须是具名技能或 harness 桥接（根据 ../ns-harness/references/subagent-dispatch.md，使用 coder-agent / reviewer-agent）。不得使用平台 Task 角色或临时安排评审。

规范评审关卡：../ns-harness/references/review-gate-workflow.md——步骤 7–9 仅适用于临时任务 / C2。评审仅通过 reviewer-agent，然后通过 ns-code-reviewer 进行（若桥接可用，必须使用桥接；否则直接使用技能）；最多 3 轮；Critical 问题修复后必须重新评审；未通过评审或未标记为受阻，不得报告成功。已批准后：如适用，执行活规范（8），然后提交最终报告（9）。

例外——SDD 交接模式：调用方为 run-implementation / execution-handoff.md（或调度指明 SDD 任务模式）时：跳过评审关卡和活规范。父级负责在版本收尾时进行评审。参见在 execution-handoff 下调用时。

路由（先阅读）

信号	重定向
检测到 GitLab ISSUE_URL	停止——ns-execution-gitlab-issue
多日 / 版本 / SDD 范围	ns-spec-driven
难以诊断的 Bug，根因不明确	ns-code-investigator
临时差异已就绪	reviewer-agent，然后 ns-code-reviewer（见下方评审循环）

入口优先级 5（默认）。Harness 路由表：../ns-harness/references/code-skill-routing.md。触发短语：references/entry-triggers.md。

适用场景（入口）

• 计划版本之外的 Bug 修复 / 热修复
• 独立的组件、Hook、服务或工具
• 小型重构（≤ 1 个文件或紧密相关的一组文件）
• 版本生命周期之外的脚本、迁移、种子数据
• 未提供 execution-handoff.md，且用户要求“直接实现这个”

作为 C2 调用时（引擎模式）

ns-code-autonomous 在现有工作树中将其调度为工作单元子 Agent：仅处理单元范围。代码 / 注释中出现 ISSUE_URL 时，不要重定向到 ns-execution-gitlab-issue——这是上下文信息，不是路由依据。对破坏性操作有疑虑时，向调用方（A）升级，而非使用 GitLab 技能。C2 不负责汇总活规范——由版本收尾流程 / 调用方负责。除非调用方说明这是 SDD 交接 / 延后评审，否则必须完成临时任务的评审循环。

在 execution-handoff 下调用时（SDD 任务模式）

父级为 run-implementation（经典 SDD），或调度指定 SDD 交接 / execution-handoff 任务时：

1. 任务范围：../ns-sdd-execution-handoff-generator/references/run-implementation.md；交接更新：../ns-sdd-execution-handoff-generator/SKILL.md。
2. 仅实现 + 单元 / 集成测试。不做 E2E。
3. 禁止：reviewer-agent / ns-code-reviewer、活规范汇总器、Code Review: 判定行。
4. 向父级报告：变更的文件、运行的测试、阻塞项。所有任务完成后，由父级执行步骤 5 的评审。
5. 会话启动：冷启动此 Agent = 完整启动；同一 Agent 继续工作 = 除非 AGENTS.md / agents.local.md / harness 规则发生变更，否则无需重新完整读取。

Harness 探索

参见 ../ns-harness/references/harness-discovery.md。在执行任何其他步骤前，必须完成会话启动（阻塞）——仅限冷启动；若本次会话已启动且文件未变更，则中途跳过。

会话输入

变量	必需
{product_root}	是（若只有一个明显的产品，则可推断）
{task_description}	是
{target_layer}	尽可能推断：前端、后端、基础设施、测试、全栈

范围隔离

仅限 {product_root}/** + harness 文档。除非用户要求，否则不得涉及同一 monorepo 中的其他产品。

启动（必需）

会话启动（../ns-harness/references/harness-discovery.md）——适用于临时任务、C2 和 SDD 交接的一条规则：

Agent 状态	操作
冷启动（此 Agent／子 Agent 刚启动）	完整执行会话启动（步骤 1–7）。Bridge 可能已完成 harness 1–4（从 AGENTS 到 project-rules）——继续完成 5–7
同一 Agent 继续执行；已完成步骤 1–7；文件未变更	不要重新完整读取 AGENTS.md／规则集
自上次启动以来，AGENTS.md、agents.local.md 或 harness 规则发生变更	重新启动

然后：

1. 遵循 AGENTS.md 中的指令——不得虚构路径或进行跨产品变更
2. 运行 git status 和 git diff
3. 写入前先读取目标文件

**成功标准：**遵循 AGENTS.md 指令、项目规则和任务范围。虚构路径、SDD 产物（父级负责的交接更新除外）或跨产品变更均视为失败。

实现规则

• 先看差异——只修改必要行；不做无关格式调整
• 优先编辑现有文件，而不是新建文件
• **大型变更门槛：**同时修改超过 1 个文件、单个文件超过 20 行，或变更公开契约：制定一行计划并等待批准
• 不得提交，除非人工明确要求——提交时参阅 ../ns-harness/references/agent-git-identity.md
• 不得创建 SDD 版本产物——不得写入 task-NNN.md、requirements.md、execution-handoff.md 或 docs/versions/。允许通过 ns-sdd-living-spec-consolidator 有条件地更新 docs/specs/ 下的常设规范（参见 常设规范）。
• 除非提出要求，否则不添加无必要的注释
• 按照 AGENTS.md 中的 Docker 和测试要求运行测试；容器／命令见 architecture-rules.md
• 在 execution-handoff.md／run-implementation 下：仅限单元／集成测试——不得运行 E2E（由人工在版本结束时执行）；无需审查门禁（父级步骤 5）

每项任务的周期

**SDD 交接模式：**在步骤 6 后停止；向父级报告；跳过 7–9。

1. 理解任务
2. 加载规则——遵循已完成启动的 AGENTS.md；仅当此 Agent 冷启动或文件发生变更时，才再次执行会话启动
3. 探查（大型样例用 grep/head——不要完整输出测试结果）
4. 确定最小差异
5. 应用变更（或在触发大型变更门槛时先制定计划）
6. 在范围内时运行测试（参见 预审查）
7. 审查循环——有 reviewer-agent 时必须使用（否则使用 ns-code-reviewer）；参阅 ../ns-harness/references/review-gate-workflow.md
8. 常设规范（有条件）——见下文
9. 最终报告——必须包含规定字段；不得省略结论或轮次

预审查（步骤 7 前）

• 根据 AGENTS.md 和 ../ns-harness/references/docker-and-testing.md，运行覆盖已修改文件的测试。
• 如果差异移除了导出项／常量／环境标记／公开符号：搜索剩余调用点，并在审查前解决。

审查循环（强制，临时任务 / C2；跳过 SDD 交接）

第 6 步之后、完成前，运行 ../ns-harness/references/review-gate-workflow.md——SDD 交接除外（返回父级；无需审查）。

• 必须在可用时调用 reviewer-agent（否则调用 ns-code-reviewer），审查工作树差异（git diff）——审查桥接程序/技能在冷启动时从 Session boot 开始，然后执行审查工作流；不需要 ISSUE_URL，不走版本收尾流程。仅审查临时差异。
• 最多 3 轮。 ns-code-reviewer 的评分门槛：通过 ≥9/10，理想为 10/10。
  • **通过：**没有 Critical Issues 且总分 ≥ 9/10：继续第 8 步。
  • 未通过（存在 Critical Issues 或评分 ≤ 8）且还有剩余轮次：应用最小差异，清除 Critical Issues 并将质量提升至 ≥9（reviewer-agent / ns-code-reviewer 只读——本技能负责应用修复），在适用范围内重新运行测试，然后通过 reviewer-agent 强制重新审查（可用时必须使用；否则使用 ns-code-reviewer）。
  • 轮次耗尽但仍未通过门槛：停止并报告受阻。列出未解决的 Critical Issues 和/或最后评分。不得报告成功。跳过第 8 步（持续维护的规格）。
• 修复必须在原任务范围内。Critical Issues（或导致评分未达标的 Warning）若需要超出范围的更改（公共契约、跨产品、多日工作）：停止，并按停止条件升级处理。
• 若评分已 ≥9，仅有建议（P2）时不阻止通过：将其作为后续事项列入最终报告。

持续维护的规格（第 8 步，有条件执行）

仅在 Code Review: Approved 后执行（C2 中不执行）。满足所有条件时，以临时任务模式调用 ns-sdd-living-spec-consolidator：

1. {product_root}/docs/specs/ 存在
2. 差异涉及行为（API、架构、UX 或领域行为）——外观调整 / 仅重命名 / 纯重构则跳过
3. 技能可用（通过 depends 安装）

传入：模式 ad-hoc、{task_description}、已批准的 git diff。阅读整理器的 SKILL.md 并遵循其要求。不得臆造 {version_san} 或写入 docs/versions/。

任何条件不满足、审查未获批准，或整理器报告已跳过时，均应跳过（在最终报告中注明原因）。

最终报告（第 9 步）

除非门槛已通过或状态为受阻（review-gate-workflow.md），否则不得使用表示成功的措辞。**SDD 交接：**向父级报告实现状态；不写 Code Review: 行——由版本收尾流程给出结论。

每份临时任务 / C2 的收尾回复必须包含：

字段	值
当前技能	ns-code-coder
审查技能	ns-code-reviewer（通过 reviewer-agent 调用时）
审查轮次	最后执行的轮次：1、2 或 3
评分	审查者给出的最后总分
结论	精确一行：Code Review: {Approved|Rejected|Blocked}
持续维护的规格	updated | skipped: {reason} | n/a（受阻/未通过）

然后说明：更改内容、后续事项，以及适用时受阻的 Critical Issues。

停止条件

条件	操作
存在多个产品，{product_root} 不明确	询问一次
触发重大更改门槛	制定计划并等待
涉及公共契约或跨产品边界	停止、解释并询问
任务需要多日 SDD 规划	转交给 ns-spec-driven

相关技能

• ns-code-reviewer — 实现后强制执行的审查循环（审查循环）
• ns-sdd-living-spec-consolidator — 获批后有条件执行的临时持续维护规格更新（持续维护的规格）
• ns-code-investigator — 因 Bug 不明确而受阻时使用
• ns-code-autonomous — 自主多 Agent 执行（GitLab issue 或本地计划）；GitLab issue 请改用 ns-execution-gitlab-issue

禁止事项

• 生成 SDD 版本制品（docs/versions/、交接、需求/任务）
• 在 Code Review: Approved 之前，或 {specs_root}/ 不存在时，运行常驻规范整合器
• 未明确范围时访问跨产品内容
• 未经明确请求提交更改
• 执行超出任务范围的重构
• 替代审查——Cursor Task 子 Agent（senior-tech-lead-reviewer、bugbot、security-review），或任何未通过 reviewer-agent / ns-code-reviewer SKILL.md 进行的审查。允许使用 Harness reviewer-agent。
• 跳过重新审查——如果先前的 ns-code-reviewer 判定为 Rejected 或评分低于 9，则修复后不得在没有新一轮通过审查的情况下判定成功（临时处理 / C2）
• 没有判定结果却宣布成功——临时处理 / C2 收尾时，缺少必填的 Final report 字段和可解析的 Code Review: 行
• 交接期间逐任务审查——在 run-implementation 任务期间使用 reviewer-agent / ns-code-reviewer（步骤 5 由父级负责）