house / Clerk + Cloudflare Commerce Bootstrap

---
name: clerk-cloudflare-commerce-bootstrap
description: Plan and implement a test-first Cloudflare commerce application with Clerk identity, Stripe Checkout, and explicit live-billing approval.
license: MIT
tags: [orchestrator, clerk, cloudflare, stripe, commerce, bootstrap]
agents: [claude-code, codex, autojack]
category: commerce
metadata:
  version: "1.0.2"
capabilities:
  network: true
  filesystem: readwrite
  tools: [Bash, Read, Edit]
requires-secrets:
  - name: CLOUDFLARE_API_TOKEN
    description: Deployment token supplied by the operator's Cloudflare configuration.
    required: true
  - name: CLERK_SECRET_KEY
    description: Server-side Clerk credential managed outside the repository.
    required: true
  - name: STRIPE_SECRET_KEY
    description: Stripe credential managed outside the repository; test mode is the default.
    required: true
  - name: STRIPE_WEBHOOK_SECRET
    description: Signing secret for verifying Stripe webhook requests.
    required: true
resources:
  - path: story.md
    type: file
---

Clerk + Cloudflare + Stripe Commerce Bootstrap

This is an orchestration path for a Cloudflare commerce app with Clerk identity,

Stripe Checkout, webhooks, and preview isolation. It does not replace the

underlying deployment, identity, or billing skills; it sequences their shared

decisions.

Start with a fit check

Before mutating anything, inspect the repository and classify it:

• full-commerce: needs identity, protected product access, Checkout, webhooks, persistent application state, and preview isolation.
• auth-only: needs sign-in or protected APIs but no paid flow.
• lead-capture: needs forms or admin notification, not account billing.
• deploy-only: needs hosting, bindings, or deployment hygiene.

Route non-commerce projects to the narrower skill and stop. Do not add Clerk

or Stripe merely because this skill was invoked.

Test-first default

Use Stripe test mode for every initial end-to-end path. Production billing

mutations require explicit current-conversation approval that says live and

names the intended action. Existing production credentials do not grant that

approval.

Keep every provider value outside version control. Typical variable names are:

CLERK_SECRET_KEY=<managed secret>
VITE_CLERK_PUBLISHABLE_KEY=<managed build variable>
STRIPE_SECRET_KEY=<managed secret>
STRIPE_WEBHOOK_SECRET=<managed secret>
STRIPE_PRICE_ID=<managed configuration value>

Use separate preview and production variable sets. Do not print values in logs,

reports, commit messages, or pull requests.

Sequence

1. Inspect deployment model, existing Cloudflare resources, application data, auth surface, billing surface, and CI. Reuse matching resources rather than creating lookalikes.
2. Establish production and preview resource boundaries: Pages/Workers deployment, D1/KV bindings where needed, and migrations. Preserve one canonical deployment path.
3. Add Clerk using clerk-cloudflare-auth: client UI, edge verification, and an explicit mapping from verified identity to application data.
4. Add Stripe Checkout using stripe-commerce-checkout in test mode. Verify signed webhook handling, idempotency, and recovery from delayed delivery.
5. Supply preview and production environment variables through the provider configuration. Frontend build variables and runtime secrets can have different loading paths; validate both.
6. Test locally and in a preview deployment. Verify signed-out public pages, signed-in routes, Checkout creation, webhook state updates, and the return path before considering production.

Live billing gate

After a user explicitly authorizes a scoped live action, confirm product,

price, currency, and webhook endpoint before creating or modifying live Stripe

objects. Apply only the approved provider configuration, verify the live

webhook signature, then report names and statuses—not secret values.

Output contract

Report the selected fit, resources reused or created, environment-variable

names by preview/production scope, test results, skipped live work, and any

manual access step. A partial run still needs this report; silent stops are not

useful.

Guardrails

• Never infer live-billing approval.
• Never register a domain or spend money without the required user approval.
• Never expose API tokens, signing secrets, or credential-store details.
• Keep identity, deployment, and billing concerns in their respective skills.

Why

Commerce launches cross several systems. A fixed order keeps preview isolation and billing safety from becoming an afterthought.

How

Classify the project first, wire the narrowest needed layers, and use test credentials until the operator explicitly authorizes scoped live billing work.

Related

This coordinates Clerk + Cloudflare Auth, Cloudflare Commerce Deploy, and Stripe Commerce Checkout.