moai

実行前コンテキスト

!git status --porcelain 2>/dev/null || true !git branch --show-current 2>/dev/null || true

必須ファイル

.moai/config/sections/*.yaml

---

権威ある参照資料

すべてのワークフローを規定するルールと制約は、常に以下のソースから読み込まれます。ここに内容を重複して記載しないでください。

• 中核となるアイデンティティ、オーケストレーションの原則、エージェントカタログ：CLAUDE.md
• 品質ゲート、セキュリティ境界：.claude/rules/moai/core/moai-constitution.md
• SPEC ワークフローのフェーズ、トークン予算：.claude/rules/moai/workflow/spec-workflow.md
• 開発方法論（DDD/TDD）：.claude/rules/moai/workflow/spec-workflow.md（Run Phase セクション）
• エージェントの定義：CLAUDE.md のセクション 4 を参照してください。エージェントを作成する場合は、builder-harness サブエージェント（artifact_type=agent）を使用してください。
• @MX タグのルールとプロトコル：.claude/rules/moai/workflow/mx-tag-protocol.md

---

ルーティング観測ログ

サブコマンドまたはワークフローをディスパッチする際、オーケストレーターはディスパッチ時に moai harness ledger record を使用して、追記専用のルーティングログ（.moai/state/routing-ledger.jsonl）にルーティングの決定を記録します。リクエストテキストは標準入力経由で渡され、プライバシーに配慮したダイジェストのみが保存されます。ユーザーテキストがそのまま保存されることはありません。ルーティングされたパイプラインがゲートポイントに到達すると、機械的な証拠（ゲートの終了、監査結果、検証ログのパス）が moai harness ledger evidence によって追記されます。結果は入力として渡されず、機械的な証拠のみから確定されます。この観測はオプトイン方式で、障害発生時も処理を継続します。ルーティングを妨げることはありません。注：記録されるかどうかは、オーケストレーターがディスパッチ時に実際に moai harness ledger record を呼び出すかどうかに依存します。可観測性のオプトインが ON でも、その記録呼び出しが出力されない場合、ログは空のままです。これは未記録のディスパッチであり、オプトインが OFF の場合の何もしない動作ではありません。空のルーティングログを「オプトインが無効」と解釈しないでください。

---

インテントルーター

生のユーザー入力

$ARGUMENTS

ルーティング手順

[HARD] 上記の生のユーザー入力を、以下の厳密な優先順位に従ってルーティングしてください。サブコマンドとの照合には、入力の最初の単語を抽出してください。サブコマンドキーワードより後のテキストはすべて、一致したワークフローに渡すコンテキストであり、ルーティングの判断材料ではありません。どのワークフローを選択するかに影響させてはなりません。

実行モードフラグ（相互排他的）

• --team：Phase 4 の 4 モードカタログ（.claude/rules/moai/workflow/orchestration-mode-selection.md §A）からエージェントチームを強制します。機能ゲートが適用されます。
• --solo：逐次実行を強制します（サブエージェント — 各フェーズで単一のエージェントが順番に実行します）。
• フラグなし：オーケストレーターは Phase 4 で 4 モードのカタログから自動選択します。複雑さに基づく自動選択のしきい値は orchestration-mode-selection.md §B.1 に一度だけ記載されています（機械可読ソース：workflow.yaml の auto_selection）。ここでは再掲しません。

--team / --solo フラグはカタログの選択を強制的に上書きします。フラグがない場合は、カタログの判断ツリー（§B）とその機能ゲートに従って決定されます。--mode のディスパッチ軸は別の軸です。orchestration-mode-selection.md §G.1 のクロスウォーク（対応関係であり、統合ではありません）を参照してください。

優先度 1：明示的なサブコマンドの照合

[HARD] 上記のRaw User Inputセクションから最初の単語を抽出します。以下のいずれかのサブコマンド（またはそのエイリアス）に一致した場合は、ただちにそのワークフローに振り分けます。振り分けのために残りのテキストを分析してはいけません。残りのテキストは、一致したワークフローのコンテキストとして扱います。

[HARD] 混在言語のガード：最初の単語によるサブコマンド照合は、（a）入力が純粋なASCII／ラテン文字である場合、または（b）メッセージが文字どおりの /moai スラッシュ形式で始まる場合にのみ適用します。最初のトークン以降に非ラテン文字（韓国語／日本語／中国語など）が含まれるメッセージでは、先頭の英単語だけでただちに振り分けてはいけません。埋め込まれた借用語の可能性として扱い、優先度 3 に進んでメッセージ全体を意味分類します。理由：CJK の技術文書では、文頭に「goal」「run」「fix」「plan」などの英語の借用語が含まれることがあります。最初の単語だけですぐに振り分けると、誤判定が発生します。

• plan（エイリアス：spec）：SPEC ドキュメント作成ワークフロー
• run（エイリアス：impl）：DDD/TDD 実装ワークフロー（quality.yaml の constitution.development_mode に準拠）
• sync（エイリアス：docs, pr）：ドキュメントの同期と PR 作成
• project（エイリアス：init）：プロジェクトドキュメントの生成
• feedback（エイリアス：fb）：GitHub issue の作成
• fix：エラーの一括自動修正
• loop：完了条件が満たされるまで自動修正を繰り返す
• mx：コードベースの MX タグのスキャンと注釈付け
• review（エイリアス：code-review）：セキュリティと MX タグの準拠状況を含むコードレビュー
• clean（エイリアス：dead-code）：デッドコードを特定し、安全に削除
• codemaps：.moai/project/codemaps/ にアーキテクチャドキュメントを生成
• gate（エイリアス：check, pre-commit）：軽量なコミット前品質ゲート（lint+format+type-check+test）
• e2e（エイリアス：e2e-test, end-to-end）：プロジェクトタイプの自動検出と CLI 優先のツールチェーン選択による、マルチプラットフォームのエンドツーエンドテスト（web/mobile/desktop）
• harness（エイリアス：hrn）：ハーネスのライフサイクル管理 — 学習ライフサイクルの動詞（status / apply / rollback <date> / disable）と v4 ライフサイクルの動詞（list / edit / remove / doctor）を提供します。すべて統合された moai harness Go バイナリの Cobra サブコマンドツリーを通じてディスパッチします。スラッシュコマンドは、ドキュメントに記載されたユーザー向けのエントリーポイントです。
• goal：条件を宣言して動作する、汎用のエージェントループ — 完了条件を設定（/moai goal "<condition>"）し、ステータスの確認、解除、または再開を行います。各ターンの終了時に stop-goal Stop フックが条件を評価します。
• todo（エイリアス：backlog）：バックログキュー — スラッシュコマンドでは、項目の追加（/moai todo "<description>"）とキューの一覧表示（引数なしの /moai todo）の 2 つの操作ができます。次のカードを選ぶ操作とカードを削除する操作は CLI 専用の動詞で、それぞれ moai todo next [<n>] と moai todo done <n> を実行します。カンバンボードへのオペレーターのエントリーポイントです。

優先度 2：SPEC-ID の検出

優先度 1 で一致しなかった場合にのみ、Raw User Input に SPEC-XXX（SPEC-AUTH-001 など）に一致するパターンが含まれているか確認します。見つかった場合は、自動的に run ワークフローに振り分けます。SPEC-ID が DDD/TDD 実装の対象になります。

優先度 3: 自然言語分類

優先度 1 と優先度 2 の両方が一致しなかった場合にのみ: 生のユーザー入力全体の意図を自然言語として分類します。最初の単語が既知のサブコマンドと一致する場合、この優先度には決して到達しません。

[HARD] 以下に挙げる手がかり語は英語の例示であり、リテラル一致の要件ではありません。任意の conversation_language に対して意図を意味的に分類してください。同じ意図を表す韓国語、日本語、中国語、その他の言語のリクエストも同一にルーティングされます。リテラルの英語トークンが出現することを要求しないでください。

• 計画と言語設計 (design, architect, plan, spec, requirements, feature request) は plan にルーティングされます
• 品質ゲートの言語 (format, check, pre-commit, quality gate) は gate にルーティングされます
• E2E とユーザージャーニーのテスト言語 (e2e, end-to-end test, browser test, mobile app test, desktop app test, user journey) は e2e にルーティングされます — 意味的な例示であり、e2e テストの意図を表す任意の conversation_language も同一にルーティングされます
• セキュリティの言語 (security, audit, owasp, vulnerability, injection, xss, csrf) は review にルーティングされます (--security スコープ付き)
• コードレビューの言語 (review my code, code review, check my PR, look at my changes, take a look at my changes) は review にルーティングされます
• エラーと修正の言語 (fix, error, bug, broken, failing, lint) は fix にルーティングされます
• 反復と繰り返しの言語 (keep fixing, until done, repeat, iterate, all errors) は loop にルーティングされます
• デッドコードとクリーンアップの言語 (dead code, unused code, safely remove, cleanup, orphaned code) は clean にルーティングされます
• ドキュメントの言語 (document, sync, docs, readme, changelog, PR) は sync または project にルーティングされます
• アーキテクチャマップの言語 (architecture map, code maps, dependency graph, structure documentation) は codemaps にルーティングされます
• フィードバックとバグ報告の言語 (report, feedback, suggestion, issue) は feedback にルーティングされます
• MX タグの言語 (mx tag, annotation, code context, legacy annotate) は mx にルーティングされます
• バックログの言語 (add to the backlog, note this for later, what should I work on next, remind me to) は todo にルーティングされます — 意味的な例示であり、「これをキューに入れ、今は開始しないでください」という意図を表す任意の conversation_language のリクエストも同一にルーティングされます
• 実装の言語 (implement, build, create, add, develop) でスコープが明確なものは moai (デフォルトの自律) にルーティングされます

優先度 4: デフォルトの動作

すべての優先度チェックの後でも意図が曖昧な場合は、AskUserQuestion を使用して一致する上位 2〜3 件のワークフローを提示し、ユーザーに選択させてください。

意図が特定のルーティングシグナルを持たない開発タスクであることが明らかな場合は、完全自律実行のために moai ワークフロー (plan -> run -> sync パイプライン) をデフォルトとしてください。

---

ワークフロー早見表

plan - SPEC ドキュメントの作成

目的: Research-Plan-Annotate サイクルを用いて、GEARS 形式で包括的な仕様ドキュメントを作成します。 フェーズ: Deep Research (research.md) -> SPEC Planning -> Annotation Cycle (1〜6 回の反復) -> SPEC Creation -> Independent Review (plan-auditor) エージェント: manager-spec (主担当)、Explore (リサーチ)、plan-auditor (品質ゲート)、manager-git (条件付き) スキル: moai-workflow-spec、moai-foundation-thinking (delegation.yaml に従う) フラグ: --branch、--resume SPEC-XXX、--issue (オプトイン。デフォルトでは late-branch オプトインポリシーに従い GitHub Issue の作成をスキップします) 詳細なオーケストレーション: ${CLAUDE_SKILL_DIR}/workflows/plan.md を参照

run - DDD/TDD 実装

目的: 設定された開発手法を通じて SPEC の要件を実装します。 エージェント: manager-develop (quality.yaml に従い cycle_type=ddd|tdd、主担当)、manager-git スキル: moai-workflow-tdd、moai-workflow-ddd (delegation.yaml に従い cycle_type で選択) + ミッションごとに注入されるドメイン moai-ref-* フラグ: --resume SPEC-XXX、--team (実験的 — Agent Teams が再許可されています。Execution Mode Flags を参照) 詳細なオーケストレーション: ${CLAUDE_SKILL_DIR}/workflows/run.md を参照

sync - ドキュメント同期と PR

目的：コード変更に合わせてドキュメントを同期し、プルリクエストを準備します。 エージェント：manager-docs（プライマリ）、sync-auditor（品質ゲート）、manager-git スキル：moai-workflow-project（delegation.yaml に従う） モード：auto、force、status、project。フラグ：--merge、--skip-mx 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/sync.md を読んでください。

gate - コミット前の品質ゲート

目的：lint、format、type-check、テストを並列実行する、軽量なコミット前の品質チェックです。run（フェーズ 15）および sync（フェーズ 1）のワークフローにも、自動事前チェックとして統合されています。 エージェント：直接実行（エージェントへの委任なし） フラグ：--fix、--staged、--file PATH 統合：run ワークフロー（フェーズ 15）および sync ワークフロー（フェーズ 1）から、--fix の動作で自動的に呼び出されます。 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/gate.md を読んでください。

e2e - マルチプラットフォームのエンドツーエンドテスト

目的：プロジェクトタイプの自動検出、CLI 優先のツールチェーン選択（Playwright、Maestro、Playwright-Electron、WebdriverIO + tauri-service）、トークンを最小限に抑えた実行により、ウェブ、モバイル、デスクトップアプリケーションの E2E テストを作成して実行します。 エージェント：e2e-tester（プライマリ — 検出、ジャーニーのマッピング、スクリプトの作成、実行、記録） スキル：moai-foundation-quality、moai-ref-testing-pyramid（delegation.yaml に従う） フラグ：--tool、--platform、--record、--url、--journey、--headless、--browser、--timeout、--retry 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/e2e.md を読んでください。

goal - 条件宣言型エージェントループ

目的：完了条件（機械的なコマンドとモデルによる申告）を設定します。stop-goal Stop-hook 評価器は、条件が満たされるか、ターン上限（デフォルト 30）に達するまで、各ターンの終了をブロックします。 動詞：/moai goal "<condition>"（登録 + 設定）、status [--all]、clear、resume。 進行モード：自律型（デフォルト）または半自律型 — 実装キックオフの承認時に選択します。どちらのモードでもゲートは必須です。 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/goal.md を読んでください。

todo - バックログキュー

目的：オペレーターが次に取り組みたい作業を保持します。backlog には所有セッションがないため、ボードへの追加は常にオペレーターが行います。このワークフローはそのためのものです。 動詞 — スラッシュコマンド：/moai todo "<description>"（追加）、単独の /moai todo（一覧）。CLI のみ：moai todo next（キュー内のカードを表示。moai todo next <n> [--spec <SPEC-ID>] は選択済みとしてマークします。選択自体は AskUserQuestion を通じて提示されます）、moai todo done <n>（削除）。 状態：.moai/state/kanban/backlog.json — プロジェクトローカル、コミット対象外、アトミック書き込み。 選択するのはオペレーターです。事前選択、推測した優先度による並べ替え、TODO コメントや issue からの自動追加は行わないでください。 有効化：.moai/config/sections/workflow.yaml で workflow.todo.enabled が false の場合、推測でこのワークフローに振り分けないでください。オペレーターがサブコマンドを指定していないバックログらしき表現には、キューに追加せず直接回答します。このゲートが制御するのは自動振り分けのみです。明示的な /moai todo または /moai todo "<description>" は、キーが存在しない場合や true の場合と同じように、引き続き通常どおり実行されます。このフラグが抑制するのはガイダンスであり、機能ではありません。moai todo は引き続き登録され、すべての動詞が動作します。そのため、明示的に指定された呼び出しを拒否したり、黙って無視したりするのは不具合であり、意図された動作ではありません。 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/todo.md を読んでください。

fix - エラーの自動修正

目的：LSP エラー、lint の問題、型エラーを自律的に検出して修正します。 エージェント：manager-develop（cycle_type=autofix）、ドメイン許可リスト付きの Agent(general-purpose)（修正） スキル：moai-workflow-ddd（delegation.yaml に従う）+ ミッションごとに注入されるドメインの moai-ref-* フラグ：--dry、--sequential、--level N、--resume、--team（実験的 — Agent Teams が再び許可されています。Execution Mode Flags を参照） 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/fix.md を読んでください。

loop - 反復自動修正

目的：完了条件が満たされるか、最大反復回数に達するまで問題を繰り返し修正します。 エージェント：manager-develop（cycle_type=autofix）、Agent(general-purpose)（ドメインのホワイトリストを適用） スキル：moai-workflow-loop（delegation.yaml に従って適用）＋ミッションごとに注入されるドメイン固有の moai-ref-* フラグ：--max N、--auto-fix、--seq オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/loop.md を読みます

mx - MX タグのスキャンと注釈付け

目的：コードベースをスキャンし、AI エージェントのコンテキスト用に @MX コードレベル注釈を追加します。 エージェント：Explore（スキャン）、Agent(general-purpose)（バックエンドの範囲で注釈付け） フラグ：--all、--dry、--priority P1-P4、--force、--team（試験運用 — Agent Teams が再び許可されています。Execution Mode Flags を参照） オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/mx.md を読みます

review - コードレビュー

目的：セキュリティ、パフォーマンス、品質、UX の分析を含む、多角的なコードレビューを行います。 エージェント：sync-auditor（レビュー）、Agent(general-purpose)（セキュリティの範囲で対応） スキル：moai-foundation-quality、moai-ref-owasp-checklist（delegation.yaml に従って適用。視点ごとの参照スキルは各観点に応じて注入） フラグ：--staged、--branch、--security、--team（試験運用 — Agent Teams が再び許可されています。Execution Mode Flags を参照） オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/review.md を読みます

clean - デッドコードの削除

目的：未使用コードを特定し、テストで検証しながら安全に削除します。 エージェント：manager-develop、Agent(general-purpose)（リファクタリングの範囲で対応） スキル：moai-workflow-ddd（delegation.yaml に従って適用） フラグ：--dry、--safe-only、--file PATH オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/clean.md を読みます

codemaps - アーキテクチャドキュメント

目的：コードベースをスキャンし、アーキテクチャドキュメントを生成します。 エージェント：Explore、manager-docs フラグ：--force、--area AREA オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/codemaps.md を読みます

(default) - MoAI 自律型ワークフロー

目的：調査 -> 計画 -> 注釈付け -> 実行 -> 同期の全自動パイプラインです。 フェーズ：並列探索（research.md） -> SPEC の生成 -> 注釈サイクル -> 実装 -> 同期 エージェント：Explore、manager-spec、plan-auditor（品質ゲート）、manager-develop、manager-docs、manager-git、sync-auditor（品質ゲート） スキル：moai-workflow-spec、moai-workflow-tdd（delegation.yaml に従って適用）＋ミッションごとに注入されるドメイン固有の moai-ref-* フラグ：--loop、--max N、--branch、--pr、--resume SPEC-XXX、--team（試験運用 — Agent Teams が再び許可されています。Execution Mode Flags を参照）、--solo、--issue（オプトイン。遅いブランチ作成時のオプトインポリシーにより、デフォルトでは GitHub Issue の作成をスキップします） オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/moai.md を読みます

project - プロジェクトドキュメント

目的：既存のコードベースを分析し、プロジェクトドキュメントを生成します。 エージェント：Explore、manager-docs、Agent(general-purpose)（DevOps の範囲で対応、任意） スキル：moai-workflow-project（delegation.yaml に従って適用） 出力：.moai/project/ 内の product.md、structure.md、tech.md オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/project.md を読みます

feedback - GitHub Issue の作成

目的：ユーザーからのフィードバックを収集し、GitHub Issue を作成します。 エージェント：orchestrator-direct（gh CLI を使ってフィードバックを記録） オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/feedback.md を読みます

harness - ハーネスのライフサイクル＋自然言語による構築（引数による分岐）

この単一の harness サブコマンドは、$ARGUMENTS の最初のトークンに基づいて、2 つのワークフローのいずれかに振り分けます（引数ベースのルーティング — 2 つ目のコマンドは導入されません）。ワークフロー固有のロジックを適用する前に、ルーティングルールを適用してください。

• 予約動詞（status / apply / rollback / disable）→ 既存の ハーネス学習ライフサイクルワークフロー（以下のブランチ A）に振り分けます。この経路に変更はありません。
• 予約動詞（list / edit / remove / doctor）→ harness-v4 ライフサイクルハンドラー（以下のブランチ A.1）に振り分けます。これらの動詞は、moai harness <verb> Go バイナリーサブコマンドを通じて、harness-v4 エントリーの列挙／編集／原子的な削除と、参照整合性のスモークゲート（doctor）を実行します。
• それ以外（「CLI テンプレートの開発用ハーネスを構築する」のような自然言語によるハーネス作成リクエスト）→ ハーネス構築エントリーワークフロー（以下のブランチ B）に振り分けます。

ブランチ A — ハーネス学習ライフサイクル（予約動詞：status / apply / rollback / disable）

目的：スラッシュコマンド経由で、ハーネス学習サブシステム（オブザーバー、4 段階の提案ラダー、5 層の安全パイプライン）をユーザーに提示します。ライフサイクル動詞（status / apply / rollback / disable）は、統合された moai harness Go バイナリーの Cobra サブコマンドツリーを通じてディスパッチされ、ファイルシステム操作を実行します。Tier-4 の適用には、オーケストレーターが発行する AskUserQuestion が必要です。 スキル：moai-harness-learner（Tier-4 の提示を補助）。プロジェクト固有のハーネス生成は、v4 Builder（builder-harness エージェント、ブランチ B）が担当します。 動詞：status（Tier の分布＋テレメトリー） | apply（次の Tier-4 提案 → AskUserQuestion → 5 層パイプライン → スナップショット＋書き込み） | rollback <YYYY-MM-DD>（スナップショットを復元） | disable（learning.enabled: false に設定） 成果物：.moai/harness/usage-log.jsonl、.moai/harness/proposals/、.moai/harness/learning-history/snapshots/、.moai/harness/learning-history/applied/、.moai/harness/learning-history/frozen-guard-violations.jsonl 正式な SPEC：ハーネス基盤ポリシー（V3R3-HARNESS-001、V3R3-HARNESS-LEARNING-001、V3R3-PROJECT-HARNESS-001 に優先します） 詳細なオーケストレーションについては、${CLAUDE_SKILL_DIR}/workflows/harness.md を読み込んでください。

ブランチ A.1 — harness-v4 のライフサイクル（予約動詞：list / edit / remove / doctor）

目的：harness-v4 エントリーを管理します。構築済みハーネスの一覧表示、編集用のマニフェストとスペシャリストファイルの場所の特定、すべてのアーティファクトを含むハーネスのアトミックな削除、または参照整合性のスモークゲートの実行を行います。4 つの動詞は、ファイルシステム処理を行う moai harness <verb> Go バイナリのサブコマンドに振り分けられます（.claude/commands/harness/*.md を manifest.json と照合してスキャンし、孤立ファイルをフェイルクローズで防止しながらアトミックに削除し、マニフェスト／スペシャリスト／スキルファイルの存在を相互参照する doctor）。 動詞：list（すべてのハーネスを列挙：名前＋ドメイン＋エントリーコマンド。マニフェストでスケジュールが宣言されている場合は、宣言されたスケジュール（間隔＋仕組み）も表示します。スケジュールのないハーネスは、スケジュール導入前のベースラインと同じ形式で表示されます） | edit <name>（編集用のマニフェスト＋スペシャリスト＋スキルのパスを表示 — マニフェストが SSOT です） | remove <name>（コマンド＋ワークフロー＋スペシャリスト＋スキル＋マニフェストをアトミックに削除します。いずれかのアーティファクトが欠けている場合はフェイルクローズします。マニフェストでスケジュールが宣言されていた場合は、削除前にマニフェストから算出した、宣言済みの仕組みを示す登録解除通知を出力します。cron の場合は CronDelete、loop の場合はセッションスコープのループキャンセルです） | doctor（参照整合性のスモークゲート：構築済みの各ハーネスについて、マニフェスト／スペシャリスト／スキルファイルが存在し、相互参照が正しいことを検証します。スキーマに無効なスケジュール宣言がある場合は、重大度 ERROR の検出結果になります） CLI：moai harness list [--json]、moai harness edit <name> [--json]、moai harness remove <name>、moai harness doctor（すべて --project-root に対応） アーティファクト：.claude/commands/harness/<name>.md（薄いラッパーコマンド）、.claude/commands/harness/<name>/manifest.json（SSOT）、.claude/workflows/hns-<name>-run.js（Runner）、.claude/agents/harness/hns-<name>*-specialist.md（スペシャリスト）、.claude/skills/hns-<name>*/（付随スキル） 名前空間：.claude/commands/harness/、.claude/workflows/hns-*.js、.claude/agents/harness/、.claude/skills/hns-*/ はユーザー所有です。moai update はこれらを保持します（必要に応じてバックアップし、上書きはしません）。harness- または my-harness- プレフィックスを持つ旧世代のものも同様に保持されます（認識ベースの後方互換性）。Builder が出力する名前は hns- のみです。

