ns-code-autonomous

Code Autonomous

具备 Harness 感知能力的执行引擎：决定规划深度、消除疑问、分派多 Agent 工作，并通过审核关卡完成闭环——既可作为独立流水线运行，也可作为其他技能的执行引擎。

工作流模式（强制）

固定工作流——命名技能交接或 Harness 项目桥接（../ns-harness/references/subagent-dispatch.md）。审核关卡：../ns-harness/references/review-gate-workflow.md。有 reviewer-agent 时必须使用（否则使用 ns-code-reviewer）；不得用任何平台 Task 人设替代。C2（有 coder-agent 时必须使用 → ns-code-coder）必须完成其完整的逐任务周期，包括相同的审核关卡，之后才能认为一个单元已完成。

隔离不变量（不可妥协）

除非用户明确指示本次运行“不要创建新分支／在当前分支上原地工作”，否则此技能绝不会在主产品检出目录中编写应用代码，也绝不会提交到 main／master（或任何基准分支／SOURCE_BRANCH）。

• 独立模式和引擎模式都要求在进行任何实现编辑前，先准备好隔离的 WORK_BRANCH 和 WORKTREE_ROOT。
• 如果创建工作树失败，或 CWD／分支仍处于主检出目录／基准分支 → 停止。不要“为了继续计划而留在 main 上”。
• 沙箱限制（Operation not permitted、.cursor/ 下的 Cursor Agent 运行时路径）不代表可以违反此不变量。

Harness 发现

请参阅 ../ns-harness/references/harness-discovery.md。在执行此技能的任何其他步骤前，必须先完成其中的 Session 启动（阻塞性要求）。

Session 启动后——引擎模式和独立模式

**引擎模式：**调用方可能已在阶段 0 完成 Session 启动——仅在上下文缺失时重新读取 harness-discovery.md。 **独立模式：**你负责在独立流水线的步骤 1 前完成 Session 启动。

路由（先读）

入口优先级表：../ns-harness/references/code-skill-routing.md。独立模式触发条件：references/entry-triggers.md。

1. 来源是 GitLab issue（ISSUE_URL 或 issue 引用）→ 入口优先级 1——从头到尾遵循 ns-execution-gitlab-issue；此技能仅作为其阶段 2 引擎运行（下文的引擎模式）。不要运行独立流水线，不要触及 GitLab 状态，也不要创建工作树。
2. 独立自主执行（本地计划文件、粘贴的文本／计划，或不涉及 issue 的临时“自主实现此内容”请求）→ 入口优先级 3——运行独立流水线：管理自己的工作树、状态和审核循环。

有关引擎模式的输入／输出以及与 ns-execution-gitlab-issue 的防循环规则，请参阅 references/routing.md。

Engine 模式（由 ns-execution-gitlab-issue 调用）

输入（调用方已解析；此技能不会创建这些输入）：issue 负载、{product_root}、WORKTREE_ROOT、WORK_BRANCH、SOURCE_BRANCH。

1. 自行判断规划深度 — 评估 issue 负载，并决定采用单个工作单元，还是在 docs/versions/{version_san}/ 下轻量编写 requirements.md + tasks/task-NNN-*.md + execution-plan.md。参见 references/planning-decision.md。
2. 疑问处理流程 — 主动提出疑问，优先查阅文档，自行解答非破坏性疑问；对于破坏性疑问，将其作为结构化事件升级给调用方，而不是修改 GitLab 状态；暂停依赖该疑问的工作单元，直至恢复执行。参见 references/doubt-resolution.md。
3. 多 Agent 调度 — 解析工作单元（或单个工作单元），并且必须在可用时调度 coder-agent（否则调度 ns-code-coder）工作者；仅当工作单元之间没有 DAG 边且文件范围不重叠时才并行执行，否则按顺序执行。每个子 Agent 都在 WORKTREE_ROOT 中工作，绝不在主检出目录中工作。参见 references/multi-agent-dispatch.md 和 ../ns-harness/references/subagent-dispatch.md。
4. 检查点提交 — 每个已完成的顺序工作单元或每个已完成的并行批次，在工作树中创建一个提交；交付时由调用方压缩提交。
5. 修复循环入口 — 在收到 Rejected 结论后重新调用时，将审查发现视为新的工作单元（或多个工作单元），仅针对这些工作单元重复步骤 3。
6. 返回给调用方：工作单元状态、变更的文件、任何尚未解决的破坏性疑问，以及（仅首次调用时）基于计划的 estimate_seconds 参考值 — 仅当 issue 估算值为空且该值 ≥ 60 时，调用方才应用 set_issue_estimate（参见 ../ns-execution-gitlab-issue/references/time-tracking.md）。

