ns-autonomous

代码自主执行

具备 Harness 感知能力的执行引擎：规划深度、疑问解决、多 Agent 调度、评审门禁——可作为独立流水线运行，也可作为调用方的 Phase 2 引擎。

工作流模式（强制）

固定工作流——命名技能交接或 Harness 桥接（../../ns-harness/references/subagent-dispatch.md 的生成门禁）。评审门禁：../ns-reviewer/references/review-gate-workflow.md。必须在 reviewer-agent 可用时使用它（否则使用 ns-reviewer）；然后仅当 Code Review: Approved 时，才在会话中调用 ns-judge。不得用 Task persona 替代。≥2 个单元 → 每个单元必须使用 coder-agent（ns-coder）；1 个单元 → 在 A（工作树）中遵循 ns-coder——不得额外生成 Agent。C2 / 单单元工作者仅负责实现；不得进行单元级评审——由父级在收尾时负责 REV。

隔离不变量（不可妥协）

技能绝不在主产品检出目录中编写应用代码；除非人工明确要求本次原地操作，否则绝不提交到 main/master/基础分支/SOURCE_BRANCH。

• 独立模式和引擎模式：在任何实现编辑之前，先创建隔离的 WORK_BRANCH 和 WORKTREE_ROOT。
• 工作树创建失败，或 CWD/分支仍指向主检出目录/基础分支 → 停止。不得以“继续在 main 上运行来解锁计划”为由继续。
• 沙箱限制（Operation not permitted、.cursor/ 路径）不代表可以违反此不变量。

会话启动

参见 ../../ns-harness/references/session-boot.md。执行此技能的任何其他步骤之前，必须先完成其中的 Session boot（阻塞）。

会话启动后——引擎模式和独立模式

**引擎模式：**调用方可能已在 Phase 0 完成 Session boot——只有在上下文缺失时才重新阅读 session-boot.md。 **独立模式：**你必须在独立流水线的第 1 步之前完成 Session boot。

路由（先阅读）

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

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

有关引擎模式的输入/输出，以及与 ns-execution-gitlab-issue 配合时避免循环的规则，请参见 references/routing.md。

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

输入（由调用方解析；此技能不会创建这些输入）：问题负载、WORKTREE_ROOT、WORK_BRANCH、SOURCE_BRANCH。

1. 自行判断规划深度 — 评估问题负载，并决定采用单个工作单元，还是在 docs/versions/{version_san}/sdd/ 下轻量创建 requirements.md、tasks/task-NNN-*.md 和 execution-plan.md。参见 references/planning-decision.md。
2. 疑问处理协议 — 自行提出问题，优先查阅文档，自行解答非破坏性疑问；将破坏性疑问作为结构化事件升级给调用方，而不是修改 GitLab 状态；依赖该疑问的工作单元暂停，直至恢复。参见 references/doubt-resolution.md。
3. 多 Agent 调度 — 解析工作单元。**1 个单元：在本会话中遵循 ns-coder，并在 WORKTREE_ROOT 内操作（将审查交由调用方／独立步骤 5 处理）。≥2 个单元：**在可用时，必须按单元调度 coder-agent（否则使用 ns-coder）；只有当单元之间没有 DAG 边且文件范围不重叠时，才可并行；否则按顺序执行。工作者仅负责实现——不要为每个单元单独调用 reviewer-agent。参见 references/multi-agent-dispatch.md 和 ../../ns-harness/references/subagent-dispatch.md。
4. 检查点提交 — 每个已完成的顺序单元或每个已完成的并行批次在工作树内提交一次；交付时由调用方压缩提交。
5. 修复循环入口 — 在 Rejected 后重新调用时，对整个映射原样调用一次 coder（不按单元数量拆分，不使用“或单元”的做法）。跳过已完成的单元。
6. 返回给调用方：单元状态、已更改的文件、任何未解决的破坏性疑问，以及（仅首次调用时）基于计划的 estimate_seconds 提示——调用方仅在问题的估算为空且数值 ≥ 60 时才应用 set_issue_estimate（参见 ../ns-execution-gitlab-issue/references/time-tracking.md）。

独立流水线（非 GitLab 来源）

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

1. 解析描述——本地计划路径或粘贴的文本。不调用 MCP。
2. 推断 change_kind（fix/feat），分配 {version_san}，在需要产物时创建 docs/versions/{version_san}/sdd/。
3. 创建自己的工作树：按照 ../../ns-harness/references/worktree-setup.md，从解析出的基分支创建 .worktrees/{version_san}/ 和分支 work/{version_san}。路径位于仓库根目录下，绝不能放在 .cursor/ 下。失败时 → 中止（不得退回主检出目录）——参见 references/standalone-pipeline.md。
4. 规划深度自行判断、疑问处理协议（破坏性疑问 → 仅通过聊天把关，不执行 GitLab 操作）和多 Agent 调度——逻辑与引擎模式相同。
5. 内部审查循环 — 按照 ../ns-reviewer/references/review-gate-workflow.md（详尽映射 → 一次 coder → delta；仅当 Approved = 10 时）：在可用时，必须使用 reviewer-agent（否则使用 ns-reviewer）的 version-closure code 模式。代码审查 Approved 之前，不要运行 ns-judge。然后在当前会话中运行 ../ns-judge/SKILL.md（closure）。如果 judge 返回 Rejected 后产品文件发生更改：再次进行代码审查，然后再次运行 judge。
6. 按照 review-gate-workflow.md 的最终报告字段进行汇报，并附上 {version_san}、工作树路径、提交，以及后续事项。不创建 GitLab 看板或 MR——除非 docs/context/gitlab-sync-config.md 存在且用户明确提出此要求（v1 范围之外；否则独立模式始终仅限本地）。

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

停下并询问人工

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

相关技能

技能	作用
ns-execution-gitlab-issue	GitLab 流程负责人——在第 2 阶段调用此技能
ns-coder	通过会话内实现（1 个单元）或 coder-agent（≥2 个单元——有可用项时必须使用）
ns-reviewer	通过 reviewer-agent 执行闭环代码门禁（有可用项时必须使用）——而非逐单元审查
ns-judge	Code Review: Approved 后在会话内提供交付证明
ns-harness	工件布局、工作树机制、发现

参考资料

文件	适用时机
references/routing.md	问题与独立模式的区分；Engine 模式的输入／输出，以及与 ns-execution-gitlab-issue 的循环防护
references/entry-triggers.md	优先级 3 的独立模式入口短语
references/planning-decision.md	自我评估启发式：单个单元，还是需求＋任务＋计划
references/doubt-resolution.md	自行提问、优先查阅文档、破坏性判定标准、升级格式
references/multi-agent-dispatch.md	DAG＋作用域不相交的并行规则、子 Agent 提示词、检查点提交
references/standalone-pipeline.md	完整的非 GitLab 流程：版本分配、独立工作树、审查循环

禁止事项

• 使用替代审查方式（senior-tech-lead-reviewer、bugbot、security-review 或任何非 ns-reviewer 的代码门禁）——允许使用 harness 的 reviewer-agent；参见 ../ns-reviewer/references/review-gate-workflow.md
• 在 Code Review: Approved 之前调用 ns-judge
• 未达到 Approved 或未明确处于受阻状态时报告成功
• 修复被 Rejected 的问题后，在闭环前跳过重新审查