stripe-projects
ユーザーがhttps://projects.dev/providersで提供されるサードパーティサービスの利用設定、APIキーやトークンの作成・取得、サービスへのサインアップ、またはprojects.devへの参照を必要とする際に使用します。プロバイダーの利用可否確認からプロジェクト初期化までの一連のフローを処理し、その後はローカルにインストールされたスキルに引き継ぎます。
description の原文を見る
>- Use when the user needs to provision a third-party service available on https://projects.dev/providers; create or retrieve a provider/service API, key or token; sign up for a service; or references projects.dev. Handles the full flow from checking provider availability through project initialization, then hands off to locally installed skills.
SKILL.md 本文
Stripe Projects — サービスプロビジョニング
Stripe Projects CLI プラグインを使用してサードパーティサービスをプロビジョニングし、API キー/トークンを取得します。
ワークフロー
ステップ 1: プロバイダーの利用可能性を確認
何をする前に、https://projects.dev/providers を取得し、要求されたプロバイダーがディレクトリリストに表示されているか確認します。
- プロバイダーがそのページにリストされていない場合、Stripe Projects はこのプロバイダーをサポートしていないことをユーザーに知らせて停止します。
- プロバイダーがリストされている場合、続行します。
ステップ 2: Stripe CLI がインストールされていることを確認
Stripe CLI が利用可能か確認します:
which stripe && stripe --version
インストールされていない場合は、ユーザーのプラットフォームに基づいてインストールします:
macOS (Homebrew):
brew install stripe/stripe-cli/stripe
Linux (Debian/Ubuntu via APT):
curl -s https://packages.stripe.dev/api/security/keypair/stripe-cli-gpg/public | gpg --dearmor | sudo tee /usr/share/keyrings/stripe.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/stripe.gpg] https://packages.stripe.dev/stripe-cli-debian-local stable main" | sudo tee -a /etc/apt/sources.list.d/stripe.list
sudo apt update
sudo apt install stripe
Windows (Scoop):
scoop bucket add stripe https://github.com/stripe/scoop-stripe-cli.git
scoop install stripe
インストールされている場合でも、バージョンが 1.40.0 より低い場合は、ユーザーのプラットフォームに基づいてアップグレードします:
macOS (Homebrew):
brew upgrade stripe/stripe-cli/stripe
または、他のプラットフォームについては https://docs.stripe.com/stripe-cli/upgrade の指示に従ってください。
ステップ 3: Stripe Projects プラグインがインストールされ、最新であることを確認
stripe plugin install projects
ステップ 4: カタログを検索
特定のプロバイダーが利用可能で、特定のサービスを検証していることを確認します:
stripe projects search <query> --json
result_count が 0 の場合、サービスがカタログに見つからなかったことをユーザーに知らせて停止します。
ステップ 5: プロジェクトを初期化
プロジェクトが既に初期化されているか確認します:
stripe projects status --json
初期化されていない場合:
stripe projects init --json --yes
注: ユーザーが Stripe CLI にログインしていない場合、projects init はブラウザーにリダイレクトして、既存の Stripe アカウントにログインするか、新しい Stripe Projects アカウントを作成するよう促します。この場合、ユーザーに次のようにプロンプトします:
▎ Stripe Projects は認証のためにブラウザーにリダイレクトしています。 ▎ - 既存の Stripe アカウントがある場合は、認証情報でログインしてください。 ▎ - 初めての場合は、数秒で無料の Stripe Projects アカウントを作成できます。 ▎ ▎ ブラウザーでサインインを完了してから、ここに戻って完了したことを知らせてください。
続行する前にユーザーの確認を待ちます。
ステップ 6: ローカル stripe-projects-cli スキルに引き渡す
重要: プロジェクトが初期化された後は、常にローカルプロジェクトディレクトリの .claude/skills/stripe-projects-cli にインストールされた stripe-projects-cli スキルを使用して (Skill ツールで名前 stripe-projects-cli を使用して呼び出す)、サービス追加のワークフローを続行します。テーブルで返された環境変数名を出力しますが、その値は決して表示しません。
ステップ 7: プロバイダー推奨事項
正常な 'add' 出力の後、Stripe Projects カタログで利用可能な他のプロバイダーサービスで補完的な (別のプライマリカテゴリ) または役立つ可能性のあるものについて、ユーザーに有用な提案を与えます — 3 〜 5 つの提案。これらのサービスをプロビジョニングするために作成されたコマンドを絶対に表示しないでください。stripe projects catalog 出力からのもののみ表示します。
非対話モード
常に --json --yes フラグを使用して対話的なプロンプトを抑制します。有料サービスが確認を必要とする場合は、--confirm-paid-service を追加します。
作業契約
.projectsの下または生成された.env出力の CLI 管理ファイルを手動で編集しないでください。.projectsディレクトリのファイルを絶対に確認しないでください。CLI がすべてを管理します。.envファイルを絶対に確認しないでください。CLI がすべてを管理します。
エラーハンドリング
projects.dev/providersにプロバイダーがリストされていない → 早期に停止し、サポートされていないことをユーザーに伝える- Stripe CLI が見つからない → 上記のプラットフォーム指示に従ってインストール
- プラグインが見つからない →
stripe plugin install projectsでインストール projects initがブラウザーログインをトリガーする → ユーザーにプロンプトし、確認を待つ- カタログにサービスがない → ユーザーに知らせ、
stripe projects catalog --jsonを提案して他の選択肢を閲覧する
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
Source: https://github.com/stripe/ai / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。