ブランチ B — harness ビルドのエントリー（自然言語によるリクエスト）

目的：自然言語によるハーネス作成リクエストを、Context-First Discovery（ドメイン／目標／制約／スコープの抽出）、harness <name> の導出（名前はリクエストから導出され、ユーザーが静的に指定するものではありません）、オーケストレーターによる明示的な承認を経て、オーケストレーターが直接実行する Builder（シグナル駆動の 4 フェーズ：ANALYZE / PLAN / GENERATE / ACTIVATE）へ移行することで、具体的なハーネスに変換します。意図の明確さが 100% 未満の場合、オーケストレーターは AskUserQuestion によるソクラテス式の対話（1 ラウンドにつき最大 4 問）を必ず実施します。 エージェント：builder-harness（v4 Builder — プロジェクト固有のハーネス生成） Builder：オーケストレーターが直接処理します（動的ワークフロースクリプトではありません）。エントリーのフェーズ 0〜3 では、作成ロジックの 4 フェーズを ${CLAUDE_SKILL_DIR}/workflows/harness-builder.md に引き継ぎます。オーケストレーターが PLAN→GENERATE の AskUserQuestion 承認ゲートを直接管理します。このゲートのラウンドには、再発に関する質問（任意のマニフェスト schedule、検出のみを行うスケジュール実行）も含まれます。ACTIVATE では、スモークゲートの後に宣言済みスケジュールを登録します。既存のハーネスに言及し、スケジュール設定の意図も含むリクエストは、作成パイプラインではなく、エントリーワークフローの Schedule Retrofit ブランチに振り分けられます（名前の衝突処理より先に評価されます）。 オーケストレーションの詳細：${CLAUDE_SKILL_DIR}/workflows/harness-build-entry.md を読みます

