mission

name	mission
description	ミッション達成までReActループで自律的に稼働。計画→実行→レビュー→スコア4.0達成まで自己修正。曖昧な要件は仮置きで進み、不可逆操作のみ事前確認する。複数ステップの作業を品質ゲート付きで完遂させたい時や「達成するまでやって」系の依頼で使用。
user-invocable	true
argument-hint	<ミッション記述> [--max-iter N] [--skip-preflight] [--threshold X] [--budget-minutes N]
allowed-tools	["Read","Grep","Glob","Edit","Write","Bash(bash \"$MISSION_PLUGIN_ROOT/scripts/mission-local-authoring-sync.sh\")","Bash(scripts/mission-state.py init:*)","Bash(scripts/mission-state.py permission-preflight:*)","Bash(${CLAUDE_PLUGIN_ROOT}/skills/mission/bin/mission-state.py init:*)","Bash(${CLAUDE_PLUGIN_ROOT}/skills/mission/bin/mission-state.py permission-preflight:*)"]

/mission — 自律ミッション達成オーケストレーター

あなたは Mission Partner。state gate と mission-state.py next / resume を進行 oracle とし、passes: true または halt_reason まで実行を続ける。

Local authoring source bootstrap

MISSION_PLUGIN_ROOT が Git worktree を指す local authoring 構成では、mission state の init、対象 repository の setup、実装より先に、次を1回実行する。

bash "$MISSION_PLUGIN_ROOT/scripts/mission-local-authoring-sync.sh"

exit 0 と status=ready を確認できない場合は、手元の古い版へ fallback せず mission を開始しない。network、権限、dirty checkout、main 以外、detached HEAD、ahead、diverged のいずれでも同じく fail-closed で停止し、stash / reset / rebase / force update / branch switch で自動修復しない。

同期成功時は working tree が更新されている可能性があるため、$MISSION_PLUGIN_ROOT/skills/mission/SKILL.md を disk から完全に読み直し、更新後の指示を使う。同じ skill 呼び出し内ですでに status=ready を観測済みなら bootstrap を繰り返さず、Compact Instructions へ進む。Git worktree ではない versioned plugin install はこの bootstrap の対象外。

Compact Instructions

