diff --git a/README.md b/README.md index 2e68e165..13d761f4 100644 --- a/README.md +++ b/README.md @@ -13,5 +13,5 @@ Highlighted richer examples in this repo include: - `plugins/notion` for planning, research, meetings, and knowledge capture - `plugins/build-ios-apps` for SwiftUI implementation, refactors, performance, and debugging - `plugins/build-macos-apps` for macOS SwiftUI/AppKit workflows, build/run/debug loops, and packaging guidance -- `plugins/build-web-apps` for deployment, UI, payments, and database workflows +- `plugins/build-web-apps` for UI, React, component, and database workflows - `plugins/netlify`, `plugins/render`, and `plugins/google-slides` for additional public skill- and MCP-backed plugin bundles diff --git a/plugins/build-web-apps/.codex-plugin/plugin.json b/plugins/build-web-apps/.codex-plugin/plugin.json index 63d43574..26737f60 100644 --- a/plugins/build-web-apps/.codex-plugin/plugin.json +++ b/plugins/build-web-apps/.codex-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "build-web-apps", "version": "0.1.0", - "description": "Build web apps with workflows for UI reviews, React improvements, deployment, payments, and database design.", + "description": "Build web apps with workflows for UI reviews, React improvements, component design, and database design.", "author": { "name": "OpenAI", "email": "support@openai.com", @@ -14,8 +14,6 @@ "build-web-apps", "build", "react", - "vercel", - "stripe", "supabase", "shadcn", "full-stack", @@ -25,8 +23,8 @@ "mcpServers": "./.mcp.json", "interface": { "displayName": "Build Web Apps", - "shortDescription": "Build, review, ship, and scale web apps across UI, React, deployment, payments, and databases", - "longDescription": "Use Build Web Apps to review and improve a web app's UI, apply React and Next.js guidance, deploy projects to Vercel, wire up Stripe payments, and design or tune Supabase/Postgres schemas and queries, all with plugin-local Vercel, Stripe, and Supabase MCP support.", + "shortDescription": "Build, review, and scale web apps across UI, React, components, and databases", + "longDescription": "Use Build Web Apps to review and improve a web app's UI, apply React and Next.js guidance, compose shadcn/ui components, and design or tune Supabase/Postgres schemas and queries with plugin-local Supabase MCP support.", "developerName": "OpenAI", "category": "Coding", "capabilities": [ @@ -37,7 +35,7 @@ "websiteURL": "https://openai.com/", "privacyPolicyURL": "https://openai.com/policies/privacy-policy/", "termsOfServiceURL": "https://openai.com/policies/terms-of-use/", - "defaultPrompt": "Review this app's UI, improve the React implementation, wire up payments or database changes, and help deploy it", + "defaultPrompt": "Review this app's UI, improve the React implementation, compose components, and wire up database changes", "brandColor": "#111111", "composerIcon": "./assets/build-web-apps-small.svg", "logo": "./assets/app-icon.png", diff --git a/plugins/build-web-apps/.mcp.json b/plugins/build-web-apps/.mcp.json index d37cfc98..16b8572d 100644 --- a/plugins/build-web-apps/.mcp.json +++ b/plugins/build-web-apps/.mcp.json @@ -1,13 +1,5 @@ { "mcpServers": { - "stripe": { - "type": "http", - "url": "https://mcp.stripe.com" - }, - "vercel": { - "type": "http", - "url": "https://mcp.vercel.com" - }, "supabase": { "type": "http", "url": "https://mcp.supabase.com/mcp" diff --git a/plugins/build-web-apps/README.md b/plugins/build-web-apps/README.md index fb2b564a..a62886ed 100644 --- a/plugins/build-web-apps/README.md +++ b/plugins/build-web-apps/README.md @@ -4,29 +4,23 @@ This plugin packages builder-oriented workflows in `plugins/build-web-apps`. It currently includes these skills: -- `deploy-to-vercel` - `react-best-practices` - `shadcn-best-practices` -- `stripe-best-practices` - `supabase-best-practices` - `web-design-guidelines` It is scaffolded to use these plugin-local MCP servers: -- `stripe` -- `vercel` - `supabase` ## What It Covers -- deployment and hosting operations through Vercel MCP -- React and Next.js performance guidance sourced from Vercel best practices +- React and Next.js performance guidance - shadcn/ui composition, styling, and component usage guidance -- Stripe integration design across payments, subscriptions, Connect, and Treasury - Supabase/Postgres schema, performance, and RLS best practices - UI review guidance against web interface design guidelines -- end-to-end product building workflows that span frontend, backend, payments, - and deployment +- end-to-end product building workflows that span frontend, backend, and + database work ## Plugin Structure @@ -42,8 +36,7 @@ with this shape: - `.mcp.json` - plugin-local MCP dependency manifest - - bundles the Stripe, Vercel, and Supabase MCP endpoints used by bundled - skills + - bundles the Supabase MCP endpoint used by bundled skills - `agents/` - plugin-level agent metadata @@ -51,15 +44,13 @@ with this shape: - `skills/` - the actual skill payload - - currently includes deployment, UI, payments, and database-focused skills + - currently includes UI, component, React, and database-focused skills ## Notes This plugin is MCP-backed through `.mcp.json` and currently combines: -- Vercel deployment workflows - React and Next.js optimization guidance - shadcn/ui frontend implementation guidance -- Stripe integration guidance - Supabase/Postgres optimization guidance - web design and UI review guidance diff --git a/plugins/build-web-apps/agents/openai.yaml b/plugins/build-web-apps/agents/openai.yaml index 0df9130d..c073268c 100644 --- a/plugins/build-web-apps/agents/openai.yaml +++ b/plugins/build-web-apps/agents/openai.yaml @@ -1,22 +1,12 @@ interface: display_name: "Build Web Apps" - short_description: "Build, review, ship, and scale web apps across UI, React, deployment, payments, and databases" + short_description: "Build, review, and scale web apps across UI, React, components, and databases" icon_small: "./assets/build-web-apps-small.svg" icon_large: "./assets/app-icon.png" - default_prompt: "Use Build Web Apps to review a web app's UI, improve the React implementation, wire up payments or database changes, and help deploy it." + default_prompt: "Use Build Web Apps to review a web app's UI, improve the React implementation, and wire up database changes." dependencies: tools: - - type: "mcp" - value: "stripe" - description: "Stripe MCP server" - transport: "streamable_http" - url: "https://mcp.stripe.com" - - type: "mcp" - value: "vercel" - description: "Vercel MCP server" - transport: "streamable_http" - url: "https://mcp.vercel.com" - type: "mcp" value: "supabase" description: "Supabase MCP server" diff --git a/plugins/build-web-apps/skills/deploy-to-vercel/Archive.zip b/plugins/build-web-apps/skills/deploy-to-vercel/Archive.zip deleted file mode 100644 index 2945baff..00000000 Binary files a/plugins/build-web-apps/skills/deploy-to-vercel/Archive.zip and /dev/null differ diff --git a/plugins/build-web-apps/skills/deploy-to-vercel/SKILL.md b/plugins/build-web-apps/skills/deploy-to-vercel/SKILL.md deleted file mode 100644 index 60f8d7ae..00000000 --- a/plugins/build-web-apps/skills/deploy-to-vercel/SKILL.md +++ /dev/null @@ -1,241 +0,0 @@ ---- -name: deploy-to-vercel -description: Deploy applications and websites to Vercel. Use when the user requests deployment actions like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment". -metadata: - author: vercel - version: "3.0.0" ---- - -# Deploy to Vercel - -Deploy any project to Vercel. **Always deploy as preview** (not production) unless the user explicitly asks for production. - -The goal is to get the user into the best long-term setup: their project linked to Vercel with git-push deploys. Every method below tries to move the user closer to that state. - -## Step 1: Gather Project State - -Run all four checks before deciding which method to use: - -```bash -# 1. Check for a git remote -git remote get-url origin 2>/dev/null - -# 2. Check if locally linked to a Vercel project (either file means linked) -cat .vercel/project.json 2>/dev/null || cat .vercel/repo.json 2>/dev/null - -# 3. Check if the Vercel CLI is installed and authenticated -vercel whoami 2>/dev/null - -# 4. List available teams (if authenticated) -vercel teams list --format json 2>/dev/null -``` - -### Team selection - -If the user belongs to multiple teams, present all available team slugs as a bulleted list and ask which one to deploy to. Once the user picks a team, proceed immediately to the next step — do not ask for additional confirmation. - -Pass the team slug via `--scope` on all subsequent CLI commands (`vercel deploy`, `vercel link`, `vercel inspect`, etc.): - -```bash -vercel deploy [path] -y --no-wait --scope -``` - -If the project is already linked (`.vercel/project.json` or `.vercel/repo.json` exists), the `orgId` in those files determines the team — no need to ask again. If there is only one team (or just a personal account), skip the prompt and use it directly. - -**About the `.vercel/` directory:** A linked project has either: -- `.vercel/project.json` — created by `vercel link` (single project linking). Contains `projectId` and `orgId`. -- `.vercel/repo.json` — created by `vercel link --repo` (repo-based linking). Contains `orgId`, `remoteName`, and a `projects` array mapping directories to Vercel project IDs. - -Either file means the project is linked. Check for both. - -**Do NOT** use `vercel project inspect`, `vercel ls`, or `vercel link` to detect state in an unlinked directory — without a `.vercel/` config, they will interactively prompt (or with `--yes`, silently link as a side-effect). Only `vercel whoami` is safe to run anywhere. - -## Step 2: Choose a Deploy Method - -### Linked (`.vercel/` exists) + has git remote → Git Push - -This is the ideal state. The project is linked and has git integration. - -1. **Ask the user before pushing.** Never push without explicit approval: - ``` - This project is connected to Vercel via git. I can commit and push to - trigger a deployment. Want me to proceed? - ``` - -2. **Commit and push:** - ```bash - git add . - git commit -m "deploy: " - git push - ``` - Vercel automatically builds from the push. Non-production branches get preview deployments; the production branch (usually `main`) gets a production deployment. - -3. **Retrieve the preview URL.** If the CLI is authenticated: - ```bash - sleep 5 - vercel ls --format json - ``` - The JSON output has a `deployments` array. Find the latest entry — its `url` field is the preview URL. - - If the CLI is not authenticated, tell the user to check the Vercel dashboard or the commit status checks on their git provider for the preview URL. - ---- - -### Linked (`.vercel/` exists) + no git remote → `vercel deploy` - -The project is linked but there's no git repo. Deploy directly with the CLI. - -```bash -vercel deploy [path] -y --no-wait -``` - -Use `--no-wait` so the CLI returns immediately with the deployment URL instead of blocking until the build finishes (builds can take a while). Then check on the deployment status with: - -```bash -vercel inspect -``` - -For production deploys (only if user explicitly asks): -```bash -vercel deploy [path] --prod -y --no-wait -``` - ---- - -### Not linked + CLI is authenticated → Link first, then deploy - -The CLI is working but the project isn't linked yet. This is the opportunity to get the user into the best state. - -1. **Ask the user which team to deploy to.** Present the team slugs from Step 1 as a bulleted list. If there's only one team (or just a personal account), skip this step. - -2. **Once a team is selected, proceed directly to linking.** Tell the user what will happen but do not ask for separate confirmation: - ``` - Linking this project to on Vercel. This will create a Vercel - project to deploy to and enable automatic deployments on future git pushes. - ``` - -3. **If a git remote exists**, use repo-based linking with the selected team scope: - ```bash - vercel link --repo --scope - ``` - This reads the git remote URL and matches it to existing Vercel projects that deploy from that repo. It creates `.vercel/repo.json`. This is much more reliable than `vercel link` (without `--repo`), which tries to match by directory name and often fails when the local folder and Vercel project are named differently. - - **If there is no git remote**, fall back to standard linking: - ```bash - vercel link --scope - ``` - This prompts the user to select or create a project. It creates `.vercel/project.json`. - -4. **Then deploy using the best available method:** - - If a git remote exists → commit and push (see git push method above) - - If no git remote → `vercel deploy [path] -y --no-wait --scope `, then `vercel inspect ` to check status - ---- - -### Not linked + CLI not authenticated → Install, auth, link, deploy - -The Vercel CLI isn't set up at all. - -1. **Install the CLI (if not already installed):** - ```bash - npm install -g vercel - ``` - -2. **Authenticate:** - ```bash - vercel login - ``` - The user completes auth in their browser. If running in a non-interactive environment where login is not possible, skip to the **no-auth fallback** below. - -3. **Ask which team to deploy to** — present team slugs from `vercel teams list --format json` as a bulleted list. If only one team / personal account, skip. Once selected, proceed immediately. - -4. **Link the project** with the selected team scope (use `--repo` if a git remote exists, plain `vercel link` otherwise): - ```bash - vercel link --repo --scope # if git remote exists - vercel link --scope # if no git remote - ``` - -5. **Deploy** using the best available method (git push if remote exists, otherwise `vercel deploy -y --no-wait --scope `, then `vercel inspect ` to check status). - ---- - -### No-Auth Fallback — Codex sandbox - -**When to use:** In the Codex sandbox where the CLI may not be authenticated. Codex runs in a sandboxed environment by default — try the CLI first, and fall back to the deploy script if auth fails. - -1. **Check whether the Vercel CLI is installed** (no escalation needed for this check): - ```bash - command -v vercel - ``` - -2. **If `vercel` is installed**, try deploying with the CLI: - ```bash - vercel deploy [path] -y --no-wait - ``` - -3. **If `vercel` is not installed, or the CLI fails with "No existing credentials found"**, use the fallback script: - ```bash - skill_dir="" - - # Deploy current directory - bash "$skill_dir/resources/deploy-codex.sh" - - # Deploy specific project - bash "$skill_dir/resources/deploy-codex.sh" /path/to/project - - # Deploy existing tarball - bash "$skill_dir/resources/deploy-codex.sh" /path/to/project.tgz - ``` - -The script handles framework detection, packaging, and deployment. It waits for the build to complete and returns JSON with `previewUrl` and `claimUrl`. - -**Tell the user:** "Your deployment is ready at [previewUrl]. Claim it at [claimUrl] to manage your deployment." - -**Escalated network access:** Only escalate the actual deploy command if sandboxing blocks the network call (`sandbox_permissions=require_escalated`). Do **not** escalate the `command -v vercel` check. - ---- - -## Agent-Specific Notes - -### Codex - -Codex runs in a sandbox. Check if the CLI is available first, then fall back to the deploy script. Go to the **no-auth fallback — Codex sandbox**. - ---- - -## Output - -Always show the user the deployment URL. - -- **Git push:** Use `vercel ls --format json` to find the preview URL. If the CLI isn't authenticated, tell the user to check the Vercel dashboard or commit status checks. -- **CLI deploy:** Show the URL returned by `vercel deploy --no-wait`. Use `vercel inspect ` to check build status and report it to the user. -- **No-auth fallback:** Show both the preview URL and the claim URL: - ``` - Deployment successful! - - Preview URL: https://my-app-abc123.vercel.app - Claim URL: https://vercel.com/claim-deployment?code=... - - View your site at the Preview URL. - To transfer this deployment to your Vercel account, visit the Claim URL. - ``` - -**Do not** curl or fetch the deployed URL to verify it works. Just return the link. - ---- - -## Troubleshooting - -### Escalated Network Access (Codex / sandboxed environments) - -If deployment fails due to network issues (timeouts, DNS errors, connection resets) in a sandboxed environment, rerun with escalated permissions (`sandbox_permissions=require_escalated`). Do not escalate the initial CLI availability check — only escalate the actual deploy command. - -Example guidance to the user: -``` -The deploy needs escalated network access to deploy to Vercel. I can rerun -the command with escalated permissions — want me to proceed? -``` - -### CLI Auth Failure - -If `vercel login` or `vercel deploy` fails with authentication errors, fall back to the Codex no-auth deploy script. diff --git a/plugins/build-web-apps/skills/deploy-to-vercel/resources/deploy-codex.sh b/plugins/build-web-apps/skills/deploy-to-vercel/resources/deploy-codex.sh deleted file mode 100644 index af07d0fd..00000000 --- a/plugins/build-web-apps/skills/deploy-to-vercel/resources/deploy-codex.sh +++ /dev/null @@ -1,301 +0,0 @@ -#!/bin/bash - -# Vercel Deployment Script for Codex (via claimable deploy endpoint) -# Usage: ./deploy-codex.sh [project-path] -# Returns: JSON with previewUrl, claimUrl, deploymentId, projectId - -set -euo pipefail - -DEPLOY_ENDPOINT="https://codex-deploy-skills.vercel.sh/api/deploy" - -# Detect framework from package.json -detect_framework() { - local pkg_json="$1" - - if [ ! -f "$pkg_json" ]; then - echo "null" - return - fi - - local content=$(cat "$pkg_json") - - # Helper to check if a package exists in dependencies or devDependencies. - # Use exact matching by default, with a separate prefix matcher for scoped - # package families like "@remix-run/". - has_dep_exact() { - echo "$content" | grep -q "\"$1\"" - } - - has_dep_prefix() { - echo "$content" | grep -q "\"$1" - } - - # Order matters - check more specific frameworks first - - # Blitz - if has_dep_exact "blitz"; then echo "blitzjs"; return; fi - - # Next.js - if has_dep_exact "next"; then echo "nextjs"; return; fi - - # Gatsby - if has_dep_exact "gatsby"; then echo "gatsby"; return; fi - - # Remix - if has_dep_prefix "@remix-run/"; then echo "remix"; return; fi - - # React Router (v7 framework mode) - if has_dep_prefix "@react-router/"; then echo "react-router"; return; fi - - # TanStack Start - if has_dep_exact "@tanstack/start"; then echo "tanstack-start"; return; fi - - # Astro - if has_dep_exact "astro"; then echo "astro"; return; fi - - # Hydrogen (Shopify) - if has_dep_exact "@shopify/hydrogen"; then echo "hydrogen"; return; fi - - # SvelteKit - if has_dep_exact "@sveltejs/kit"; then echo "sveltekit-1"; return; fi - - # Svelte (standalone) - if has_dep_exact "svelte"; then echo "svelte"; return; fi - - # Nuxt - if has_dep_exact "nuxt"; then echo "nuxtjs"; return; fi - - # Vue with Vitepress - if has_dep_exact "vitepress"; then echo "vitepress"; return; fi - - # Vue with Vuepress - if has_dep_exact "vuepress"; then echo "vuepress"; return; fi - - # Gridsome - if has_dep_exact "gridsome"; then echo "gridsome"; return; fi - - # SolidStart - if has_dep_exact "@solidjs/start"; then echo "solidstart-1"; return; fi - - # Docusaurus - if has_dep_exact "@docusaurus/core"; then echo "docusaurus-2"; return; fi - - # RedwoodJS - if has_dep_prefix "@redwoodjs/"; then echo "redwoodjs"; return; fi - - # Hexo - if has_dep_exact "hexo"; then echo "hexo"; return; fi - - # Eleventy - if has_dep_exact "@11ty/eleventy"; then echo "eleventy"; return; fi - - # Angular / Ionic Angular - if has_dep_exact "@ionic/angular"; then echo "ionic-angular"; return; fi - if has_dep_exact "@angular/core"; then echo "angular"; return; fi - - # Ionic React - if has_dep_exact "@ionic/react"; then echo "ionic-react"; return; fi - - # Create React App - if has_dep_exact "react-scripts"; then echo "create-react-app"; return; fi - - # Ember - if has_dep_exact "ember-cli" || has_dep_exact "ember-source"; then echo "ember"; return; fi - - # Dojo - if has_dep_exact "@dojo/framework"; then echo "dojo"; return; fi - - # Polymer - if has_dep_prefix "@polymer/"; then echo "polymer"; return; fi - - # Preact - if has_dep_exact "preact"; then echo "preact"; return; fi - - # Stencil - if has_dep_exact "@stencil/core"; then echo "stencil"; return; fi - - # UmiJS - if has_dep_exact "umi"; then echo "umijs"; return; fi - - # Sapper (legacy Svelte) - if has_dep_exact "sapper"; then echo "sapper"; return; fi - - # Saber - if has_dep_exact "saber"; then echo "saber"; return; fi - - # Sanity - if has_dep_exact "sanity"; then echo "sanity-v3"; return; fi - if has_dep_prefix "@sanity/"; then echo "sanity"; return; fi - - # Storybook - if has_dep_prefix "@storybook/"; then echo "storybook"; return; fi - - # NestJS - if has_dep_exact "@nestjs/core"; then echo "nestjs"; return; fi - - # Elysia - if has_dep_exact "elysia"; then echo "elysia"; return; fi - - # Hono - if has_dep_exact "hono"; then echo "hono"; return; fi - - # Fastify - if has_dep_exact "fastify"; then echo "fastify"; return; fi - - # h3 - if has_dep_exact "h3"; then echo "h3"; return; fi - - # Nitro - if has_dep_exact "nitropack"; then echo "nitro"; return; fi - - # Express - if has_dep_exact "express"; then echo "express"; return; fi - - # Vite (generic - check last among JS frameworks) - if has_dep_exact "vite"; then echo "vite"; return; fi - - # Parcel - if has_dep_exact "parcel"; then echo "parcel"; return; fi - - # No framework detected - echo "null" -} - -# Parse arguments -INPUT_PATH="${1:-.}" - -# Create temp directory for packaging -TEMP_DIR=$(mktemp -d) -TARBALL="$TEMP_DIR/project.tgz" -STAGING_DIR="$TEMP_DIR/staging" -CLEANUP_TEMP=true - -cleanup() { - if [ "$CLEANUP_TEMP" = true ]; then - rm -rf "$TEMP_DIR" - fi -} -trap cleanup EXIT - -echo "Preparing deployment..." >&2 - -# Check if input is a .tgz file or a directory -FRAMEWORK="null" - -if [ -f "$INPUT_PATH" ] && [[ "$INPUT_PATH" == *.tgz ]]; then - # Input is already a tarball, use it directly - echo "Using provided tarball..." >&2 - TARBALL="$INPUT_PATH" - CLEANUP_TEMP=false - # Can't detect framework from tarball, leave as null -elif [ -d "$INPUT_PATH" ]; then - # Input is a directory, need to tar it - PROJECT_PATH=$(cd "$INPUT_PATH" && pwd) - - # Detect framework from package.json - FRAMEWORK=$(detect_framework "$PROJECT_PATH/package.json") - - # Stage files into a temporary directory to avoid mutating the source tree. - mkdir -p "$STAGING_DIR" - echo "Staging project files..." >&2 - tar -C "$PROJECT_PATH" \ - --exclude='node_modules' \ - --exclude='.git' \ - --exclude='.env' \ - --exclude='.env.*' \ - -cf - . | tar -C "$STAGING_DIR" -xf - - - # Check if this is a static HTML project (no package.json) - if [ ! -f "$PROJECT_PATH/package.json" ]; then - # Find HTML files in root - HTML_FILES=$(find "$STAGING_DIR" -maxdepth 1 -name "*.html" -type f) - HTML_COUNT=$(printf '%s\n' "$HTML_FILES" | sed '/^$/d' | wc -l | tr -d '[:space:]') - - # If there's exactly one HTML file and it's not index.html, rename it - if [ "$HTML_COUNT" -eq 1 ]; then - HTML_FILE=$(echo "$HTML_FILES" | head -1) - BASENAME=$(basename "$HTML_FILE") - if [ "$BASENAME" != "index.html" ]; then - echo "Renaming $BASENAME to index.html..." >&2 - mv "$HTML_FILE" "$STAGING_DIR/index.html" - fi - fi - fi - - # Create tarball from the staging directory - echo "Creating deployment package..." >&2 - tar -czf "$TARBALL" -C "$STAGING_DIR" . -else - echo "Error: Input must be a directory or a .tgz file" >&2 - exit 1 -fi - -if [ "$FRAMEWORK" != "null" ]; then - echo "Detected framework: $FRAMEWORK" >&2 -fi - -# Deploy -echo "Deploying..." >&2 -RESPONSE=$(curl -s -X POST "$DEPLOY_ENDPOINT" -F "file=@$TARBALL" -F "framework=$FRAMEWORK") - -# Check for error in response -if echo "$RESPONSE" | grep -q '"error"'; then - ERROR_MSG=$(echo "$RESPONSE" | grep -o '"error":"[^"]*"' | cut -d'"' -f4) - echo "Error: $ERROR_MSG" >&2 - exit 1 -fi - -# Extract URLs from response -PREVIEW_URL=$(echo "$RESPONSE" | grep -o '"previewUrl":"[^"]*"' | cut -d'"' -f4) -CLAIM_URL=$(echo "$RESPONSE" | grep -o '"claimUrl":"[^"]*"' | cut -d'"' -f4) - -if [ -z "$PREVIEW_URL" ]; then - echo "Error: Could not extract preview URL from response" >&2 - echo "$RESPONSE" >&2 - exit 1 -fi - -echo "Deployment started. Waiting for build to complete..." >&2 -echo "Preview URL: $PREVIEW_URL" >&2 - -# Poll the preview URL until it returns a non-5xx response (5xx = still building) -MAX_ATTEMPTS=60 # 5 minutes max (60 * 5 seconds) -ATTEMPT=0 - -while [ $ATTEMPT -lt $MAX_ATTEMPTS ]; do - HTTP_STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$PREVIEW_URL") - - if [ "$HTTP_STATUS" -eq 200 ]; then - echo "" >&2 - echo "Deployment ready!" >&2 - break - elif [ "$HTTP_STATUS" -ge 500 ]; then - # 5xx means still building/deploying - echo "Building... (attempt $((ATTEMPT + 1))/$MAX_ATTEMPTS)" >&2 - sleep 5 - ATTEMPT=$((ATTEMPT + 1)) - elif [ "$HTTP_STATUS" -ge 400 ] && [ "$HTTP_STATUS" -lt 500 ]; then - # 4xx might be an error or the app itself returns 4xx - it's responding - echo "" >&2 - echo "Deployment ready (returned $HTTP_STATUS)!" >&2 - break - else - # Any other status, assume it's ready - echo "" >&2 - echo "Deployment ready!" >&2 - break - fi -done - -if [ $ATTEMPT -eq $MAX_ATTEMPTS ]; then - echo "" >&2 - echo "Warning: Timed out waiting for deployment, but it may still be building." >&2 -fi - -echo "" >&2 -echo "Preview URL: $PREVIEW_URL" >&2 -echo "Claim URL: $CLAIM_URL" >&2 -echo "" >&2 - -# Output JSON for programmatic use -echo "$RESPONSE" diff --git a/plugins/build-web-apps/skills/stripe-best-practices/SKILL.md b/plugins/build-web-apps/skills/stripe-best-practices/SKILL.md deleted file mode 100644 index c7eb81c1..00000000 --- a/plugins/build-web-apps/skills/stripe-best-practices/SKILL.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -name: stripe-best-practices -description: Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accounts, integration surfaces (Checkout, Payment Element), and migrating from deprecated Stripe APIs. Use when building, modifying, or reviewing any Stripe integration — including accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, or creating connected accounts. ---- - -Latest Stripe API version: **2026-02-25.clover**. Always use the latest API version and SDK unless the user specifies otherwise. - -## Integration routing - -| Building... | Recommended API | Details | -|---|---|---| -| One-time payments | Checkout Sessions | [references/payments.md](references/payments.md) | -| Custom payment form with embedded UI | Checkout Sessions + Payment Element | [references/payments.md](references/payments.md) | -| Saving a payment method for later | Setup Intents | [references/payments.md](references/payments.md) | -| Connect platform or marketplace | Accounts v2 (`/v2/core/accounts`) | [references/connect.md](references/connect.md) | -| Subscriptions or recurring billing | Billing APIs + Checkout Sessions | [references/billing.md](references/billing.md) | -| Embedded financial accounts / banking | v2 Financial Accounts | [references/treasury.md](references/treasury.md) | - -Read the relevant reference file before answering any integration question or writing code. - -## Key documentation - -When the user's request does not clearly fit a single domain above, consult: - -- [Integration Options](https://docs.stripe.com/payments/payment-methods/integration-options.md) — Start here when designing any integration. -- [API Tour](https://docs.stripe.com/payments-api/tour.md) — Overview of Stripe's API surface. -- [Go Live Checklist](https://docs.stripe.com/get-started/checklist/go-live.md) — Review before launching. diff --git a/plugins/build-web-apps/skills/stripe-best-practices/references/billing.md b/plugins/build-web-apps/skills/stripe-best-practices/references/billing.md deleted file mode 100644 index ef520ad6..00000000 --- a/plugins/build-web-apps/skills/stripe-best-practices/references/billing.md +++ /dev/null @@ -1,23 +0,0 @@ -# Billing / Subscriptions - -## Table of contents -- When to use Billing APIs -- Recommended frontend pairing -- Traps to avoid - -## When to use Billing APIs - -If the user has a recurring revenue model (subscriptions, usage-based billing, seat-based pricing), use the Billing APIs to [plan their integration](https://docs.stripe.com/billing/subscriptions/designing-integration.md) instead of a direct PaymentIntent integration. - -Review the [Subscription Use Cases](https://docs.stripe.com/billing/subscriptions/use-cases.md) and [SaaS guide](https://docs.stripe.com/saas.md) to find the right pattern for the user's pricing model. - -## Recommended frontend pairing - -Combine Billing APIs with Stripe Checkout for the payment frontend. Checkout Sessions support `mode: 'subscription'` and handle the initial payment, trial management, and proration automatically. - -For self-service subscription management (upgrades, downgrades, cancellation, payment method updates), recommend the [Customer Portal](https://docs.stripe.com/customer-management/integrate-customer-portal.md). - -## Traps to avoid - -- Do not build manual subscription renewal loops using raw PaymentIntents. Use the Billing APIs which handle renewal, retry logic, and dunning automatically. -- Do not use the deprecated `plan` object. Use [Prices](https://docs.stripe.com/api/prices.md) instead. diff --git a/plugins/build-web-apps/skills/stripe-best-practices/references/connect.md b/plugins/build-web-apps/skills/stripe-best-practices/references/connect.md deleted file mode 100644 index 39eeb49e..00000000 --- a/plugins/build-web-apps/skills/stripe-best-practices/references/connect.md +++ /dev/null @@ -1,47 +0,0 @@ -# Connect / Platforms - -## Table of contents -- Accounts v2 API -- Controller properties -- Charge types -- Integration guides - -## Accounts v2 API - -For new Connect platforms, ALWAYS use the [Accounts v2 API](https://docs.stripe.com/connect/accounts-v2.md) (`POST /v2/core/accounts`). This is Stripe's actively invested path and ensures long-term support. - -**Traps to avoid:** Do not use the legacy `type` parameter (`type: 'express'`, `type: 'custom'`, `type: 'standard'`) in `POST /v1/accounts` for new platforms unless the user has explicitly requested v1. - -## Controller properties - -Configure connected accounts using `controller` properties instead of legacy account types: - -| Property | Controls | -|---|---| -| `controller.losses.payments` | Who is liable for negative balances | -| `controller.fees.payer` | Who pays Stripe fees | -| `controller.stripe_dashboard.type` | Dashboard access (`full`, `express`, `none`) | -| `controller.requirement_collection` | Who collects onboarding requirements | - -Use `defaults.responsibilities`, `dashboard`, and `configuration` as described in [connected account configuration](https://docs.stripe.com/connect/accounts-v2/connected-account-configuration.md). - -Always describe accounts in terms of their responsibility settings, dashboard access, and [capabilities](https://docs.stripe.com/connect/account-capabilities.md) to describe what connected accounts can do. - -**Traps to avoid:** Do not use the terms "Standard", "Express", or "Custom" as account types. These are legacy categories that bundle together responsibility, dashboard, and requirement decisions into opaque labels. Controller properties give explicit control over each dimension. - -## Charge types - -Choose one charge type per integration — do not mix them. For most platforms, start with destination charges: - -- **Destination charges** — Use when the platform accepts liability for negative balances. Funds route to the connected account via `transfer_data.destination`. -- **Direct charges** — Use when the platform wants Stripe to take risk on the connected account. The charge is created on the connected account directly. - -Use `on_behalf_of` to control the merchant of record, but only after reading [how charges work in Connect](https://docs.stripe.com/connect/charges.md). - -**Traps to avoid:** Do not use the Charges API for Connect fund flows — use PaymentIntents or Checkout Sessions with `transfer_data` or `on_behalf_of`. Do not mix charge types within a single integration. - -## Integration guides - -- [SaaS platforms and marketplaces guide](https://docs.stripe.com/connect/saas-platforms-and-marketplaces.md) — Choosing the right integration shape. -- [Interactive platform guide](https://docs.stripe.com/connect/interactive-platform-guide.md) — Step-by-step platform builder. -- [Design an integration](https://docs.stripe.com/connect/design-an-integration.md) — Detailed risk and responsibility decisions. diff --git a/plugins/build-web-apps/skills/stripe-best-practices/references/payments.md b/plugins/build-web-apps/skills/stripe-best-practices/references/payments.md deleted file mode 100644 index 06be6931..00000000 --- a/plugins/build-web-apps/skills/stripe-best-practices/references/payments.md +++ /dev/null @@ -1,62 +0,0 @@ -# Payments - -## Table of contents -- API hierarchy -- Integration surfaces -- Payment Element guidance -- Saving payment methods -- Dynamic payment methods -- Deprecated APIs and migration paths -- PCI compliance - -## API hierarchy - -Use the [Checkout Sessions API](https://docs.stripe.com/api/checkout/sessions.md) (`checkout.sessions.create`) for on-session payments. It supports one-time payments and subscriptions and handles taxes, discounts, shipping, and adaptive pricing automatically. - -Use the [PaymentIntents API](https://docs.stripe.com/payments/paymentintents/lifecycle.md) for off-session payments, or when the merchant needs to model checkout state independently and just create a charge. - -**Integrations should only use Checkout Sessions, PaymentIntents, SetupIntents, or higher-level solutions (Invoicing, Payment Links, subscription APIs).** - -## Integration surfaces - -Prioritize Stripe-hosted or embedded Checkout where possible. Use in this order of preference: - -1. **Payment Links** — No-code. Best for simple products. -2. **Checkout** ([docs](https://docs.stripe.com/payments/checkout.md)) — Stripe-hosted or embedded form. Best for most web apps. -3. **Payment Element** ([docs](https://docs.stripe.com/payments/payment-element.md)) — Embedded UI component for advanced customization. - - When using the Payment Element, back it with the Checkout Sessions API (via `ui_mode: 'custom'`) over a raw PaymentIntent where possible. - -**Traps to avoid:** Do not recommend the legacy Card Element or the Payment Element in card-only mode. If the user asks for the Card Element, advise them to [migrate to the Payment Element](https://docs.stripe.com/payments/payment-element/migration.md). - -## Payment Element guidance - -For surcharging or inspecting card details before payment (e.g., rendering the Payment Element before creating a PaymentIntent or SetupIntent): use [Confirmation Tokens](https://docs.stripe.com/payments/finalize-payments-on-the-server.md). Do not recommend `createPaymentMethod` or `createToken` from Stripe.js. - -## Saving payment methods - -Use the [Setup Intents API](https://docs.stripe.com/api/setup_intents.md) to save a payment method for later use. - -**Traps to avoid:** Do not use the Sources API to save cards to customers. The Sources API is deprecated — Setup Intents is the correct approach. - -## Dynamic payment methods - -Advise users to enable dynamic payment methods in the Stripe Dashboard rather than passing specific [`payment_method_types`](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_types.md) in the PaymentIntent or SetupIntent. Stripe automatically selects payment methods based on the customer's location, wallets, and preferences when the Payment Element is used. - -## Deprecated APIs and migration paths - -Never recommend the Charges API. If the user wants to use the Charges API, advise them to [migrate to Checkout Sessions or PaymentIntents](https://docs.stripe.com/payments/payment-intents/migration/charges.md). - -Do not call other deprecated or outdated API endpoints unless there is a specific need and absolutely no other way. - -| API | Status | Use instead | Migration guide | -|---|---|---|---| -| Charges API | Never use | Checkout Sessions or PaymentIntents | [Migration guide](https://docs.stripe.com/payments/payment-intents/migration/charges.md) | -| Sources API | Deprecated | Setup Intents | [Setup Intents docs](https://docs.stripe.com/api/setup_intents.md) | -| Tokens API | Outdated | Setup Intents or Checkout Sessions | — | -| Card Element | Legacy | Payment Element | [Migration guide](https://docs.stripe.com/payments/payment-element/migration.md) | - -## PCI compliance - -If a PCI-compliant user asks about sending server-side raw PAN data, advise them that they may need to prove PCI compliance to access options like [payment_method_data](https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_data.md). - -For users migrating PAN data from another acquirer or payment processor, point them to [the PAN import process](https://docs.stripe.com/get-started/data-migrations/pan-import.md). diff --git a/plugins/build-web-apps/skills/stripe-best-practices/references/treasury.md b/plugins/build-web-apps/skills/stripe-best-practices/references/treasury.md deleted file mode 100644 index 6b39ef9d..00000000 --- a/plugins/build-web-apps/skills/stripe-best-practices/references/treasury.md +++ /dev/null @@ -1,15 +0,0 @@ -# Treasury / Financial Accounts - -## Table of contents -- v2 Financial Accounts API -- Legacy v1 Treasury - -## v2 Financial Accounts API - -For embedded financial accounts (bank accounts, account and routing numbers, money movement), use the [v2 Financial Accounts API](https://docs.stripe.com/api/v2/core/vault/financial-accounts.md) (`POST /v2/core/vault/financial_accounts`). This is required for new integrations. - -For Treasury concepts and guides, see the [Treasury overview](https://docs.stripe.com/treasury.md). - -## Legacy v1 Treasury - -Do not use the [v1 Treasury Financial Accounts API](https://docs.stripe.com/api/treasury/financial_accounts.md) (`POST /v1/treasury/financial_accounts`) for new integrations. Existing v1 integrations continue to work.