---

実行ディレクティブ

このスキルが有効化されたら、次の手順を順番に実行します。 ステップ 1 - 引数の解析： Raw User Input からサブコマンドのキーワードとフラグを抽出します。認識されるグローバルフラグ：--resume [ID]、--seq、--team、--solo。入力テキスト内の ultrathink キーワードも検出します。

重要：詳細分析モード：

• ultrathink キーワードが検出された場合 → Claude のネイティブな拡張推論（xhigh 労力モード）を有効にします。これは MCP に依存しない、Claude ネイティブの動作です。

ステップ 1.5 - フラグとサブコマンドの互換性検証： [HARD] サブコマンドとフラグの解析後（ステップ 1）、ルーティングの前に、フラグとサブコマンドの互換性を検証します。禁止された組み合わせが検出された場合は、すべての後続処理を停止し、ユーザーの conversation_language でエラーを出力します。ステップ 2 に進んではいけません。

禁止されているフラグとサブコマンドの組み合わせ：

フラグ	使用可能なサブコマンド	使用禁止のサブコマンド
--branch	plan、デフォルト（自律型）	run、sync

理由：--branch は SPEC の初期化時に機能ブランチを作成するため、/moai run と /moai sync は、すでに plan で設定されたブランチで実行する必要があります。ライフサイクルの途中でブランチを再作成すると SPEC のライフサイクルが破損するため、ルーターレベルで拒否されます。