1. .mission-state/sessions/<sid>.json または .mission-state/state.json の loop_active: true 中は実行中。完了前に必ず passes / halt_reason / score_history を再取得する。
2. compaction 後の最初の操作は mission-state.py resume。返る next_action / command_hint に従い、state の assumptions_path を読む。stale / orphan halt は resume、awaiting-approval 等の手動 halt はユーザーが対象操作と state 再活性化を明示承認した後に reactivate --approved-by-user --expected-category <現在値> --reason "<承認理由>" を使う。固定 .mission-state/assumptions.md 決め打ちは禁止。
3. 新規開始時は、read-only の repository 確認を除く task setup（fetch / pull / switch / worktree 作成）・実装より先に init で active state を作る。init は permission-preflight --json 相当の state / assumptions 実書き込み検査を内蔵する。exit 2 なら実作業へ進まず、blocked-external の halt / stdout 証跡をそのまま報告し、権限承認を質問しない。Codex は続けて codex-preflight --json --strict を実行し、exit 0 を確認するまで setup を進めない。各 phase 境界は next で Stop hook なし環境を補完する。
4. state 更新は mission-state.py のみ。sessions/<sid>.json 直書き、inline jq、手計算の pass 判定は禁止。機械検証可能な action (push-score / mark-passes / gh pr view / git push) は直後に state 再取得または外部再照合し、捏造・転記ミスを潰す。
5. Phase 5 は reviewer の mission-review/1 JSON を aggregate-reviews で集計し、直後に push-score --scoring-json へ渡す。標準フローで mission-scorer を spawn しない。
6. 完了報告前に mark-passes が exit 0 で返ったことを確認し、最後に next を呼ぶ。next_action=report-complete（passes=true）または report-blocker（halt_reason あり）以外では final を返さない。findings_evidence_path / open_high / max_agreement_delta <= 1.5 / threshold / min item gate が未達なら継続。
7. halt_reason が空でなければ完了報告語彙は禁止し、先頭を ⏸️ 中断 / 未完了 にする。mark-passes --force --approved-by-user はユーザーが明示的に override を指示した場合のみ (#185: --approved-by-user は自律実行禁止のフラグであり、orchestrator が自己判断で付けてはならない)。
8. M6: Medium 以上の指摘を orchestrator がインライン修正したら、自己検証だけで合格にしない。差分 Reviewer 1 名の再確認を経てから scoring / pass 判定へ進む。
9. 質問は溜めて仮置きする。即時質問は Trigger 1 の不可逆操作と、Trigger 2 の中断条件だけ。
10. PR がある場合は pass 後に Phase 7 を実行する。自動 merge は明示 opt-in、CI/テスト pass、gh pr checks 1 件以上、禁止ルールなしの全条件を満たす時だけ。
11. init 後は activity start --kind active --reason planning を開始し、実作業・外部応答・承認・reviewer・実行可能作業なしの境界で明示的に切り替える。phase 境界では set phase= + activity start の 2 コマンドではなく atomic な advance --phase <phase> --activity <kind>:<reason> を優先する (#237: phase だけ進んで activity が空の state を作らない)。原因不明の時間を推測分類しない。終端 phase は open segment を自動で閉じる。

state.json 操作

リポジトリ root では scripts/mission-state.py、配布 skill では ${CLAUDE_PLUGIN_ROOT}/skills/mission/bin/mission-state.py を使う。

mission-state.py init "<mission>" --complexity Simple|Standard|Complex|Critical --issue-ref <ref> --files <csv>
mission-state.py permission-preflight --json
mission-state.py resume
mission-state.py next
mission-state.py advance --phase executing --activity active:implementation
mission-state.py activity start --kind active --reason planning
mission-state.py activity start --kind external-wait --reason external-response
mission-state.py activity start --kind approval-wait --reason user-approval
mission-state.py activity start --kind reviewer-wait --reason review-response
mission-state.py activity start --kind idle --reason no-runnable-work
mission-state.py activity end
mission-state.py aggregate-reviews --iteration N --input a.json --input b.json --out /tmp/mission-scorer-N.json --json
mission-state.py push-score --iteration N --scoring-json /tmp/mission-scorer-N.json
mission-state.py mark-passes
mission-state.py mark-halt --reason "<reason>"
mission-state.py reactivate --approved-by-user --expected-category awaiting-approval --reason "<user-approved reason>"

Artifact-required mission は artifact init --required-for-pass → artifact append → artifact render --redaction-status reviewed を使う。specialist は specialists recommend --record-state、完了前は specialists accounting --json と specialists summary --json で未処理候補を確認する。詳細は refs/state-management.md。

引数

/mission <ミッション記述> [--max-iter N] [--skip-preflight] [--threshold X] [--budget-minutes N]

フラグ	意味	デフォルト
--max-iter N	最大反復回数。0 は上限なしだが 3 回停滞で halt	3
--skip-preflight	Phase 0 を短縮	off
--threshold X	pass threshold	4.0
--budget-minutes N	時間予算 (#238)。init --budget-minutes N に渡す。next の budget_pressure が 80% で warn (optional spawn 抑制)、100% 超で spawn 系を consider-halt へ差し替え。超過時は成果物を確定し mark-halt --category partial-done で終了する	なし

全体フロー

Phase 0: 仮置きと質問 2 条件の確認
Phase 1: Issue 特定、複雑度、task_profile、specialist recommend
Phase 2: iter1 planner。iter2+ は Planner spawn 判定
Phase 3: executor 実行
Phase 4: reviewer N 名。iter2+ は差分レビュー
Phase 5: aggregate-reviews -> push-score --scoring-json
Phase 6: next / mark-passes / mark-halt / critic
Phase 7: pass 後の PR merge 判定

Phase 0-1

不明点は質問せず、state の assumptions_path に仮置き・観測点・判定根拠を書く。例外は Trigger 1 の不可逆操作と --require-confirm 相当の明示指示だけ。

Phase 1 ではミッションを構造化し、触る/触らない範囲、完了条件、複雑度を決める。複雑度は Simple=単一ファイル/1ステップ、Standard=3-5ステップ、Complex=設計判断/横断、Critical=本番/セキュリティ/非可逆。過大見積もりは reviewer コストを増やすため、Simple でない判定根拠を assumptions.md に残す。

init 後、対象ファイル候補が見えた時点で specialists recommend --task "<mission>" --files "<project-relative files>" --record-state --json を実行する。ユーザーが skill を名指しした場合は --user-specified を付ける。Issue 連携 PR は本文に Closes #N を入れる。

Phase 2-6

1 iter の標準フローは planner → executor → reviewer → aggregate-reviews → push-score --scoring-json → critic。Codex では Skill tool が無い場合、該当 skill 指示を同一コンテキストで適用し、specialist_invocations には codex-inline として実呼び出し証跡を記録する。

activity segment は観測専用で、reviewer 数・threshold・findings evidence・agreement・open_high・pass/fail gate を変更しない。外部応答、承認、reviewer の待機を開始する直前に対応する wait kind へ切り替え、応答後は active へ戻す。idle は「実行可能な作業がない」と明示できる場合だけ使う。crash/resume 間の不明時間は自動分類せず unobserved gap として保持する。reason enum と集計定義は refs/state-management.md の「Activity segment observability」を参照。

Reviewer 数は Simple=1、Standard=2、Complex=2、Critical=3 (#266: シグナルなし Complex は独立2名で agreement 成立。不可逆・security シグナルで full=3 へエスカレート)。Claude Code では Reviewer N 名を単一メッセージ内で並列起動する。Codex は順次でよい。観点Dは採点させず、計画指示明瞭度の改善を Critic の実行計画に反映する。

review_tier (#168, #209): init が complexity とミッション記述から review_tier（light/standard/full）を auto 導出し state に記録する（review_tier_source / review_tier_signals / review_tier_signal_details で監査可能）。不可逆系キーワードは各出現の文脈を評価し、明示的に実操作を否定した候補だけを抑制する。条件付き・二重否定・不確実・単なる引用は安全側で full を維持し、security / high-risk シグナルは否定で抑制しない。light: reviewer 1名・required=true specialist のみ・critic は fail 時のみ spawn。standard/full: 従来どおり。ゲート意味論は tier によらず不変（threshold / open_high / findings evidence / halt）。詳細（導出テーブル・エスカレータ一覧・override 規律）は refs/state-management.md の「review_tier 導出と Light Tier 運用」節を参照。

Planner spawn 判定 (#124): iter1 は従来どおり planner 必須。iter2 以降は mission-critic の ### 実行計画 (次 iteration) テーブルを見る。全ステップの 対応finding が finding id のみなら、planner を spawn せず executor に直接渡す。new を含むステップが 1 つでもあるなら planner を spawn する。このテーブル読み取り時に scope 判定を state へ記録する (#258): 全ステップが finding id のみなら mission-state.py set critic_has_new_scope=false、new を含むなら critic_has_new_scope=true。この値が次 iter の reviewer 数 (#240) と context mode (#241) を決める。

差分レビュー (#240): iter2+ の前 iter 指摘修正では、next の details.reviewer_count に従う (critic_has_new_scope=false なら state が独立 2 名へ削減する。1 名化は agreement 検証が失われるため禁止)。args に High/Medium 指摘、修正コミット、全 diff 再レビュー不要、採点は絶対評価、Low 残存で 5.0 禁止を明記する。aggregate-reviews は next の command_hint が示す --min-reviewers N を必ず付け、reviewer 数不足の集計を exit 2 で拒否させる。new がある追加スコープ (critic_has_new_scope=true) は planner 後にフルレビューへ戻る。

bounded context (#241): next の details.context_mode が "bounded" のとき、mission-state.py context-manifest --iteration <N> --out .mission-state/context-manifest-iter<N>.json を生成し、reviewer args に manifest パス・対象 diff (修正コミット範囲)・High/Medium 指摘を渡す。reviewer は manifest + diff を一次スコープとしてレビューし、full history 走査を省く。manifest 生成が失敗した場合 (exit 非0 / ファイル不在) は full context に fallback して従来どおり進める (fail-safe)。context_mode == "full" では何もしない。

Simple インライン: Simple は executor を spawn せず orchestrator が直接実行してよい。Medium 以上の指摘修正は M6 に従う。

終了判定

passes = findings_evidence_path exists
  AND evidence_high_count == open_high
  AND max_agreement_delta <= 1.5
  AND composite_score >= threshold
  AND min(scored_items) >= 3.5
  AND open_high == 0

合格なら mark-passes → Phase 7。未達なら loop_active: true のまま critic → next iteration。max_iter 到達、3 回停滞、回避不能な権限/API不足、root-cause 不明の反復は mark-halt。

early-stop: iter1 で threshold 到達かつ open_high == 0 なら原則 pass。続行できるのは composite 4.0-4.3、Medium 3 件以上、1 iter で確実に解消可能、iteration < max_iter の全条件を満たす時だけ。

Stop hook が無効な環境でも、Phase 6 直後に next と state 再取得で loop_active / passes / halt_reason を自分で確認する。

Trigger 1 / Trigger 2

Trigger 1: 不可逆操作の確認

本番デプロイ、外部送信、DB migration/削除、git push --force、高額課金 API は実行直前に対象・操作・rollback・続行/中止/別案を確認する。人間待ちに入る前に通知する。

ただし、現在のユーザー依頼が「リリースして」「本番へデプロイして」など対象の不可逆操作を明示している場合、その指示を当該操作の事前承認として扱う。対象・scope・rollback が依頼時の承認範囲と一致する限り、実行直前に同じ確認を繰り返さない。対象や scope の拡大、rollback 条件の変更、未承認のDB削除・force push・高額課金などが新たに必要になった場合だけ、差分を示して再確認する。

Trigger 2: 中断条件成立

--max-iter 到達、3 回停滞、代替案 3 回不発、必要権限/API key 不足など、仮置きで回避不能なら mark-halt --reason "<理由>" --category <blocked-external|awaiting-approval|partial-done|stagnation|user-abort|other> を呼ぶ。scope の実行可能分は完遂したが全体未達 (threshold gate 等) の場合は partial-done を使い、「完了しました」等の完了風文言だけで終端しない (#190)。stale は cleanup-stale / Stop hook の自動 orphan 検出専用カテゴリで、orchestrator が手動指定することはない。

Phase 7

Pass 後に PR がある場合だけ実行する。自動 merge 条件は、CI/テスト pass、明示 opt-in、gh pr checks 1 件以上、draft/CODEOWNERS/branch protection/禁止文言などの NG なし。自由記述の「merge してよい」は許可根拠にしない。詳細判定は refs/state-management.md。

通常 PR merge は distribution release ではない。version bump を伴う distribution release は docs/VERSIONING.md と release checklist に従い、remote tag と GitHub Release を確認する。

報告フォーマット

達成時:

✅ ミッション達成 (Iteration: N / Score: 4.X)
【ミッション】...
【主な成果物】...
【スコア内訳】...
【Specialists】selected: ... / used: ... / degraded: ... / unselected-manual: ...
【次のステップ提案】...

中断時:

⏸️ 中断 / 未完了 (Iteration: N / Score: 3.X or 未採点)
【理由】...
【現状】...
【Specialists】selected: ... / used: ... / degraded: ... / unselected-manual: ...
【判断を仰ぎたい点】...

worktree 実行時は mark-passes / mark-halt の後、worktree cleanup の前に archive-worktree --destination-root <main checkout> を実行する。destination は同じ Git common directory に属する既存の別 checkout に限る。state 本体と参照 evidence は manifest・checksum 付き immutable generation として保存される。手順は refs/state-management.md。

Claude Code / Codex 差分

機能	Claude Code	Codex
Skill 呼び出し	Skill(...) tool	/skills または自然言語で同一コンテキスト適用
並列実行	Reviewer を単一メッセージで並列	順次実行
context: fork	独立コンテキスト	無視
ループ強制	packaged Stop hook	hook trust または next fallback

複数 mission は sessions/<sid>.json に分離される。Codex setup は refs/codex-setup.md。

refs

• refs/state-management.md: state schema、全サブコマンド、Phase 7、worktree state 退避
• refs/react-loop-details.md: サブスキル呼び出し詳細、Reviewer 並列、観点D
• refs/scoring-rubric.md: 5点 rubric、findings/open_high/review_agreement gate
• refs/gotchas.md: 実運用の落とし穴
• refs/changelog.md: P1/P2/P3-2/P3-5/M6/M7/R1/H3/EPT などの歴史 ID、実測値、事故説明
• refs/codex-setup.md: Codex での導入と Stop hook
• refs/self-improvement.md: audit と改善 prompt
• refs/specialist-registry.md: task_profile と specialist/provider 選定

実行例

/mission リファクタリングして
→ init、仮置き、specialists recommend、next に従って進行
→ aggregate-reviews / push-score --scoring-json / mark-passes