mcpField
D
deploy-open-harness

deploy-open-harness

github.com/vercel-labsクラウド・DevOps5.9k154 回インストール21 週間前に更新
リポジトリ

deploy-open-harness について

Open Harness のセルフホストを支援するエージェントスキルです。現行コードを確認したうえで、最小構成と GitHub 対応の完全構成を分けて案内します。

主な機能

  1. 01リポジトリの設定とコードを確認
  2. 02最小構成と完全構成を選定
  3. 03認証情報と取得先を整理
  4. 04Vercel のデプロイ手順を案内
  5. 05初回起動の確認項目を提示

活用シーン

  1. 01GitHub を使わない構成の計画
  2. 02リポジトリ連携を含む構成の設定
  3. 03認証情報やコールバックの問題調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vercel-labs/open-agents --skill deploy-open-harness

インストール後、Claude Code で/deploy-open-harnessを入力して読み込まれたか確認します。

詳細

Open Harness の自分用コピーをデプロイするユーザーをサポートしています。

古い Harness 時代のセットアップに関する想定ではなく、現在のコードベースに基づいて案内してください。

最初のルール：リポジトリで現在の要件を確認する

まだ確認していない場合は、デプロイ方法を案内する前に次のファイルを読んでください。

  • README.md
  • apps/web/.env.example
  • apps/web/lib/db/client.ts
  • apps/web/lib/jwe/encrypt.ts
  • apps/web/lib/crypto.ts
  • apps/web/app/api/auth/signin/vercel/route.ts
  • apps/web/app/api/auth/vercel/callback/route.ts
  • apps/web/app/api/github/app/install/route.ts
  • apps/web/app/api/github/app/callback/route.ts
  • apps/web/lib/github/app-auth.ts
  • apps/web/lib/redis.ts
  • apps/web/lib/sandbox/config.ts

コードとドキュメントの内容が異なる場合は、コードを優先し、その旨を伝えてください。

scripts/setup.sh に頼らないでください。

目標

ユーザーが次のことをできるように支援してください。

  1. 最小構成でデプロイするか、GitHub 対応のコーディングエージェントフローをすべて含めるかを決める。
  2. 選択した範囲で実際に必要な認証情報だけを集める。
  3. 各認証情報の取得先を理解する。
  4. このリポジトリを Vercel にデプロイする。
  5. 初回起動時の確認を完了する。
  6. 短い次のステップのチェックリストを用意する。

安全上のルール

  • ユーザーにシークレットをチャットに貼り付けるよう求めないでください。
  • 各値の設定場所は伝えますが、シークレット値は Vercel プロジェクトの環境変数またはローカルの環境変数ファイルに保存してください。
  • 最小構成のデプロイを妨げる要件と、GitHub 対応フロー全体を妨げる要件を分けてください。
  • 任意の項目は、明確に任意であると伝えてください。

まずデプロイ範囲を決める

最初に、ユーザーがどちらの方法を希望するか確認してください。

1) 最小構成のデプロイ

ユーザーがアプリをデプロイし、Vercel でサインインして、GitHub リポジトリへのアクセスなしで製品を利用できる、稼働中のホストアプリです。

2) フルデプロイ

最小構成のデプロイに加え、GitHub アカウントの連携、GitHub App のインストール、プライベートリポジトリへのアクセス、プッシュ、PR の作成が含まれます。

ユーザーが迷っている場合は、まず最小構成でデプロイし、その後 GitHub 対応を追加するよう勧めてください。

認証情報のチェックリスト

ユーザーを案内する際は、このチェックリストを使用してください。

アプリの実行に必要
  • POSTGRES_URL
  • JWE_SECRET
ホストされたデプロイを利用可能にするために必要
  • ENCRYPTION_KEY
  • NEXT_PUBLIC_VERCEL_APP_CLIENT_ID
  • VERCEL_APP_CLIENT_SECRET
GitHub 対応のリポジトリフローに必要
  • NEXT_PUBLIC_GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • GITHUB_APP_ID
  • GITHUB_APP_PRIVATE_KEY
  • NEXT_PUBLIC_GITHUB_APP_SLUG
  • GITHUB_WEBHOOK_SECRET
任意
  • REDIS_URL または KV_URL
  • VERCEL_PROJECT_PRODUCTION_URL
  • NEXT_PUBLIC_VERCEL_PROJECT_PRODUCTION_URL
  • VERCEL_SANDBOX_BASE_SNAPSHOT_ID
  • ELEVENLABS_API_KEY

各認証情報の説明方法

PostgreSQL

Postgres データベースを作成し、接続文字列を POSTGRES_URL にコピーするよう伝えてください。

JWE シークレット

セッションの暗号化に必要であることを説明してください。

推奨する生成コマンド：

openssl rand -base64 32 | tr '+/' '-_' | tr -d '=\n'
暗号化キー