廃止された --worktree フラグは別途処理します。このフラグを含むリクエストは、禁止された組み合わせによるエラーではなく、廃止されたフラグとして扱います。plan ではワークスペースを作成しなくなったこと、および先にワークスペースに入る方法が代替手段であることをユーザーに伝えてください。

エラーメッセージのテンプレート（韓国語の conversation_language。実際のフラグとサブコマンドに置き換えてください）：

에러: --branch 플래그는 /moai plan 전용입니다.
/moai run 과 /moai sync 는 plan 단계에서 만든 브랜치를 그대로 씁니다.

올바른 사용법:
  /moai plan SPEC-XXX --branch    (브랜치 생성)
  /moai run SPEC-XXX              (기존 브랜치 재사용)
  /moai sync SPEC-XXX             (기존 브랜치 재사용)

--branch 플래그를 뺀 형태로 다시 실행하세요.

廃止フラグのメッセージ（--worktree）：

안내: --worktree 플래그는 폐기됐습니다. plan 은 더 이상 작업 공간을 만들지 않습니다.

격리된 공간에서 작업하려면 먼저 들어간 뒤 plan 을 실행하세요:
  moai cc -w <이름>              (그 자리에서 진입)
  moai cg -w <이름> --spawn      (새 tmux 창, 현재 세션 유지)
  /moai plan "<설명>"

