mcpField
C
chrome-webstore-release-blueprint

chrome-webstore-release-blueprint

github.com/brianlovinクラウド・DevOps3792.8k 回インストール31 週間前に更新
リポジトリ

chrome-webstore-release-blueprint について

Chrome Web Store Release Blueprintは、Chrome Web Storeのリリース自動化を設定するためのガイド付きスキルです。ダッシュボードとOAuthの手順を案内し、認証情報の扱いをユーザー確認に委ねながら、リポジトリ用スクリプト、CIワークフロー、提出状況の確認方法を示します。

主な機能

  1. 01Chrome Web StoreとOAuthの設定を案内
  2. 02リポジトリのリリーススクリプトとCIワークフローを設計
  3. 03ghによるGitHubシークレット設定に対応
  4. 04提出と公開の状態を確認
  5. 05バージョン確認と公開状態の処理

活用シーン

  1. 01Chrome Web Storeのリリース自動化を設定
  2. 02認証情報をコミットせずCIシークレットを準備
  3. 03バージョンに変更がない場合は公開をスキップ
  4. 04審査待ちの提出があるか確認

インストール

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

$npx skills add https://github.com/brianlovin/agent-config --skill chrome-webstore-release-blueprint

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

詳細

Chrome Web Store リリースの手順ガイド

このスキルは、実際に作業しながら設定を進めるためのガイドです。エージェントはユーザーを一つずつ手順に沿って案内し、確認を求め、ローカルまたは CI で実行できる部分のみを自動化してください。

このスキルの用途

  • Chrome Web Store のリリース自動化を一から設定するユーザーを支援します。
  • Google／CWS ダッシュボードで行う手順を明確に案内します。
  • ユーザーから認証情報を受け取った後、リポジトリ側のスクリプト／ワークフローを実装します。
  • 送信状態（PUBLISHED、PENDING_REVIEW など）を確認します。

エージェントの動作ルール

  • ダッシュボード／OAuth の作業はユーザーが行うものとして扱い、エージェントが実行したかのように示してはいけません。
  • 一度に一つの手順を案内し、次に進む前に確認を待ってください。
  • 必要な場合に限り具体的な値を尋ね、それぞれの値の取得元を伝えてください。
  • ログではシークレットをマスキングし、シークレットの値を git にコミットしないでください。
  • gh が利用可能な場合はシークレットのアップロード自動化を提案してください。利用できない場合は手動での代替手順を提示してください。

Step 1: プロジェクトの確認（認証情報を扱う前）

次の情報を収集してください。

  • 拡張機能のバージョンが記載されたマニフェストのパス
  • ビルドコマンド
  • zip／パッケージ化コマンドと出力ファイル名／パス
  • CI プラットフォーム（デフォルトは GitHub Actions）
  • リリースブランチのポリシー（main、タグ、または手動ディスパッチ）
  • ローカルのシークレットファイルの規約（.env、.env.local など）

明示的に確認してください。

  • 「バージョンが変更された場合にのみ、CI から公開しますか？」
  • 「gh を使って GitHub シークレットのアップロードを設定しますか？」

Step 2: 認証情報の詳細な設定手順（ユーザー + エージェント）

2.1 Google Cloud で API を有効にする

ユーザーに次のページを開くよう案内してください。

  • https://console.cloud.google.com/apis/library/chromewebstore.googleapis.com

ユーザーの操作：

  1. 対象の Google Cloud プロジェクトを選択します。
  2. Chrome Web Store API の Enable をクリックします。

エージェントからの案内例：

  • 「Chrome Web Store API が有効と表示されたら、OAuth の設定に進みますのでお知らせください。」
2.2 OAuth 同意画面を設定する

ユーザーに次のいずれかのページを開くよう案内してください。

  • https://console.cloud.google.com/apis/credentials/consent
  • UI のリダイレクトが発生した場合は、Google Auth Platform の同意画面ページで続行してください。

ユーザーの操作：

  1. External のユーザータイプを選択します（Workspace 内部アプリではない場合）。
  2. アプリ名、サポート用メールアドレス、開発者連絡先メールアドレスを入力します。
  3. カスタムスコープが必要でない限り、保存してスコープの手順を続行します。
  4. アプリが Testing モードの場合は、自分の Google アカウントをテストユーザーとして追加します。
  5. 保存します。