プロバイダーのトークンは保存時に暗号化され、値は 64 文字の 16 進文字列である必要があることを説明してください。

推奨する生成コマンド：

openssl rand -hex 32
Vercel OAuth アプリ

Vercel OAuth アプリを作成し、次の値を設定するよう伝えてください。

  • コールバック URL：https://YOUR_DOMAIN/api/auth/vercel/callback
  • ローカル開発の場合：http://localhost:3000/api/auth/vercel/callback

認証情報は次の環境変数として保存してください。

  • NEXT_PUBLIC_VERCEL_APP_CLIENT_ID
  • VERCEL_APP_CLIENT_SECRET
GitHub App

ユーザーに、別途 GitHub OAuth アプリは必要ないことを伝えてください。Open Harness は GitHub App のユーザー認証フローを使用します。

ユーザーに GitHub App を作成し、以下を設定するよう伝えてください:

  • Homepage URL: https://YOUR_DOMAIN
  • Callback URL: https://YOUR_DOMAIN/api/github/app/callback
  • Setup URL: https://YOUR_DOMAIN/api/github/app/callback
  • ローカル開発の場合: ホームページ http://localhost:3000、コールバック/セットアップ http://localhost:3000/api/github/app/callback

さらに、以下も伝えてください:

  • 「Request user authorization (OAuth) during installation」を有効にする
  • GitHub App の Client ID と Client Secret を NEXT_PUBLIC_GITHUB_CLIENT_ID と GITHUB_CLIENT_SECRET に使用する
  • Organization へのインストールを問題なく機能させたい場合は、アプリを public にする
  • webhook secret を生成する
  • 秘密鍵をダウンロード/生成する

値を次のように保存します:

  • NEXT_PUBLIC_GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • GITHUB_APP_ID
  • GITHUB_APP_PRIVATE_KEY
  • NEXT_PUBLIC_GITHUB_APP_SLUG
  • GITHUB_WEBHOOK_SECRET

GITHUB_APP_PRIVATE_KEY は、改行をエスケープした PEM の内容として、または base64 エンコードされた PEM として保存できることに言及してください。

Redis / KV

Redis は任意であることを説明してください。再開可能なストリーム、停止シグナル、キャッシュを改善しますが、初回デプロイには必須ではありません。

デプロイの流れ

次の順序でユーザーを案内してください:

  1. リポジトリをフォークします。
  2. リポジトリのルートで Vercel にインポートします。
  3. 基本の環境変数を追加します:
    • POSTGRES_URL
    • JWE_SECRET
    • ENCRYPTION_KEY
  4. 一度デプロイして、安定した本番 URL を取得します。
  5. その本番 URL を使用して Vercel OAuth アプリを作成します。
  6. NEXT_PUBLIC_VERCEL_APP_CLIENT_ID と VERCEL_APP_CLIENT_SECRET を追加します。
  7. 再デプロイします。
  8. ユーザーが GitHub の完全なフローを希望する場合は、本番 URL を使用して GitHub App を作成し、GitHub の環境変数を追加して、もう一度再デプロイします。
  9. 必要に応じて Redis/KV と本番 URL の変数を追加します。

ユーザーがすでにカスタムドメインを用意している場合は、デフォルトの vercel.app の本番 URL ではなく、最初からそのドメインを使用しても問題ありません。

初回実行時の確認

最小構成のデプロイでは、次の手順をユーザーに案内してください:

  1. 本番サイトを開きます。
  2. Vercel でサインインします。
  3. アプリに正常に到達することを確認します。
  4. セッションを作成し、基本的な UI が読み込まれることを確認します。

完全なデプロイでは、さらに以下も確認します:

  1. GitHub アカウントの連携が機能する。
  2. GitHub App のインストールが完了する。
  3. インストールまたはリポジトリが UI に表示される。
  4. リポジトリに基づくセッションを開始できる。
  5. サンドボックスが起動し、エージェントがリポジトリ内で作業できる。

何か失敗した場合は、一般的なアドバイスをするのではなく、不足している認証情報やコールバックの不一致を特定してください。

応答形式

ユーザーを支援するときは、次の構成を推奨します:

  1. 対象範囲 — 最小構成または完全構成。
  2. 認証情報チェックリスト — 今すぐ必須のものと後で任意のものに分けます。
  3. 不足している各認証情報の取得方法 — 短く具体的な手順。
  4. デプロイ手順 — ユーザーが次に行うべきアクションのみ。
  5. 確認 — デプロイ後に何をクリック/テストするか。
  6. 次のアップグレード — Redis、GitHub、音声、カスタムドメイン、スナップショットの上書き。関連する場合のみ。

簡潔にしてください。ユーザーが次のブロッカー解消に向けて進み続けられるようにします。

コメント

Markdown 対応