英語（en の conversation_language）の場合は、メッセージを翻訳します。構造は同一です。

ステップ 2 - ワークフローへのルーティング： インテントルーター（優先度 1 から優先度 4）を適用し、対象のワークフローを決定します。曖昧な場合は、AskUserQuestion を使用してユーザーに確認します。

ステップ 2.2 - ルーティング決定の記録： ルーティングが確定した直後（ステップ 2）、追記専用のルーティング台帳（.moai/state/routing-ledger.jsonl）にルーティングの決定を記録し、自動呼び出しを監視できるようにします。次を実行します：

echo "<raw request text>" | moai harness ledger record --subcommand <matched> --mode <phase-4-mode> --tier <tier> --level <harness-level> --session <session-id>

リクエストテキストは stdin 経由で渡され、プライバシー保護されたダイジェストのみが保存されます。ユーザーのテキストがそのまま保存されることはありません（ポリシーの出典：上記の「ルーティング観測台帳」）。このステップはオプトイン方式で、失敗しても処理を続行します。moai CLI が PATH に存在しない場合、またはコマンドがゼロ以外の終了コードを返した場合は、何も記録せずに続行します。このステップによってルーティングがブロックされたり、ワークフローが制限されたり、再試行ループが発生したりすることは決してありません。記録されないディスパッチは観測上の空白であり、エラーではありません。