独立流水线（非 GitLab 来源）

内部流程与 Engine 模式相同，但整个运行由此技能负责：

1. 解析任务描述 — 本地计划路径或粘贴的文本。不会调用 MCP。
2. 推断 change_kind（fix/feat），分配 {version_san}，创建 docs/versions/{version_san}/。
3. 创建自己的工作树：根据解析出的基准分支创建 {product_root}/.worktrees/{version_san}/，并创建分支 work/{version_san}，遵循 ../ns-harness/references/worktree-setup.md。路径位于产品根目录下，绝不放在 .cursor/ 下。失败时 → 中止（不要退回主检出目录）— 参见 references/standalone-pipeline.md。
4. 自行判断规划深度、疑问处理流程（破坏性疑问 → 仅限聊天的关卡，没有可用的 GitLab 操作）、多 Agent 调度 — 与 Engine 模式采用相同逻辑。
5. 内部审查循环 — 参见 ../ns-harness/references/review-gate-workflow.md：仅（版本闭环模式）在可用时必须调用 reviewer-agent（否则调用 ns-code-reviewer）；最多 3 轮；Approved 要求评分 ≥9/10（理想为 10）；对于 Rejected（存在 Critical 项或评分 ≤8），修复相应工作单元，然后必须重新审查；遇到 Blocked 或轮数耗尽时停止。
6. 根据 review-gate-workflow.md 中的最终报告字段进行报告，并补充 {version_san}、工作树路径、提交和后续事项。不创建 GitLab 看板，不创建 MR — 除非 docs/context/gitlab-sync-config.md 存在且人工明确提出要求（超出 v1 范围；否则独立运行始终仅在本地进行）。

完整流程参见 references/standalone-pipeline.md。

停止并询问人工

条件	操作
破坏性疑虑（引擎模式）	向调用方返回升级事件——此处不暂停聊天
破坏性疑虑（独立模式）	停止聊天并提问，收到答案后将其作为上下文继续
同一 {run_id} 存在工作树冲突（独立模式）	停止，除非明确要求恢复
git worktree add 失败（权限／沙箱／路径）	中止——报告尝试过的路径；绝不回退到主检出目录或 .cursor/
即将编辑代码时仍位于 main／master／基础分支	中止——缺少隔离；不要实施
人工明确表示“不要创建新分支／在原处工作”	只有在这种情况下才可以编辑当前分支；仍绝不臆造 .cursor/ 路径
独立工作树的基础分支未解决	停止——询问一次
审查结果为 Blocked 或已耗尽 3 轮	停止，报告为受阻——不要捏造成功
引擎模式在未提供工作树／分支的情况下使用 GitLab 源	停止——这是调用方违反约定，而非疑虑

相关技能

技能	作用
ns-execution-gitlab-issue	GitLab 流程负责人——在阶段 2 调用此技能
ns-code-coder	通过 coder-agent 执行子代理实施（可用时必须使用）
ns-code-reviewer	通过 reviewer-agent 进行审查门禁（可用时必须使用）
ns-harness	制品布局、工作树机制、发现

参考资料

文件	适用时机
references/routing.md	Issue 与独立任务；引擎模式的 I/O，以及与 ns-execution-gitlab-issue 的反循环机制
references/entry-triggers.md	优先级 3 的独立任务入口短语
references/planning-decision.md	自我评估启发式：单一单元 vs. 需求＋任务＋计划
references/doubt-resolution.md	自行提问、优先查阅文档、破坏性标准、升级格式
references/multi-agent-dispatch.md	DAG＋不重叠范围并行规则、子代理提示词、检查点提交
references/standalone-pipeline.md	完整的非 GitLab 流程：版本分配、自有工作树、审查循环

禁止事项

• 使用替代审查机制（senior-tech-lead-reviewer、bugbot、security-review 或任何非 ns-code-reviewer 的门禁）——允许使用 harness reviewer-agent；参见 ../ns-harness/references/review-gate-workflow.md
• 未获得通过的 ns-code-reviewer 结论或明确的受阻状态就报告成功
• 修复结果为 Rejected 后跳过重新审查便结束流程