ns-code-autonomous

Code Autonomous

ハーネスを考慮した実行エンジンです。計画の深さを判断し、疑問を解消し、複数エージェントによる作業を振り分け、レビューゲートを通じて完了まで確認します。単独のパイプラインとしても、別のスキルの実行エンジンとしても利用できます。

ワークフローモード（必須）

固定ワークフローです。名前付きスキルへの引き継ぎ、またはハーネスプロジェクトとの連携（../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 が必要です。
• worktree の作成に失敗した場合、または CWD／ブランチが依然としてメインチェックアウト／ベースブランチである場合は、停止してください。「プランを進めるためにメインブランチで続行」してはいけません。
• サンドボックスの制限（Operation not permitted、.cursor/ 配下の Cursor エージェントのランタイムパス）は、この不変条件に違反する許可にはなりません。

ハーネスの検出

../ns-harness/references/harness-discovery.md を参照してください。このスキルのほかの手順を始める前に、そこでセッションの起動を完了してください（ブロッキング）。

セッション起動後 — エンジンモードとスタンドアロンモード

エンジンモード： 呼び出し元がフェーズ 0 ですでにセッションの起動を完了している場合があります。コンテキストが不足している場合に限り、harness-discovery.md を読み直してください。 スタンドアロンモード： スタンドアロンパイプラインの手順 1 に進む前に、自分でセッションの起動を行ってください。

ルーティング（最初に読む）

エントリ優先順位表：../ns-harness/references/code-skill-routing.md。スタンドアロンの起動条件：references/entry-triggers.md。

1. GitLab イシューが起点の場合（ISSUE_URL またはイシュー参照）→ エントリ優先順位 1 — ns-execution-gitlab-issue を最初から最後まで実行してください。このスキルはフェーズ 2 のエンジンとしてのみ実行します（以下のエンジンモード）。スタンドアロンパイプラインを実行せず、GitLab の状態にも触れず、worktree も作成しないでください。
2. スタンドアロンの自律実行（ローカルのプランファイル、貼り付けられたテキスト／プラン、イシューを伴わない「これを自律的に実装して」のような単発の依頼）→ エントリ優先順位 3 — スタンドアロンパイプラインを実行してください。独自の worktree、状態、レビューサイクルを管理します。

ns-execution-gitlab-issue とのエンジンモードの入出力および循環防止ルールについては、references/routing.md を参照してください。

Engine モード（ns-execution-gitlab-issue から呼び出された場合）

入力（呼び出し元によってすでに解決済み。このスキルでは作成しません）：issue ペイロード、{product_root}、WORKTREE_ROOT、WORK_BRANCH、SOURCE_BRANCH。

1. 計画の深さを自ら判断 — issue ペイロードを評価し、作業単位を1つにするか、docs/versions/{version_san}/ 以下に簡易版の requirements.md ＋ tasks/task-NNN-*.md ＋ execution-plan.md を作成するかを決定します。references/planning-decision.md を参照してください。
2. 疑問点への対応手順 — 自ら問いを立て、まずドキュメントを調べ、破壊的でない疑問には自ら回答します。破壊的な疑問は GitLab の状態を変更する代わりに、構造化イベントとして呼び出し元にエスカレーションします。再開されるまで、依存する作業単位は一時停止します。references/doubt-resolution.md を参照してください。
3. マルチエージェントへの振り分け — 作業単位（または単一の作業単位）を解析し、利用可能な場合は 必ず coder-agent（利用できない場合は ns-code-coder）ワーカーに振り分けます。DAG エッジがなく、ファイル範囲が重複しない作業単位間に限り並列で実行し、それ以外は順次実行します。すべてのサブエージェントは WORKTREE_ROOT 内で作業し、メインのチェックアウトでは作業しません。references/multi-agent-dispatch.md と ../ns-harness/references/subagent-dispatch.md を参照してください。
4. チェックポイントコミット — 完了した順次作業単位ごと、または完了した並列バッチごとに、ワークツリー内でコミットを1つ作成します。呼び出し元が納品時にスカッシュします。
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. 独自のワークツリーを作成します：../ns-harness/references/worktree-setup.md に従い、解決済みのベースブランチから {product_root}/.worktrees/{version_san}/ とブランチ work/{version_san} を作成します。パスは 製品ルート の下に置き、.cursor/ の下には置きません。失敗した場合は中止します（メインのチェックアウトにはフォールバックしません）。references/standalone-pipeline.md を参照してください。
4. 計画の深さの自己判断、疑問点への対応手順（破壊的な疑問はチャットのみで確認し、GitLab アクションは利用できません）、マルチエージェントへの振り分けは、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 を参照してください。

作業を止めて人に確認する

条件	アクション
破壊的な懸念（Engine モード）	呼び出し元にエスカレーションイベントを返します。ここでチャットを一時停止しません
破壊的な懸念（スタンドアロン）	チャットを一時停止して確認し、回答をコンテキストとして再開します
同じ {run_id} のワークツリーが競合（スタンドアロン）	明示的な再開指示がない限り停止します
git worktree add が失敗（権限／サンドボックス／パス）	中止し、試行したパスを報告します。メインのチェックアウトや .cursor/ には決してフォールバックしません
コードを編集しようとしている時点で、まだ main／master／ベースブランチにいる	中止します。分離されていないため、実装しません
人が「新しいブランチを作成しない／その場で作業する」と明示した	その場合に限り現在のブランチを編集できます。ただし、.cursor/ のパスを独自に作成してはいけません
スタンドアロンのワークツリーのベースブランチを特定できない	停止して一度だけ確認します
レビューが Blocked、または3ラウンドを使い切った	停止し、ブロックされたと報告します。成功を捏造してはいけません
GitLab の origin を指定して Engine モードを呼び出したが、ワークツリー／ブランチが指定されていない	停止します。これは懸念事項ではなく、呼び出し元の契約違反です

関連スキル

スキル	役割
ns-execution-gitlab-issue	GitLab フローの所有者 — Phase 2 でこのスキルを呼び出します
ns-code-coder	coder-agent によるサブエージェントの実装（利用可能な場合は必須）
ns-code-reviewer	reviewer-agent によるレビューチェックゲート（利用可能な場合は必須）
ns-harness	成果物のレイアウト、ワークツリーの仕組み、検出

参照

ファイル	使用する場面
references/routing.md	Issue とスタンドアロンの区別、Engine モードの I/O、ns-execution-gitlab-issue との循環防止
references/entry-triggers.md	優先度3のスタンドアロン開始フレーズ
references/planning-decision.md	自己評価のヒューリスティック：単一ユニットか、要件＋タスク＋計画か
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 以外のゲート）。ハーネスの reviewer-agent は使用できます。../ns-harness/references/review-gate-workflow.md を参照してください
• ns-code-reviewer の合格判定、または明示的なブロック状態なしに成功を報告すること
• Rejected の修正後、完了前の再レビューを省略すること