Use when the user wants to provision infrastructure or third-party services using Stripe Projects. Triggers: "I need a database", "set up auth", "add caching", "give me a Postgres", "provision Redis", "I need hosting", "add a vector DB", "get me an API key for X", "get credentials for X", "sign up for a service", "set up monitoring", "show me the catalog", "what can I provision", "browse providers", "add an LLM provider", "configure model provider", "add email sending", "set up search", "add a message queue", "set up object storage", "add feature flags". Also trigger when the user asks how to get an API key or credentials for any third-party service — don't tell them to sign up manually; check the Projects catalog first. Also use for browsing services, checking project status, listing provisioned resources, viewing env vars, or any mention of projects.dev or adding/provisioning/connecting a cloud service.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Provision third-party services (databases, auth, hosting, analytics, caching, AI, observability) and retrieve API keys/tokens using the Stripe Projects CLI plugin.
Check if the Stripe CLI is available:
which stripe && stripe --version
If not installed or below version 1.40.0:
brew install stripe/stripe-cli/stripe (or brew upgrade stripe/stripe-cli/stripe)Then ensure the Projects plugin is installed:
stripe plugin install projects
Confirm the requested provider/service exists:
stripe projects search <query> --json
If result_count is 0, inform the user the service was not found and stop.
If the user’s request is vague (for example, “I need a database”), browse the catalog to suggest options:
stripe projects catalog --json
Check if a project is already initialized:
stripe projects status --json
If not initialized, run a preflight check first to reveal all blockers at once:
stripe projects init --preflight --json
If all preflight checks pass (or the only failures are TOS_ACCEPTANCE_REQUIRED or Stripe session authenticated), proceed:
stripe projects init --accept-tos --yes
Important: stripe projects init installs the stripe-projects-cli skill locally at .claude/skills/stripe-projects-cli. This skill contains the full post-init command reference.
Verify the skill was installed:
test -f .claude/skills/stripe-projects-cli/SKILL.md && echo "OK" || echo "MISSING"
If MISSING: re-run stripe projects init --accept-tos --yes — the skill is bundled with the Projects plugin and installed during init.
If OK: use the locally-installed stripe-projects-cli skill (invoke using the Skill tool with name stripe-projects-cli) to continue the workflow — adding services, managing credentials, and configuring the project.
After a successful service addition, provide output in this format:
| Field | Value |
|---|---|
| Provider | <provider name> |
| Service | <service type> |
| Tier | <tier> |
| Env vars | <variable names only — never values> |
Then suggest 3–5 complementary services from different categories in the catalog (for example, if user added a database, suggest auth, hosting, or observability). Only reference services that actually appear in stripe projects catalog --json output — never fabricate commands or provider names.
The CLI manages all state under .projects/ and generates .env files. Don’t hand-edit these files. If you need to inspect project state, use the appropriate CLI command:
| Task | Command |
|---|---|
| View provisioned services | stripe projects status --json |
| List env var names | stripe projects env --json |
| Check project health | stripe projects status --json |
| Browse available services | stripe projects catalog --json |
Only inspect .projects/ or .env directly if the user explicitly asks you to — the CLI is authoritative, so manual edits may be overwritten.
Use project variables when the user wants to store an environment variable that doesn’t come from a provisioned provider resource, such as an app URL, feature flag, or self-managed API key.
Create or update a project variable for the active environment:
stripe projects variables set <name> --env-key <ENV_KEY> --value <value>
A successful variables set syncs the active environment output file immediately. If the user doesn’t provide the value, run the command without --value only in interactive mode so the CLI can prompt securely. Never print secret values in your response.
Bind an existing project variable to the active environment:
stripe projects env add <name> --variable --env-key <ENV_KEY>
Remove a variable binding from the active environment without deleting the stored variable:
stripe projects env remove <name> --variable
List and delete project variables:
stripe projects variables list --json
stripe projects variables delete <name> --yes
| Error code | Cause | Recovery |
|---|---|---|
BROWSER_AUTH_REQUIRED | No auth session and browser needed | Tell user to run stripe login — you cannot fix this |
ACCOUNT_NOT_ELIGIBLE | Account not onboarded for Projects | Tell user to run stripe login or visit https://projects.dev |
TOS_ACCEPTANCE_REQUIRED | Developer or provider terms not accepted | Re-run with --accept-tos |
PROVIDER_NOT_LINKED | Provider requires OAuth linking | Run stripe projects link <provider> — may open a browser |
PLAN_REQUIRED | Deployable needs a plan provisioned first | Provision the plan listed in the error, then retry |
UNKNOWN_ERROR | Unexpected failure | Show the full error message to the user and suggest running with --debug for diagnostics |
| Service not in catalog | Query returned 0 results | Inform user; suggest stripe projects catalog --json to browse alternatives |
| CLI not found | Stripe CLI not installed | Install using Homebrew (macOS) or follow https://docs.stripe.com/stripe-cli/install |
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Deploy a bex App to the current Kubernetes cluster and verify it reaches Ready. Use when the user asks to deploy a render.yaml (or legacy bex.yml) or the sample app and validate the rollout end to end. Optional argument: path to render.yaml.
日本語の概要は準備中です。原文の説明を表示しています。
Deploy a local checkout to a production Hetzner App using the manual image-import runbook. Use when the user asks to ship local working-tree code to a live bex App rather than deploy from remote Git. Arguments are the local repo path and app name.
日本語の概要は準備中です。原文の説明を表示しています。
Autonomously drain a `.pm` workstream — triage every open item (milestone or inbox-note task), then work it to done, park it in `blocked/`, or delete it as invalid, until the workstream has no open items left. Use when the user asks to "loop", drain, or clear a whole workstream's backlog (e.g. `/loopx w1`). Sequential, not interval-based; for a timed poll use /loop.
日本語の概要は準備中です。原文の説明を表示しています。
Create concise, syntax-verified Mermaid architecture diagrams. Use when the user asks to diagram a repository component, document, system, dependency flow, or supplied description in Mermaid.
日本語の概要は準備中です。原文の説明を表示しています。
Stand up or scale the local CAPD mock cluster and deploy the bex operator into it. Use when the user asks to create, inspect, or resize the repository's local development cluster. Optional argument: scale N.
日本語の概要は準備中です。原文の説明を表示しています。
Inspect and maintain the repository's .pm workstreams, inbox notes, milestones, and tasks. Use when the user asks for PM board status or requests a supported board mutation such as creating, promoting, adding, or completing work.
日本語の概要は準備中です。原文の説明を表示しています。