ステップ 2.5 - プロジェクトドキュメントの確認： plan、run、sync、fix、loop、またはデフォルトのワークフローを実行する前に、.moai/project/product.md の有無を確認し、プロジェクトドキュメントが存在することを検証します。product.md が存在しない場合は、AskUserQuestion を使用してユーザーの conversation_language で尋ねます。

質問：プロジェクトドキュメントが見つかりません。先に作成しますか？ 選択肢：

• プロジェクトドキュメントを作成（推奨）：ガイド付きインタビューを通じて product.md、structure.md、tech.md を生成します。これにより、MoAI がプロジェクトのコンテキストを把握できるようになり、その後のすべてのワークフローでより良い結果が得られます。
• スキップして続行：プロジェクトドキュメントなしで続行します。MoAI が把握できるプロジェクトのコンテキストは少なくなります。

この確認は、project および feedback サブコマンドには適用されません。

[HARD] 初心者にわかりやすい選択肢の設計： MoAI のワークフロー全体で AskUserQuestion を呼び出す場合は、次のルールに従う必要があります。

• 最初の選択肢は、必ず推奨される選択肢とし、「（推奨）」の接尾辞を明確に付けます。
• すべての選択肢に、実行内容とその影響を説明する詳細な説明を含めます。

ステップ 2.8 - 要件分析と完了条件： ワークフロー本文を読み込む前（ステップ 3）に、ルーティングされたリクエストの要件分析レコードを作成します。

