mission-command-dev

Claude Code に開発を委任するためのリポジトリテンプレート。 Issue を書くと AI が実装して PR を出し、人間はレビューとマージだけを行う——その運用一式 （品質ゲート・ラベル運用・自動マージ・定期ルーチン・スキル）が最初から組み込まれている。

「Use this template」で新規リポジトリを作れば、その日から Issue 駆動での AI 実装を始められる。 既存プロジェクトには Claude Code プラグインとして mission-command だけを後付けすることもできる （プラグインのみ導入する場合）。

---

何が嬉しいか

• Issue が命令になる: 「① 意図 ② 最終状態 ③ 制約 ④ 受け入れ条件 ⑤ 優先度」の5項目が揃った Issue だけが着手対象になる（不備は自動で差し戻される）。
• 着手からレビュー可能な PR まで無人で進む: 実装・lint・型検査・テスト・簡素化・セキュリティ レビューまで AI がやり切ってから PR を出す。
• 人間の仕事は「読んでマージ」だけ: 最終マージは常に人間の一票（自己マージ禁止をハーネスで 強制）。判断すべき場面だけ status:awaiting-human でエスカレーションが上がる。
• 物理的にサボれない品質ゲート: scripts/gate-*.sh が手元・pre-commit・CI で同一に走る。 「ローカルは通ったのに CI が落ちる」が起きない。

---

動き方（1周の流れ）

flowchart LR
    A["人間が mission Issue を起票<br/>(意図・受け入れ条件を書く)"] --> B["審査ルーチン<br/>命令審査 (5項目チェック)"]
    B -- 不備 --> A
    B -- 合格 --> C["ディスパッチルーチン<br/>AI に着手させる"]
    C --> D["AI が実装<br/>品質ゲート → PR 提出"]
    D --> E["PR レビュールーチン<br/>Opus によるレビュー"]
    E -- 要修正 --> D
    E -- 問題なし --> F["人間がレビュー・マージ<br/>(追認)"]

Loading

図中の「ルーチン」は claude.ai に手動登録して使う任意のアドオンで、未登録でも同じ流れを 人間の手動起動（Claude Code に直接指示）で回せる。紹介と登録手順は docs/routines/ を参照。

人間が握るのは ①意図（Issue を書く） ②制約（ROE） ③追認（マージ判断） の三点だけで、 実装の段取りや手順（How）はすべて AI 側に委ねる。この「委譲は最大化・制約は最小化」という 設計思想が 任務型指揮（Mission Command / Auftragstaktik） で、 なぜこの運用がうまく回るかの理論的な裏付けになっている。

---

クイックスタート

1. 「Use this template」で新規リポジトリを作成する。
2. clone して Claude Code を起動する。 .claude/settings.json と .mcp.json により、 プラグイン・MCP サーバ（serena 等）が自動セットアップされる。
3. /mission-command:init を実行し、質問に答える。 プレースホルダの置換（{{OWNER}}/{{REPO}} 等）から 初回 PR のマージまでを対話的に誘導する（最終マージは人間が行う）。
4. mission Issue（.github/ISSUE_TEMPLATE/mission.yml）を起票して開発を開始する。 起票後は審査ルーチンが命令審査を行い、合格した Issue がディスパッチルーチンで着手される （docs/routines/）。

---

プラグインのみ導入する場合

このリポジトリ自体が Claude Code のプラグインマーケットプレイスでもある。既存プロジェクトに mission-command プラグインだけを追加したい場合は、.claude/settings.json に以下を追記する。

{
  "extraKnownMarketplaces": {
    "mission-command": {
      "source": {
        "source": "github",
        "repo": "Takahito-Kinouchi/mission-command-dev"
      }
    }
  },
  "enabledPlugins": {
    "mission-command@mission-command": true
  }
}

詳細（バージョン固定・アップデート手順・トラブルシュート）は docs/ops/plugin-consumption.md を参照。

---

何が入っているか

機構	内容	場所
品質ゲート	lint・型検査・テスト・link-check 等を scripts/gate-*.sh に集約。三層構成——即動作（スタック非依存で導入直後から動く）／プラガブル（.mc/stack.conf でスタック別ゲートを差し込む）／実装例（examples/stacks/）	scripts/
ラベルステートマシン	status:triage → ready → in-progress → in-review → done 等、Issue の進行状況を機械的に可視化。sync-labels workflow が main マージ時に GitHub 上へ同期	.github/labels.yml
campaign 自動マージ	issue/* → campaign/* の取り込みは GitHub Actions workflow が自動化。campaign/* → main の最終マージは人間の一票を維持	.github/workflows/campaign-automerge.yml
claude.ai ルーチン 4本	命令審査・ディスパッチ・PR レビュー・複雑度リファクタリング起票を定期実行するプロンプト集	docs/routines/
Claude Code スキル 6本	mission-command doctrine・ROE・SOP・サブエージェント駆動実装・初期セットアップ等。プラグインとしても配布	plugins/mission-command/skills/
mc-init オンボーディング	/mission-command:init — プレースホルダ置換から初回 PR のマージまでを対話で誘導	plugins/mission-command/skills/mc-init/
ROE / SOP / PLAN 文書体系	人間が握る制約・AI 側の標準手順・要件定義（記入式）を分離して管理	docs/

---

ドキュメント構成

文書	役割
docs/mission-command.md	理論リファレンス（なぜこの運用が成立するか）
docs/PLAN.md	要件定義・技術スタック・開発手法（正。記入式テンプレート）
docs/ROE.md	人間が握る制約（越えてはならない線・不可逆操作リスト）
docs/SOP.md	AI 側の標準手順（品質ゲート・ラベルのステートマシン等）
docs/routines/	claude.ai ルーチンのプロンプト本体（4本・任意）

矛盾する場合は docs/PLAN.md が正。CLAUDE.md はこれらへの導線としてのサマリを持つ。

---

前提・注意

• Claude Code の利用を前提とする。
• claude.ai ルーチンの登録は人間が手動で行う（GitHub のイシューイベントや API による自動起動はしない）。
• self-hosted runner の運用は任意（docs/ops/ を参照）。

---

ライセンス

MIT License（Copyright (c) 2026 kinotilus）。ただし一部ディレクトリは サードパーティ由来の帰属表示を維持している。詳細は NOTICE.md を参照。