エージェントからの案内：

  • ユーザーが安定した長期利用可能なリフレッシュトークンを必要とする場合は、準備ができた時点で同意画面を Production に移行することを勧めてください。
2.3 OAuth クライアントを作成する

ユーザーに次のページを開くよう案内してください。

  • https://console.cloud.google.com/apis/credentials

ユーザーの操作：

  1. Create Credentials -> OAuth client ID をクリックします。
  2. アプリケーションの種類として Web application を選択します。
  3. 次の認証済みリダイレクト URI を正確に追加します。
  • https://developers.google.com/oauthplayground
  1. クライアントを作成します。

次の値を取得します。

  • CWS_CLIENT_ID
  • CWS_CLIENT_SECRET

エージェントからの案内例：

  • 「準備ができたら CWS_CLIENT_ID と CWS_CLIENT_SECRET を貼り付けてください。これらはシークレットとして扱います。」
2.4 リフレッシュトークンを生成する（OAuth Playground）

ユーザーに次のページを開くよう案内してください。

  • https://developers.google.com/oauthplayground/

ユーザーの操作：

  1. 設定の歯車アイコンをクリックします。
  2. Use your own OAuth credentials を有効にします。
  3. CWS_CLIENT_ID と CWS_CLIENT_SECRET を貼り付けます。
  4. Step 1 で、次のスコープを入力します。
  • https://www.googleapis.com/auth/chromewebstore
  1. Authorize APIs をクリックします。
  2. 拡張機能を所有／公開しているのと同じ Google アカウントでログインします。
  3. Exchange authorization code for tokens をクリックします。
  4. リフレッシュトークンをコピーします。

次の値を取得します。

  • CWS_REFRESH_TOKEN

エージェントからの案内例：

  • 「CWS_REFRESH_TOKEN を貼り付けてください。ローカルのシークレットストレージ／CI シークレットにのみ保存します。」
2.5 ストア ID を取得する

次の値を取得します。

  • CWS_EXTENSION_ID（ストア／デベロッパーの掲載ページ URL に含まれる拡張機能アイテム ID）
  • CWS_PUBLISHER_ID（Chrome Web Store デベロッパーアカウントのコンテキストにあるデベロッパー／パブリッシャー ID）

エージェントからの指示：

  • ユーザーが不明な場合は、Chrome Web Store Developer Dashboard を開き、アイテム／アカウントの URL またはアカウント詳細から ID をコピーするよう案内してください。
2.6 認証情報チェックリスト

次の5つがすべて揃うまで、先に進まないでください。

  • CWS_CLIENT_ID
  • CWS_CLIENT_SECRET
  • CWS_REFRESH_TOKEN
  • CWS_PUBLISHER_ID
  • CWS_EXTENSION_ID

ステップ 3：ローカルのシークレットファイルと CI シークレットの設定

実際の値をコミットしないローカルのテンプレートファイルを作成します。

CWS_CLIENT_ID=
CWS_CLIENT_SECRET=
CWS_REFRESH_TOKEN=
CWS_PUBLISHER_ID=
CWS_EXTENSION_ID=

実際のシークレットファイルのパスが gitignore に登録されていることを確認してください。

GitHub Actions を使う場合は、gh による自動化が必要かユーザーに確認してください。

必要な場合は、次のコマンドを確認します。

gh --version
gh auth status

gh の認証が設定されていない場合は、次を実行するようユーザーに伝えてください。

  • gh auth login

次に、以下の機能を備えたヘルパースクリプトを実装します。

  • ローカルの環境変数ファイルからシークレット値を読み取る
  • 必須のキーがすべて揃っていることを検証する
  • --dry-run に対応する
  • dry-run の出力では値をマスクする
  • gh secret set ... --repo ... を使ってアップロードする
  • 必須のキーまたは認証が不足している場合は、すぐに失敗する

ユーザーが gh を使わない場合は、リポジトリ設定でシークレットを手動入力するためのチェックリストを提示してください。

ステップ 4：リリースワークフローの設計図（バージョンをトリガーにする）