1. 要件の概要（1～3 文）：オーケストレーター自身の言葉で、ユーザーの依頼を言い換えます。
2. 完了条件：「完了」とみなされる最終状態です。条件を機械的に検証できる場合（テストの終了コード、lint エラーがない状態、grep の件数、ターン数の上限など）は、.claude/rules/moai/workflow/goal-directive.md に従って /moai goal 互換の形式（測定可能な最終状態を 1 つ、明記した確認方法、上限条項）で表現します。並行する評価機構を独自に作らないでください。goal engine が利用可能な場合（hooks が有効な場合）は、/moai goal で条件を設定します（評価を行うのは stop-goal Stop hook です）。利用できない場合は、各ターンでオーケストレーターが同一の条件文を評価します（縮退運用では新たな仕組みを追加しません）。
3. パイプライン契約：full-pipeline（自然言語によるデフォルトのルート。run-phase の完了後、自動的に sync に連鎖します）または single-phase（明示的な run／sync サブコマンド。連鎖は「（推奨）」の次のステップとして提示し、暗黙には実行しません）。
4. オーケストレーション形状の事前シグナル：Phase 4 の 4 モード選択（orchestration-mode-selection.md §A）に対する早期の入力です。ここで記録し、決定は Phase 4 で行います。

簡易スコープの免除：feedback、gate、codemaps、sync のステータスモード、および askuser-protocol.md § Ambiguity Triggers and Exceptions に基づく Stage-1-Clarify の例外では、このステップを完全に省略します。 ソクラテス式の優先順序：意図の明確さが 100% 未満の場合は、完了条件を導き出す前に、ソクラテス式インタビュー（askuser-protocol.md に準拠）を実施します。条件には、推測ではなく、意図を明確にした結果を反映させます。 導き出された完了条件は、自律的な run-phase の開始を決して許可しません。plan→run の境界では、Implementation Kickoff Approval が引き続き必須です。

