MetaCoderMetaCoder ドキュメント
MetaCoder の Harness Engineering パイプライン（/harness）と 4 つの自動化ツールのコマンドリファレンス。本ページの構文・フラグ・既定値は MetaCoder のソースコードと照合済みです。
/harness status）。概要
MetaCoder は大規模システム向けのグラフ・ファースト AI 開発ツールです。コードベースを意味知識グラフに変換し、Harness Engineering——機械検証される品質ゲートを備えた規律ある 10 フェーズパイプライン——を通じて AI 開発を駆動します。2 つのコマンドファミリがあります:
/harness— 規律システム: ロール・ゲート・コンテキスト層・監査証跡を備えた 10 フェーズの状態機械。18 のサブコマンド。- 自動化ツール —
/modernize・/newproject・/systest・/env: 同じ知識グラフの上に構築されたエンドツーエンドのスキル。
インストールと初回実行
Windows / macOS 向けの無料デスクトップ アプリをダウンロードページから入手してください。典型的な初回セッション:
Harness Engineering — コンセプトとパイプライン
Harness Engineering は AI 駆動開発に、固定された順序と、楽観的な自己報告ではなく機械が検証する品質基準を与えます。人間も AI も同じレールを通ります。
10 フェーズパイプライン
各フェーズはそのゲートが合格したときのみ前進します。rollback は 1 フェーズずつ戻ります。
4 つのロール（フェーズごとに自動付与）
| ロール | フェーズ |
|---|---|
pm | requirements / design / deploy-plan / confirm |
tester | test-spec / integration-test |
developer | implementation / performance |
reviewer | code-review / security |
- 機械検証されるゲート — ゲートのチェックは
harness/workflow/gates.yamlで定義されます。正直に落ちる仕組み: 一度も実行されなかった・0 件を返した・ブラウザに到達できなかったテストは赤のままです。 - 3 つのコンテキスト層 — session / phase / on-demand。
/harness contextで管理します。 - 監査証跡 — phase-advance / rollback / gate-run / role-assume は NDJSON として追記されます。
/harness ai-rateは git 履歴から AI 採用率を計測します。
harness/workflow/gates.yaml から取得されます。本ドキュメントの一覧は /harness init が生成する標準テンプレートを反映しています。spec-kit — まず設計し、設計どおりに正確に作る
spec-kit は鍵となるイノベーションです。AI はまず業界標準の設計（プロジェクト憲法と spec.md → plan.md → tasks.md の連鎖）を作り、それに厳密に従って実装します——多すぎず・少なすぎず。これにより、AI のハルシネーションが想像上の範囲外機能を追加することを防ぎます。spec-kit は METACODER_HARNESS_SPEC_MODE が off でないときに有効になります。これは /harness spec を支え、design → test-spec への前進時に tasks.md を自動生成し、横断機能（認証・i18n・AI アシスタント）を第一級タスクへ昇格させて何も埋もれないようにします。
/harness — コマンドリファレンス
3 つのグループに分かれた 18 のサブコマンド。以下のフラグと既定値はソース（src/skills/bundled/harness.ts と _exec レジストリ）から取得しています。
/harness init
効果: harness/{rules,skills,agents,workflow,context}/ と workflow/phases.yaml・gates.yaml を作成。spec-kit が有効なら harness/constitution.md（3 条）と harness/specs/.gitkeep も書き込む。
| フラグ | 既定値 | 説明 |
|---|---|---|
--template TYPE | minimal | minimal, java-spring-enterprise, node-fastapi, python-django, go-microservice, react-nextjs-frontend, cobol-modernization |
--force | false | 既存の harness/ ファイルを確認なしで上書き |
/harness spec
前提: 現在のフェーズが requirements または design であること（フェーズ状態が未設定の場合は自動で requirements に初期化）。requirements では <brief> が必須。
効果: アクティブな feature を解決（必要なら雛形生成）し、harness/inputs.yaml + --inputs から設計入力を読み込み、docs/SPEC_PLAN.md（著述 SOP）を書き込み、AI が spec.md（design では続けて plan.md + data-model.md）を著述、セルフチェック（テンプレートのプレースホルダ、空の横断セクション、未解決の [NEEDS CLARIFICATION]）を実行。--advance 指定かつセルフチェックがクリーンなら、ゲートを実行して次フェーズへ進む。
| フラグ | 既定値 | 説明 |
|---|---|---|
--feature <name> | brief から導出 | feature の表示名 |
--inputs <p1,p2,…> | harness/inputs.yaml | 入力レジストリに追加する設計入力パスの CSV |
--advance | off | セルフチェックがクリーンなら、ゲートを実行して次フェーズへ進む |
--db <dir> | 空 | 設計文書ディレクトリ。spec の前提として記録される実 DB URL は、このフラグではなく DATABASE_URL から取得される。 |
/harness validate
効果: ok・エラー（✗）・警告（⚠）を報告。spec-kit が有効なら、Constitution セクションと横断アーティファクト整合セクションも表示。フラグなし。
/harness lint
効果: 0〜100 のスコアと違反テーブル（severity / file / line / rule / message）を返す。spec-kit が有効なら、constitution-conformance と no-unresolved-clarification が常に実行される。フラグなし。
/harness status
効果: 検出されたテンプレート、必須/任意ファイルの present/missing。spec-kit が有効なら、憲法バージョン・アクティブな feature・未解決の clarification 件数も表示。素の /harness は status に既定。フラグなし。
/harness phase init
| フラグ | 既定値 | 説明 |
|---|---|---|
--phase <id> | requirements | 初期化するフェーズ |
--feature <name> | なし | spec-kit のみ: specs/<NNN-name>/{spec,plan,tasks}.md を雛形生成し、アクティブな feature に設定 |
/harness phase status
効果: spec-kit が有効なら、アクティブな feature・タスク進捗（done/total %）も表示し、requirements では未解決の clarification を表示。フラグなし。
/harness phase advance
効果:（spec-kit, requirements）[NEEDS CLARIFICATION] を対話的に解決。ゲートを実行。前進し、フェーズ既定ロールを再付与。design → test-spec では tasks.md を自動生成。implementation に入る際は、先に /harness implement を使うよう促す。
| フラグ | 既定値 | 説明 |
|---|---|---|
--reason "…" | 空 | 監査理由 |
--no-interactive | off | spec-kit のみ: requirements で clarification が未解決のとき、プロンプトせずブロックする |
/harness phase rollback
効果: 前のフェーズへ戻り、試行カウンタを増やす。フラグ: --reason（監査理由）。
/harness gate
効果: チェックごとの合否テーブルを返す。gate-integration-test は特別で、プログラム的なチェックではなく /systest パイプラインをセッション内で（Claude-in-Chrome MCP を継承して）実行する。
/harness assume
効果: 手動ロールを設定し、ペルソナブロックを CLAUDE.md に書き込み、role-assume 監査エントリを追記する。
/harness role
/harness implement
効果: 次のタスクと受入基準を docs/IMPLEMENT_PLAN.md に集約。AI はタスクごとに必須のセルフチェック（AC 網羅 + 漏れた横断機能のための設計再読）を行いつつ実装し、タスクを done にマークする。モードは権限モードに従う: auto / bypassPermissions → 連続（全タスクを順に実装）。それ以外は単一タスクで停止。フラグなし。
/harness context
show— スナップショットと層ごとのエントリ/トークン数テーブルを表示（永続化なし）。refresh— スナップショットを再構築し、CLAUDE.mdに書き込み、監査エントリを追記。spec-kit では、アクティブな feature の spec/plan/tasks を phase 層に注入する。query <text>— そのテキストに対して on-demand 層を、永続化せず実行する。
/harness approve
/harness drill
| フラグ | 既定値 | 説明 |
|---|---|---|
--skip-gates | false | 全フェーズを通し、構造チェックのみ（ゲート実行をスキップ） |
--from <phaseId> | 既定フェーズ | 開始フェーズ（含む） |
--to <phaseId> | 終端フェーズ | 終了フェーズ（含む） |
/harness ai-rate
効果: AI コミット（author/email が claude|anthropic に一致、または Co-Authored-By: Claude トレーラ）を検出し、コミット単位・行単位の率と著者別テーブルを報告。フラグ: --since <days>（既定 30）。
/harness ci-init
| フラグ | 既定値 | 説明 |
|---|---|---|
--target | github | github | gitlab | both |
--force | false | 既存の CI ファイルを上書き |
自動化ツール
/modernize と /newproject は同じ引数パーサを共有します。/systest は独自のものを持ち、/env はプロンプト駆動（サブコマンド）です。以下のフラグはすべてソースと照合済みです。
/modernize
レガシーコードベースをモダン化——レガシーソース（およびスクリーンショット）を知識グラフで解析し、PRP モジュールへ分解、その後マルチエージェント TDD で開発・テスト・文書化を行い、レガシーツリーには一切触れずに新しい Web アプリを作ります。
| フラグ（ロング / ショート） | 既定値 | 説明 |
|---|---|---|
--workspace / -w | 必須 | レガシーコードのパス（読み取り専用の参照） |
--output / -o | = workspace | モダン化コードの出力先ディレクトリ |
--database / --db | 未設定 | データベース接続 URL |
--design-docs / -d | 未設定 | 要件/設計文書ディレクトリ |
--design-style | 未設定 | 生成 UI のブランド設計言語——デザインスタイルを参照（70+ プリセット、例: stripe, linear.app, notion） |
--backend-lang / --frontend-lang | 未設定 | ターゲットのバックエンド / フロントエンドフレームワーク |
--reference / -r | 未設定 | 参照プロジェクトのパス |
--language / -l | ja | ドキュメントの言語 |
--team | false | 実験的な Agent Teams を有効化 |
-v / --verify | false | Phase 3 の終わりでレビューのため一時停止 |
--env | 未設定 | 名前付きインフラ環境を有効化（URL を自動補完） |
フェーズフロー
- 2 系統グラフアーキテクチャ — 解析/分解用の読み取り専用 legacy グラフと、Phase 4 で育成しゲートクエリで検証する output グラフ。
- スクリーンショット駆動の UI マッピング — 事前選択した最大 10 枚のレガシースクリーンショットをモダンページへ 1:1 でマッピング。
- コントラクト・ファースト —
openapi.yamlを生成し、バックエンドとフロントエンドがズレないようにする。 - PRP + 完了マーカー — モジュールごとに grep で検出でき再実行可能な証跡。
package.jsonが無くても（例: COBOL）技術スタック解決が機能する。
デザインスタイル（--design-style）
--design-style <name> を渡すと、生成されるフロントエンドが既製のブランド設計言語に従います。MetaCoder はオープンソースの awesome-design-md ライブラリから設計仕様（色・タイポグラフィ・余白・コンポーネントパターン）を読み込み、Phase 3〜4 で対応する DESIGN.md を適用します——その結果、モダン UI は無味乾燥ではなく意図のあるものになります。
70+ のブランドプリセットが利用可能です。例: apple, stripe, linear.app, notion, vercel, claude, figma, airbnb, spotify, tesla, shopify, supabase, raycast, nike, uber。
DESIGN.md を含むフォルダ）を見る: github.com/VoltAgent/awesome-design-md。フォルダ名を --design-style の値として使います（例: --design-style stripe）。/newproject
要件文書からグリーンフィールドプロジェクトを構築——ソクラテス式 Q&A で意思決定を確認し、PRP へ分解、その後マルチエージェント TDD でフルスタック Web アプリを開発・テスト・文書化します。
| フラグ | 既定値 | 説明 |
|---|---|---|
--workspace / -w | 必須 | 新規コードの出力ワークスペース |
--design-docs / -d | 未設定 | 要件文書（列挙のみ、正規表現解析はしない） |
--reference / -r | auto | 参照/PoC プロジェクト。省略時は一般的なフォルダから自動検出 |
--database / --db | resolved | 省略時: セッション TiDB（DATABASE_URL）→ なければローカル SQLite |
-v / --verify | false | Phase 3 の終わりで一時停止（ソクラテス式フェーズ自体は対話的） |
フェーズフロー
- ソクラテス式 Phase 1.5 — 7〜15 個の必須質問（アーキテクチャ / ビジネス / UI-UX / 非機能 / MVP）で、コーディング前に言語・認証・DB・デプロイ先・範囲を確定。
- DB 自動解決 — 明示的な
--database> セッション TiDB Cloud > ローカル SQLite。 - 文書は機械解析されない — 列挙のみ。構造化は AI の仕事。参考コードは自動検出され、env スキャフォールドが生成される。
- デザインスタイル —
/modernize同様、--design-style <name>で awesome-design-md の 70+ ブランドプリセットの 1 つを適用（例:--design-style notion）。
/systest
稼働中アプリの自動システム QA——知識グラフを構築し、2 階層のテストケースを生成、その後 API + Chrome-MCP フロントエンド E2E テストを自動修正ループと証跡に基づく自己監査つきで実行します。
| フラグ（ロング / エイリアス / ショート） | 既定値 | 説明 |
|---|---|---|
--workspace / -w | 必須 | テスト対象のプロジェクトワークスペース |
--backend-url / --backend / -b | 未設定 / env から | バックエンドのベース URL → Phase 5B（API テスト）を有効化 |
--frontend-url / --frontend / -f | 未設定 / env から | フロントエンド URL → Phase 5C（E2E）を有効化。無ければ ⇒ 5C をスキップ |
--database / --database-url / --db | 未設定 / env から | データベース URL（ユーザ作成・管理者昇格） |
--env | 未設定 | 名前付き env。欠けている URL スロットを補完（明示フラグが優先） |
--design-docs / -d | 未設定 | 設計文書ディレクトリ |
フェーズフロー
- 2 階層テスト — Layer 1 の CRUD/ハッピーパス、その後 Layer 2 の negative/auth/validation/boundary/role-routing。片方だけの実行は VIOLATION。
- Chrome-MCP 駆動の E2E — 実ブラウザでのナビゲーション/フォーム送信。2xx の POST を証跡として捕捉。Phase 5C のスキップ条件は
--frontend-urlの欠如のみ。 - 正直に落ちる自己監査（6.5） — 証跡ファイルを再読し、対応する証跡のない合格主張は FAIL に格下げ。
- 本番安全性 —
productionとタグ付けされた env は Phase 1 の前に拒否される。
/env
プロンプト駆動のインフラ環境マネージャ——.metacoder/environments.yaml に定義された環境を list・switch・import/export・edit・health-check・diff。シークレット安全性と preview → /apply のガードつき。
| サブコマンド | 説明 |
|---|---|
/env list [--tag TAG] | env 一覧 + アクティブ（素の /env = list） |
/env use NAME [Reason: …] | アクティブ env を切替 |
/env reset | 既定 env へ戻す |
/env import PATH --as NAME | .env をインポート。キーを var/secret に自動分類 |
/env export NAME [--include-secrets] | .env としてエクスポート。フラグがない限りシークレットはマスク |
/env add NAME [extends PARENT] [field=VALUE …] | env を追加（cloud.provider, cloud.region, safety.destructive_ops が必須） |
/env edit NAME [field=VALUE …] | フィールドを浅いマージで更新 |
/env remove NAME | env を削除（依存先について警告） |
/env clone SRC DST [field=VALUE …] | 上書き付きでコピー |
/env set NAME.PATH VALUE | ドットパスで単一フィールドを設定 |
/env doctor [--level basic|standard|full] [--env NAME] [--force] [--offline] | ヘルスチェック（full は --force がない限り production でブロック） |
/env diff A B | extends 解決後の左右並列 diff |
- シークレット安全性 — list/doctor/diff はシークレット値を決して出力せず、
${var:KEY}/${secret:KEY}名のみ表示。インポートではPASSWORD/SECRET/TOKEN/CREDENTIAL/PASS/PWD/KEYを含むキーを secret に、NEXT_PUBLIC_/VITE_PUBLIC_/PUBLIC_プレフィックスを var に分類。 - preview → /apply — すべての変更コマンドは YAML diff を表示し、
/applyと入力するまで何も書き込まない（/cancelで破棄）。 - doctor の 3 レベル —
basic（参照解決）、standard（+ TCP 到達性）、full（+ クラウド CLI の identity。production ガード付き）。--offlineはネットワークチェックをスキップ。 - スキル間ブリッジ —
--envはバックエンド/フロントエンド/データベース URL を/systest・/modernize・/newprojectに供給。本番 env は消費側スキルが実行前に拒否する。
/deploy に属し、/env のものではありません。/env は safety.writes_two_phase_commit を /env diff でフラグ付きフィールドとして表示するだけです。本ドキュメントは MetaCoder Desktop v3.6.22 を反映しています。コマンド構文はソースコードと照合済みです。ゲートの内容はプロジェクトごとに harness/workflow/gates.yaml で定義されます。