次のロジックを中心に CI ワークフローを設計します。

  1. ローカルのマニフェストのバージョンを読み取ります。
  2. 必要に応じて別のバージョンファイルと比較し、一致しない場合は失敗させます。
  3. リフレッシュトークンをアクセストークンと交換します。
  • POST https://oauth2.googleapis.com/token
  1. CWS のステータスを取得します。
  • GET https://chromewebstore.googleapis.com/v2/publishers/<publisherId>/items/<extensionId>:fetchStatus
  1. 現在公開されているバージョンを次から抽出します。
  • publishedItemRevisionStatus.distributionChannels[0].crxVersion
  1. ローカルのバージョンと公開済みバージョンが一致する場合は、公開をスキップします。
  2. バージョンが変わっている場合は、次を行います。
  • パッケージの zip をビルドする
  • zip をアップロードする： POST https://chromewebstore.googleapis.com/upload/v2/publishers/<publisherId>/items/<extensionId>:upload
  • 必要に応じてポーリングし、非同期のアップロード状態を処理する
  • 公開する： POST https://chromewebstore.googleapis.com/v2/publishers/<publisherId>/items/<extensionId>:publish

次の公開状態は、送信成功として扱います。

  • PENDING_REVIEW
  • PUBLISHED
  • PUBLISHED_TO_TESTERS
  • STAGED

ステップ 5：送信ステータス確認スクリプトの設計図

「最新の送信状態は何か」を確認する専用スクリプトを作成します。

必須の動作：

  • 環境変数を受け付ける（任意の --env-file も受け付ける）
  • ローカルバージョンとの比較用に、任意で --manifest を受け付ける
  • --json に対応する
  • トークンエンドポイントと fetchStatus を呼び出す
  • 次のフィールドを正規化して出力する：
    • itemId
    • localVersion
    • publishedVersion
    • publishedState
    • submittedVersion
    • submittedState
    • upToDate
    • pendingReview
  • 認証、API、入力のエラー時にはゼロ以外の終了コードを返す

含めると便利なチェック：

  • マニフェストとパッケージのメタデータのバージョン不一致を検出する
  • アップロードされたバージョンが審査待ちで、まだ公開されていないかを表示する
  • --json を使わない場合は、簡潔な概要を出力する

ステップ 6：ガイド付き検証フロー

ユーザーと一緒に次の手順を実行します。

  1. リリース前にステータス確認スクリプトが正常に実行されることを確認します。
  2. すべてのバージョン情報源で、拡張機能のバージョンを（パッチで）上げます。
  3. ブランチをプッシュしてワークフローを起動します。
  4. ワークフローが次のいずれかになることを確認します。
  • スキップする（バージョンに変更がない場合）
  • アップロードして公開を送信する
  1. ステータス確認スクリプトを再実行します。
  • 多くの場合、最初は PENDING_REVIEW になるはずです
  • 後で、公開チャネルのバージョンがローカルバージョンと一致することを確認します

トラブルシューティングスクリプト（エージェントが伝える内容）

  • invalid_grant：
  • リフレッシュトークンの誤りまたは期限切れ、OAuth クライアントの誤り、あるいはアカウントの誤りが考えられます
  • CWS エンドポイントからの 403：
  • アカウントに、その拡張機能の公開者権限がありません
  • ワークフローが何も実行しない：
  • 設計どおり、ローカルバージョンと公開済みバージョンが一致しています
  • アップロードの失敗：
  • API の応答、パッケージ化された zip の構成、マニフェストの有効性を確認してください
  • バージョン不一致ガードの失敗：
  • 公開前に、宣言されているすべてのバージョンファイルの内容を一致させてください

実用的なリンク（ガイド中に共有）

  • Chrome Web Store API の概要： https://developer.chrome.com/docs/webstore/using-api
  • 公開エンドポイント： https://developer.chrome.com/docs/webstore/publish
  • OAuth Playground： https://developers.google.com/oauthplayground/
  • API 有効化ページ： https://console.cloud.google.com/apis/library/chromewebstore.googleapis.com
  • 認証情報ページ： https://console.cloud.google.com/apis/credentials

ガードレール

  • 認証情報をコミットしないでください。
  • ワークフロー YAML にシークレットをハードコードしないでください。
  • バージョンを比較せずに、すべてのプッシュを自動公開しないでください。
  • セットアップ手順は明確にし、手動で行う各ステップでユーザーの確認を得てください。
  • その場限りのコマンドより、繰り返し使えるヘルパースクリプトを優先してください。

コメント

Markdown 対応