Step 3 - ワークフローの詳細を読み込む： 対象サブコマンドの workflows/<name>.md を読みます。（Agent Teams の静的レイヤーは廃止されています。--team フラグは .claude/rules/moai/workflow/orchestration-mode-selection.md に従ってサブエージェントモードにフォールバックします。別個の team/<name>.md ワークフローファイルはありません。）

Step 4 - 設定を読み込む： 必要に応じて、.moai/config/sections/*.yaml セクションファイルから関連する設定を読み込みます。

Step 5 - タスク追跡を初期化する： TaskCreate を使用して、見つかった作業項目を pending ステータスで登録します。

Step 6 - ワークフローの各フェーズを実行する： ワークフロー固有のフェーズ手順に従います。実装はすべて、Agent() を介して適切なエージェントに委任します。指定されたチェックポイントでは、AskUserQuestion を介してユーザーの承認を得ます。実装またはレビューを担当する Agent() を起動する前に毎回、.claude/rules/moai/workflow/skill-routing.md §1 を適用します。委任マップ（.moai/config/sections/delegation.yaml）に従って、At start, invoke Skill("<name>") for <reason> の行を 0～3 行挿入します。

Step 7 - 進捗を追跡する： 作業の進行に合わせて TaskUpdate を使い、タスクのステータスを更新します（pending から in_progress、さらに completed へ）。

Step 8 - 結果を提示する： Markdown 形式で、ユーザーの conversation_language を使って結果を表示します。

Step 9 - 完了を宣言する： すべてのワークフローフェーズが正常に完了したら、結果が明確になるように、Completion Report（バナーまたは文章）でワークフローの完了を伝えます。

Step 10 - 次のステップを案内する： AskUserQuestion を使い、完了したワークフローに基づく論理的な次のアクションをユーザーに提示します。

---

Version: 2.8.0 Last Updated: 2026-07-07