ns-autonomous

Code Autonomous

ハーネス対応の実行エンジン：計画の深掘り、疑問の解決、マルチエージェントへのディスパッチ、レビューゲートを備えた、単独のパイプラインまたは呼び出し元の Phase 2 エンジンです。

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

固定ワークフローです。名前付きスキルへの引き継ぎ、またはハーネスブリッジ（../../ns-harness/references/subagent-dispatch.md の spawn gate）を使用します。レビューゲート：../ns-reviewer/references/review-gate-workflow.md。利用可能な場合は 必ず reviewer-agent（利用できない場合は ns-reviewer）を使用し、Code Review: Approved の場合に限り、セッション内で ns-judge を使用します。Task のペルソナで代用してはいけません。2 つ以上のユニットがある場合は、ユニットごとに 必ず coder-agent（ns-coder）を使用します。1 つのユニットの場合は、A（worktree）で ns-coder に従います。追加でスポーンしてはいけません。C2／単一ユニットのワーカーは実装のみを行い、ユニットごとのレビューは行いません。親が終了時に REV を担当します。

分離の不変条件（厳守）

スキルは、メインの製品チェックアウトにアプリケーションコードを 書き込みません。また、人間が今回の実行でインプレース作業を明示的に指示した場合を除き、main／master／base／SOURCE_BRANCH にコミットしません。

• Standalone モードと Engine モードでは、実装編集の前に、分離された WORK_BRANCH と WORKTREE_ROOT を用意します。
• worktree の作成に失敗した場合、または CWD／ブランチが引き続きメインチェックアウト／base の場合は、停止します。「計画を進めるために main で続行」してはいけません。
• サンドボックスの制限（Operation not permitted、.cursor/ パス）は、この不変条件に違反する許可にはなりません。

セッションの起動

../../ns-harness/references/session-boot.md を参照してください。このスキルの他の手順に進む前に、そこでセッションの起動（ブロッキング）を完了してください。

セッションの起動後 — Engine モードと Standalone モード

Engine モード： 呼び出し元が Phase 0 ですでにセッションの起動を完了している場合があります。コンテキストが不足している場合に限り、session-boot.md を再読してください。 Standalone： 単独パイプラインの手順 1 に進む前に、セッションの起動を行います。

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

エントリー優先順位テーブル：../../ns-harness/references/code-skill-routing.md。Standalone のトリガー：references/entry-triggers.md。

1. GitLab issue が起点の場合（ISSUE_URL または issue の参照）→ エントリー優先順位 1 — ns-execution-gitlab-issue に最初から最後まで従います。このスキルは、その Phase 2 エンジンとしてのみ実行します（以下の Engine モード）。Standalone パイプラインを実行せず、GitLab の状態に触れず、worktree を作成しません。
2. Standalone の自律実行（ローカルの計画ファイル、貼り付けられたテキスト／計画、issue を伴わない臨時の「これを自律的に実装して」という依頼）→ エントリー優先順位 3 — Standalone パイプラインを実行します。独自の worktree、独自の状態、独自のレビューループを使用します。

Engine モードの I/O と 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. マルチエージェントへのディスパッチ — 作業単位を解析します。1 単位： このセッションで WORKTREE_ROOT 内の ns-coder に従います（レビューは呼び出し元／単独のステップ 5 に委ねます）。2 単位以上： 作業単位ごとに、利用可能であれば 必ず coder-agent をディスパッチし、そうでなければ ns-coder を使用します。DAG の辺がなく、ファイルスコープが重複しない作業単位間でのみ並行処理し、それ以外は順次処理します。ワーカーは実装のみを担当します。作業単位ごとの reviewer-agent は使用しません。references/multi-agent-dispatch.md と ../../ns-harness/references/subagent-dispatch.md を参照してください。
4. チェックポイントコミット — 完了した順次処理の作業単位ごと、または完了した並列バッチごとに、ワークツリー内で 1 つコミットします。呼び出し元が引き渡し時にスカッシュします。
5. 修正ループの開始点 — Rejected の後に再呼び出しされた場合、全体マップをそのまま使用してコーダーを 1 回呼び出します（作業単位数による分割や「または作業単位」という表現はしません）。完了済みの作業単位はスキップします。
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 操作は行いません）、マルチエージェントへのディスパッチは、エンジンモードと同じロジックです。
5. 内部レビューのループ — ../ns-reviewer/references/review-gate-workflow.md（網羅的なマップ → コーダー 1 回 → delta、Approved = 10 のみ）に従います。バージョンクローズ用のコードモードでは、利用可能であれば 必ず reviewer-agent を使用し、そうでなければ ns-reviewer を使用します。コードが 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ラウンドを使い切った場合	停止してブロック状態として報告します — 成功したと捏造しないでください
GitLab のオリジンを指定して Engine モードを呼び出したのに、ワークツリー／ブランチが指定されていない場合	停止します — これは呼び出し元との契約違反であり、疑念ではありません

関連スキル

スキル	役割
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＋範囲が重複しない並列ルール、サブエージェントのプロンプト、チェックポイントコミット
references/standalone-pipeline.md	GitLab を使わない一連のフロー：バージョン割り当て、独自のワークツリー、レビューループ

禁止事項

• レビューの代替手段（senior-tech-lead-reviewer、bugbot、security-review、または ns-reviewer 以外のコードゲート）— ハーネスの reviewer-agent は使用できます。../ns-reviewer/references/review-gate-workflow.md を参照してください
• Code Review: Approved より前に ns-judge を実行すること
• Approved、または明示的なブロック状態のいずれも報告せずに、成功を報告すること
• 却下された修正を完了する前に、再レビューを省略すること