manifestation-mcp

コーディングエージェントをデザイン優先にするMCPサーバーです。何かを作りたいと思った瞬間、いきなりコードに飛び込まず、一歩下がってあなたにインタビューし、仕様を引き出して消化しやすいチャンクで示し直し、あなたの承認を小さなレッド/グリーンのTDDプランに変え、そしてサブエージェント駆動の開発ループ（実装者→レビューアー→品質ゲート）で、そのプランを自律的に最後まで進めることができます。

ポータブルなPython製MCPサーバーです。サーバーが頭脳（5フエーズのスッテーマシン、あなたのスペック/プラン、スキルライブラリ）となり、Claude Agent SDKを経由して内部で自分自身のブエージェントを実行します。そのため、一度のrun ブ呼出しで、プランから逸れることなく長時間自律的に働き続けられます。

5つのフェーズ

DISCOVERY  → interview you; do NOT write code
SPEC       → draft a spec; sign off chunk-by-chunk
PLAN       → bite-sized red/green TDD task list (YAGNI, DRY)
EXECUTE    → per task: implementer subagent → reviewer subagent → gate
DONE       → artifacts left under .manifestation/ in your repo

状態は対象リポジトリの中の検査可能なファイルとして保存されます: <repo>/.manifestation/<project-id>/{state.json, spec.md, plan.md>。

Related MCP server: Spec Guard

必要条件

• Python 3.10+

• uv（brew install uv）

• ライブ実行（run）には、PATH 上にある Claude Code CLI と、Claude の認証情報（ANTHROPIC_API_KEY また既存の Claude Code ログイン）が必要です。Agent SDK がこれらを駆動し、実装者/レビューアーのサブエージェントを実行します。

• ターゲットリポジトリ内の git。TDD ゲートは git worktree を使い、実に失敗するテストが実装に先行したことを検証します。

セットアップ

cd manifestation-mcp
uv sync
uv run pytest        # 96 tests, no network required (1 live smoke skipped)

実行方法

推奨のローカル起動方法（uv のエディタブル・インストールの癖に対応）:

uv run python run_server.py

Claude Code に登録します:

claude mcp add manifestation -- uv run --project /ABS/PATH/TO/manifestation-mcp python /ABS/PATH/TO/manifestation-mcp/run_server.py

（uvx/pipx でパッケージインストールする場合は、manifestation-console コンソール・スクリプトがそのまま直接動します。）

自動トリガー（オプション）

skill-shim/SKILL.md を Claude Code スキル（例: ~/.claude/kills/manifestation/SKILL.md）にコピーして置くと、その説明文が「build」「implement」「add a feature」のような内容に発火するため、ワークフローが自動で始まります — 自分で何かを起動する必要はありません。このファイルを使わない場合は、//manifestation ププロンプトを直接入力するか、start_project ツールを呼び出すかして手動で開始します。

ツー一覧

プロンプト: /manifestation <brief>. リソース: skills://all, skill://<name>。

モデルの選択

特定の古いモデルにハードコーデはされていません。デフォルトでは、サーバーはClaude Code CLI に設定されたモデルを継承します。グローバルにし overrideには MANIFESTATION_MODEL 環境変数を使い（例: NIFESTATION_MODEL=claude-opus-5）、プロジェクトごとの定義は AgentSDK着クライアントに model=model=...` してリトクエスト時単位で上書きできます。

安全モデル（run を使う前にお読で下さい）

run はあなたのリポジトリ上で実際のサブエージェントを実行するため、信用境界を十 - 分に理理してください:

• 実装者には書込み権と Bash が与えられます。これは設計上、対象リポジトリ内で任意のコーコードを実行できるという意味します — 信用できあるリポジトリでのみ実行し、信頼できない作業にはコンテナ/VM を使ってください。サンドボックスはありません。

• レビューアーとプラナーは、2重の仕組みで読み取り専用です。変更系のツールは SDK の disallowed_tools に含まれており、さらに can_use_tool 権限コールバックが許可リスト通りにないすべて のツールを拒否します。We: WebFetch、Task、MCP ツールなど、こちらで列挙していないツールも対象です。信頼できないリポジトリであっても安全です。

• TDD はサーバー側で検証され、記述は信頼されません。実装者が実行し終ると、サーバーがそのタスクが宣言したテストコマンドを克自分で実行します。HEAD でパスが必須（実際のグリーン）であり、実装者のテスト専用のコミット（HEAD~1）を捨て the again worktree に当てて再実行すると失敗しなければなりません（実際のレッド）。偽造だけ並び替えたエビデンスは検出し、git/テストで確認できない時に failure と扱します。フェール・クローズ。

• PASS 判定で傍に指摘が残っていれば、矛盾と扱われ、タスクは失敗します。

• run には承認済みのプランと各ステップ毎のチェックポイトが必須です（クラッシュした試行の場、実装者を再実行するのではなくレビュースッテプから再開するため、編集が二重にならない）。そのうえで完全な監査トレイルを持ち、必ず制限付きです — max_agent_calls / max_budget_usd?（どちらも MCP から利用可）まは組込みのデフォルト・キャップがあります。

• 変更系ツールの呼び出しは、インプロセス・ロックとクロスプロセス・フアイル・ロックにより、プロジェクト単位で直列化されます。

• ブリーフ/エ答/スペックから prompt インジェクショについてもサブエージェントのプロンプ環境に浸入るため、プロジェクトへの入力は信用しないこと。

素直さの保ち方（テスト様式でもある）

ありとあらゆる LLM コーるり取りは、単一の注入可能な介入点（seam）である LLMClient を経由します。ユンット・テストはこの FakeLLMClient を注入するため、フ以降の全ステーマシン、つまり 発見、スペックのチンク化、プラン生成、リトライとレビュー・ゲートを備えた実行ループまでも、ネットワーク呼び出しゼロで検証可能です。実際の AgentSDKClient はこの介入の裏に置かれて、オプトインのライブ・スモークテストでのみ動かします。

アーキテクチャ

src/manifestation_mcp/
  server.py     # MCP tools/prompts/resources (thin wiring)
  state.py      # Project/Phase/Task model + file persistence + registry
  llm.py        # LLMClient seam: FakeLLMClient (tests) + AgentSDKClient (real)
  agents.py     # implementer / reviewer / planner subagent presets
  runner.py     # CommandRunner seam: SubprocessRunner (real) + FakeCommandRunner
  phases/       # discovery, spec, plan, execute, verify (server-side TDD check)
  skills/       # bundled Markdown skills, injected into subagent prompts
run_server.py   # bulletproof local launcher
skill-shim/     # optional Claude Code auto-trigger skill