{
  "$schema": "https://ui.shadcn.com/schema/registry-item.json",
  "name": "agent-ready-installs",
  "type": "registry:block",
  "title": "Agent-Ready Installs",
  "description": "One-shot prompt packs and context files for coding assistants to install SaaS infrastructure safely.",
  "dependencies": [],
  "devDependencies": [],
  "registryDependencies": [],
  "files": [
    {
      "path": ".stackfoundry/context/agent-ready-installs.json",
      "type": "registry:file",
      "target": ".stackfoundry/context/agent-ready-installs.json",
      "content": "{\n  \"name\": \"agent-ready-installs\",\n  \"positioning\": \"Install production SaaS infrastructure as editable source.\",\n  \"primaryRecipe\": \"api-saas-starter\",\n  \"compatibleAgentSurfaces\": [\n    \"coding assistants\",\n    \"CLI-based coding agents\",\n    \"IDE-based coding agents\",\n    \"review automation\"\n  ],\n  \"oneShotPrompts\": [\n    {\n      \"name\": \"one-shot-api-saas\",\n      \"recipe\": \"api-saas-starter\",\n      \"path\": \".stackfoundry/prompts/one-shot-api-saas.md\",\n      \"useWhen\": \"The app needs API keys, usage, credits, billing, docs, and webhooks as editable source.\"\n    },\n    {\n      \"name\": \"one-shot-cloudflare-saas\",\n      \"recipe\": \"cloudflare-saas\",\n      \"path\": \".stackfoundry/prompts/one-shot-cloudflare-saas.md\",\n      \"useWhen\": \"The app needs a Cloudflare-native runtime, storage, queue, workflow, security, and deploy path.\"\n    },\n    {\n      \"name\": \"one-shot-minimal-saas\",\n      \"recipe\": \"saas-starter-minimal\",\n      \"path\": \".stackfoundry/prompts/one-shot-minimal-saas.md\",\n      \"useWhen\": \"The app needs a small SaaS foundation before heavier provider decisions.\"\n    },\n    {\n      \"name\": \"one-shot-enterprise-saas\",\n      \"recipe\": \"enterprise-saas\",\n      \"path\": \".stackfoundry/prompts/one-shot-enterprise-saas.md\",\n      \"useWhen\": \"The app needs enterprise auth, access, compliance, support, and incident surfaces.\"\n    },\n    {\n      \"name\": \"one-shot-ai-saas\",\n      \"recipe\": \"ai-saas-starter\",\n      \"path\": \".stackfoundry/prompts/one-shot-ai-saas.md\",\n      \"useWhen\": \"The app needs an AI product surface with metering, quotas, and cost controls.\"\n    },\n    {\n      \"name\": \"one-shot-customer-intelligence\",\n      \"recipe\": \"customer-intelligence\",\n      \"path\": \".stackfoundry/prompts/one-shot-customer-intelligence.md\",\n      \"useWhen\": \"The app needs customer health, event ingestion, usage, and risk visibility.\"\n    },\n    {\n      \"name\": \"one-shot-integration-marketplace\",\n      \"recipe\": \"integration-marketplace\",\n      \"path\": \".stackfoundry/prompts/one-shot-integration-marketplace.md\",\n      \"useWhen\": \"The app needs connected accounts, provider adapters, integration health, webhooks, and sync visibility.\"\n    },\n    {\n      \"name\": \"one-shot-security-center\",\n      \"recipe\": \"security-center\",\n      \"path\": \".stackfoundry/prompts/one-shot-security-center.md\",\n      \"useWhen\": \"The app needs a workspace security posture, data lifecycle, secrets, dependency, and audit control center.\"\n    },\n    {\n      \"name\": \"one-shot-support-ops\",\n      \"recipe\": \"support-ops\",\n      \"path\": \".stackfoundry/prompts/one-shot-support-ops.md\",\n      \"useWhen\": \"The app needs support, feedback, incident, on-call, postmortem, status, and health workflows.\"\n    }\n  ],\n  \"safeWorkflow\": [\n    \"Run stackfoundry recipe <name> before installing.\",\n    \"Run stackfoundry add recipe <name> --dry-run before writing files.\",\n    \"Review module manifests, source files, dependencies, env notes, and maintenance skills.\",\n    \"Install only after the diff is accepted.\",\n    \"Run the target app's Biome lint/format, TypeScript typecheck, migration, test, production build, and responsive smoke-check workflow.\",\n    \"Never commit secrets or local provider metadata.\"\n  ],\n  \"nextAppRouterRules\": [\n    \"Use route groups such as (marketing), (auth), (app), and (admin) to share layouts without changing URLs.\",\n    \"Keep public Route Handlers under app/api and do not colocate route.ts with page.tsx in the same segment.\",\n    \"Keep reusable business logic in src/lib/stackfoundry and schema in packages/db/src/schema instead of duplicating logic inside route files.\",\n    \"Use catch-all or optional catch-all routes only when one renderer or dispatcher truly owns nested paths with the same auth/runtime boundary.\",\n    \"Keep high-risk handlers such as billing webhooks, OAuth callbacks, deletion/export APIs, and provider-specific signature verification explicit.\"\n  ],\n  \"recommendedCommands\": {\n    \"inspectApiSaas\": \"pnpm stackfoundry recipe api-saas-starter\",\n    \"dryRunApiSaas\": \"pnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run\",\n    \"installApiSaas\": \"pnpm stackfoundry add recipe api-saas-starter --target ./my-app\",\n    \"dryRunMinimalSaas\": \"pnpm stackfoundry add recipe saas-starter-minimal --target ./my-app --dry-run\",\n    \"dryRunEnterpriseSaas\": \"pnpm stackfoundry add recipe enterprise-saas --target ./my-app --dry-run\",\n    \"dryRunAiSaas\": \"pnpm stackfoundry add recipe ai-saas-starter --target ./my-app --dry-run\",\n    \"dryRunCustomerIntelligence\": \"pnpm stackfoundry add recipe customer-intelligence --target ./my-app --dry-run\",\n    \"dryRunCloudflareSaas\": \"pnpm stackfoundry add recipe cloudflare-saas --target ./my-app --dry-run\",\n    \"dryRunIntegrationMarketplace\": \"pnpm stackfoundry add recipe integration-marketplace --target ./my-app --dry-run\",\n    \"dryRunSecurityCenter\": \"pnpm stackfoundry add recipe security-center --target ./my-app --dry-run\",\n    \"dryRunSupportOps\": \"pnpm stackfoundry add recipe support-ops --target ./my-app --dry-run\",\n    \"diffApiKeys\": \"pnpm stackfoundry diff api-keys --target ./my-app\",\n    \"validateRegistry\": \"pnpm registry:doctor\"\n  },\n  \"reviewChecklist\": [\n    \"Are target paths correct for this app?\",\n    \"Are provider adapters intentionally selected?\",\n    \"Are env vars documented without committing values?\",\n    \"Are schema and migration changes reviewed?\",\n    \"Are tests/checklists included for installed modules?\",\n    \"Did the target app pass its normal checks?\"\n  ]\n}\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-ai-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-ai-saas.md",
      "content": "# One-Shot Prompt: Ship a Complete AI SaaS Feature\n\nUse this prompt when an app needs a complete AI product surface with cost and usage controls.\n\n```text\nYou are taking this app to a completed AI SaaS endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app has an AI feature surface, chat primitives, model configuration, quota enforcement, usage metering, billing-ready cost controls, and optional AI discovery/edge building blocks. Expensive model calls are gated, observable, and safe to run behind auth.\n\nDefinition of done:\n- A user can access the AI UI/route and receive a streamed or completed response through configured server-side model code.\n- Quota and usage checks happen before expensive model calls.\n- Model/provider secrets are never exposed to the browser.\n- Usage records can connect to billing or entitlement decisions.\n- Biome lint/format, TypeScript typecheck, tests, production build, route-handler smoke checks, responsive chat UI checks, and manual streaming checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Put authenticated AI pages in `apps/web/src/app/(app)/ai` and marketing/demo pages in `apps/web/src/app/(marketing)` if demos are public.\n- Put streaming and model Route Handlers under explicit `apps/web/src/app/api/ai` paths, separate from UI pages.\n- Keep model routing, quota checks, usage capture, and prompt defaults in `apps/web/src/lib/stackfoundry/ai` so route handlers stay thin.\n- Put shared AI UI primitives in `apps/web/src/components/stackfoundry/ai`.\n- Use `apps/web/src/app/(app)/ai/[[...workspacePath]]/page.tsx` only when one AI workspace renderer handles nested threads/projects. Keep costly server routes explicit so auth, quota, and runtime choices are obvious.\n\nInstall workflow:\n1. Inspect the app's Next.js App Router structure, existing AI SDK usage, provider keys, auth boundary, usage records, billing model, and deploy platform.\n2. Run `pnpm stackfoundry recipe ai-saas-starter`.\n3. Run `pnpm stackfoundry add recipe ai-saas-starter --target ./my-app --dry-run`.\n4. Summarize model/provider assumptions, streamed routes, UI components, usage/cost controls, env vars, registry dependencies, and maintenance skills.\n5. Ask before installing if the app already has AI routes, chat UI, usage billing, or provider routing.\n6. Install after approval and review the diff for exposed provider keys, unbounded model calls, missing auth checks, and missing quota gates.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, route-handler smoke checks, responsive chat UI checks, and a manual streaming check when available.\n8. Finish with a cost-control handoff: what works, required provider env vars, which usage checks run, and what remains before production.\n\nExpected modules:\n`ai-sdk`, `ai-elements`, `ai-chat`, `ai-chatbot-sdk`, `usage-metering`, `quota-enforcement`, `cloudflare-agents-sdk`, `cloudflare-vectorize`, `cloudflare-kumo-ui`, and `ai-seo`.\n\nNever expose secret provider keys to the browser. Put metering and quota checks before expensive model calls.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-api-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-api-saas.md",
      "content": "# One-Shot Prompt: Ship a Complete API SaaS\n\nUse this prompt when a maintainer asks for a complete API-first SaaS workflow in an existing app.\n\n```text\nYou are taking this app to a completed API SaaS endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app can onboard a developer, issue and verify API keys, meter usage, enforce quotas, manage credits, connect Stripe billing and entitlements, publish API docs, receive and deliver webhooks, and show request visibility. The result must be editable source in the target app, not a black-box starter or hidden generator output.\n\nDefinition of done:\n- A maintainer can run the app and find the API key, usage, billing, docs, webhook, and request visibility surfaces.\n- Required env vars are documented in example/env notes without committed values.\n- Database/schema changes are reviewed and paired with migration guidance.\n- Provider adapters are explicit choices and do not become hidden base dependencies.\n- Biome lint/format, TypeScript typecheck, tests, production build, migration review, API/webhook smoke checks, and responsive UI checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Keep customer-facing pages in `apps/web/src/app/(marketing)` and authenticated product pages in `apps/web/src/app/(app)` so layouts stay DRY without changing URLs.\n- Put operator-only surfaces in `apps/web/src/app/(admin)/admin`, not mixed into user dashboard routes.\n- Put public API and webhook Route Handlers under `apps/web/src/app/api`, never in the same segment as a `page.tsx`.\n- Prefer feature code in `apps/web/src/lib/stackfoundry/api`, `apps/web/src/lib/stackfoundry/billing`, and `packages/db/src/schema` instead of duplicating logic inside route files.\n- Use `apps/web/src/app/(marketing)/docs/[[...slug]]/page.tsx` for docs when the docs renderer owns multiple nested docs pages.\n- Use `apps/web/src/app/api/v1/[[...path]]/route.ts` only for a shared public API dispatcher that validates method, auth, scope, quota, and path. Keep high-risk billing and webhook handlers explicit.\n\nInstall workflow:\n1. Inspect the app structure, App Router groups, package manager, database ownership, auth boundary, and existing billing/webhook/API code.\n2. Run `pnpm stackfoundry recipe api-saas-starter`.\n3. Run `pnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run`.\n4. Summarize proposed files, dependencies, env vars, registry dependencies, schema changes, docs, checklists, maintenance skills, and any path conflicts.\n5. Ask before writing files unless the user already approved the install.\n6. Install with `pnpm stackfoundry add recipe api-saas-starter --target ./my-app`.\n7. Review the diff and keep provider adapters explicit. Do not commit secrets, `.env.local`, provider credentials, generated caches, or local metadata.\n8. Run the app's Biome lint/format, TypeScript typecheck, tests, production build, migration review, API/webhook smoke checks, and responsive UI checks.\n9. Finish with a short handoff: what works, what env vars must be set, what migrations/checks were run, and what remains before production.\n\nExpected modules:\n`auth-core`, `tenant-context`, `api-keys`, `api-errors`, `rate-limits`, `usage-metering`, `quota-enforcement`, `credit-wallet`, `api-docs`, `webhook-inbox`, `webhook-delivery`, `billing-core`, `stripe-billing`, `plan-gating`, and `entitlements`.\n\nStop and ask if auth, database, package manager, deploy target, billing provider, or target paths are unclear.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-cloudflare-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-cloudflare-saas.md",
      "content": "# One-Shot Prompt: Ship a Complete Cloudflare SaaS\n\nUse this prompt when an app needs a Cloudflare-native SaaS path with edge runtime, storage, queues, workflows, and security primitives.\n\n```text\nYou are taking this app to a completed Cloudflare SaaS endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app has an intentional Cloudflare platform path: Workers/Pages runtime guidance, observability, D1/KV/R2/Hyperdrive data primitives, Queues/Workflows/Durable Objects coordination, Turnstile security, optional Workers AI/Vectorize/MCP pieces, and infrastructure notes. Bindings and provider setup should stay isolated and readable.\n\nDefinition of done:\n- A maintainer can see where runtime, data, coordination, security, AI, and infrastructure pieces belong.\n- Cloudflare bindings are documented and not hardcoded as secrets.\n- Local development and deploy expectations are clear.\n- Provider-specific setup remains isolated to adapter/source files.\n- Biome lint/format, TypeScript typecheck, tests, production build, responsive checks for installed setup/admin surfaces, and any Wrangler/deploy dry-run checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Keep the app's normal Next.js surfaces grouped as `apps/web/src/app/(marketing)`, `apps/web/src/app/(app)`, and `apps/web/src/app/(admin)` even when deploying through Cloudflare.\n- Put Cloudflare platform demos and setup pages under `apps/web/src/app/(admin)/admin/platform/cloudflare`.\n- Put Cloudflare-specific Route Handlers under explicit `apps/web/src/app/api/cloudflare` paths and keep bindings/adapters in `apps/web/src/lib/stackfoundry/providers/cloudflare`.\n- Keep Durable Object, Queue, Workflow, storage, and binding helpers outside route files so runtime assumptions are easy to review.\n- Use catch-all routes only for documentation/setup explorers such as `apps/web/src/app/(admin)/admin/platform/cloudflare/[[...section]]/page.tsx`. Do not hide queue consumers, webhooks, or security verification behind catch-all handlers.\n\nInstall workflow:\n1. Inspect the App Router groups, deploy target, existing Cloudflare config, storage usage, background jobs, and secrets/bindings strategy.\n2. Run `pnpm stackfoundry recipe cloudflare-saas`.\n3. Run `pnpm stackfoundry add recipe cloudflare-saas --target ./my-app --dry-run`.\n4. Summarize proposed runtime files, binding/env notes, storage modules, queues/workflows, security modules, infrastructure files, and path conflicts.\n5. Ask before installing if the app already has Workers, Pages, D1, KV, R2, Durable Objects, Queues, or Wrangler config.\n6. Install after approval, then review the diff for leaked secrets, global mutable state, unsafe bindings, and provider assumptions.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, responsive checks for installed setup/admin surfaces, and any available Cloudflare validation or build command.\n8. Finish with a deploy-readiness handoff: required bindings, local commands, deployment steps, checks run, and remaining blockers.\n\nExpected modules:\n`cloudflare-next-starter`, `cloudflare-workers`, `cloudflare-pages`, `cloudflare-observability`, `cloudflare-d1`, `cloudflare-kv`, `cloudflare-r2`, `cloudflare-hyperdrive`, `cloudflare-queues`, `cloudflare-workflows`, `cloudflare-durable-objects`, `cloudflare-turnstile`, `cloudflare-workers-ai`, `cloudflare-vectorize`, `cloudflare-mcp-server`, `cloudflare-terraform`, and `cloudflare-tunnel`.\n\nNever commit Cloudflare tokens, account IDs that are meant to stay private, generated `.wrangler` state, or local deployment metadata.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-customer-intelligence.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-customer-intelligence.md",
      "content": "# One-Shot Prompt: Ship Complete Customer Intelligence\n\nUse this prompt when a team needs complete customer health, adoption, usage, and risk visibility.\n\n```text\nYou are taking this app to a completed customer intelligence endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app can connect product analytics, large event ingestion, usage data, and account intelligence into customer health, risk, adoption, and expansion signals. Event capture should be intentional, privacy-aware, and usable by operators.\n\nDefinition of done:\n- Operators can identify customer usage, adoption, health, and risk signals from installed source surfaces or helpers.\n- Analytics and large-event ingestion paths avoid secrets, raw private customer data, and unbounded payloads.\n- Event names and payload shapes are documented well enough to maintain.\n- Provider env vars are documented without committed values.\n- Biome lint/format, TypeScript typecheck, tests, production build, responsive dashboard checks, ingestion smoke checks, and analytics/provider validation pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Put operator dashboards under `apps/web/src/app/(admin)/admin/customers` and authenticated account-level views under `apps/web/src/app/(app)`.\n- Put ingestion Route Handlers under explicit `apps/web/src/app/api/analytics` or provider-specific webhook paths.\n- Keep event schemas, capture helpers, customer health scoring, and provider clients in `apps/web/src/lib/stackfoundry/analytics` and `apps/web/src/lib/stackfoundry/customers`.\n- Keep database schema slices in `packages/db/src/schema`.\n- Use `apps/web/src/app/(admin)/admin/customers/[[...view]]/page.tsx` only for one DRY customer intelligence dashboard renderer. Keep event ingestion and provider callbacks explicit.\n\nInstall workflow:\n1. Inspect existing App Router groups, analytics providers, event naming, account/workspace model, billing usage records, support surfaces, and data retention expectations.\n2. Run `pnpm stackfoundry recipe customer-intelligence`.\n3. Run `pnpm stackfoundry add recipe customer-intelligence --target ./my-app --dry-run`.\n4. Summarize event flows, provider adapters, env vars, data ownership, privacy notes, and dashboard/source files.\n5. Ask before installing if analytics, warehouse, customer health, or billing usage models already exist.\n6. Install after approval, then review the diff for PII leakage, unbounded event payloads, duplicate event names, and missing consent notes.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, responsive dashboard checks, ingestion smoke checks, and any analytics provider dry-run or validation command.\n8. Finish with a data-quality handoff: what signals work, which env vars are required, what privacy checks were made, and what remains before production.\n\nExpected modules:\n`posthog-analytics`, `tinybird-analytics`, and `usage-metering`.\n\nKeep event payloads intentional. Do not send secrets, private customer data, or raw provider credentials through analytics ingestion.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-enterprise-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-enterprise-saas.md",
      "content": "# One-Shot Prompt: Ship Complete Enterprise SaaS Controls\n\nUse this prompt when a team needs a complete enterprise SaaS control layer.\n\n```text\nYou are taking this app to a completed enterprise SaaS endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app can support enterprise procurement with stronger access controls, SSO/SCIM boundaries, auditability, retention/export/deletion policies, SLA workflows, support operations, incident response, and public status communication. The result should be reviewable source code with clear auth and compliance boundaries.\n\nDefinition of done:\n- Admins can find enterprise identity, roles/permissions, MFA/security, audit, retention/export/deletion, SLA/support, incident, and status surfaces.\n- Protected routes, server actions, and route handlers have explicit authorization expectations.\n- Compliance-sensitive data flows are documented and do not commit customer data or secrets.\n- Provider setup remains adapter-based and is not hidden in the base scaffold.\n- Biome lint/format, TypeScript typecheck, tests, production build, migration review, responsive admin checks, auth smoke tests, and support/status route checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Keep enterprise admin surfaces under `apps/web/src/app/(admin)/admin` with a shared admin layout and explicit authorization checks.\n- Keep workspace user surfaces under `apps/web/src/app/(app)` and avoid mixing procurement/admin-only controls into ordinary dashboard pages.\n- Put SSO, SCIM, MFA, and lifecycle Route Handlers under explicit `apps/web/src/app/api` paths such as `api/scim`, `api/sso`, and `api/webhooks`.\n- Keep role, permission, audit, retention, and export logic in `apps/web/src/lib/stackfoundry/security` and `packages/db/src/schema`.\n- Use catch-all routes only for policy/document viewers such as `apps/web/src/app/(admin)/admin/security/policies/[[...slug]]/page.tsx`. Do not collapse SSO, SCIM, deletion, export, or webhook handlers into a catch-all.\n\nInstall workflow:\n1. Inspect existing App Router groups, auth, org/workspace model, roles, audit logs, support tooling, and incident/status surfaces.\n2. Run `pnpm stackfoundry recipe enterprise-saas`.\n3. Run `pnpm stackfoundry add recipe enterprise-saas --target ./my-app --dry-run`.\n4. Summarize route additions, schema slices, env notes, provider adapters, access-control assumptions, and checklist coverage.\n5. Ask before installing if the app already has SSO, SCIM, RBAC, audit, support, or status-page code.\n6. Install after approval, then review every protected route and server action for authorization boundaries.\n7. Verify that no secrets, customer data, local provider metadata, or generated caches were added.\n8. Run Biome lint/format, TypeScript typecheck, tests, production build, migration review, responsive admin checks, auth smoke tests, and any support/status route checks.\n9. Finish with a security-focused handoff: what works, what still needs provider setup, which checks ran, and which controls need human policy decisions.\n\nExpected modules:\n`auth-core`, `custom-roles`, `permission-matrix`, `enterprise-sso`, `scim-provisioning`, `mfa-security`, `audit-log`, `data-retention`, `data-export`, `account-deletion`, `secrets-management`, `sla-management`, `support-console`, `incident-management`, `status-page`, and `postmortem-runbook`.\n\nPrioritize authorization correctness and compliance notes over UI polish.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-integration-marketplace.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-integration-marketplace.md",
      "content": "# One-Shot Prompt: Ship a Complete Integration Marketplace\n\nUse this prompt when an app needs a user-facing integration marketplace with connection, permissions, health, webhook, and sync visibility.\n\n```text\nYou are taking this app to a completed integration marketplace endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app lets users connect external services, understand connection ownership and permissions, see integration health, review sync or webhook history, and operate adapter-specific flows without hardwiring providers into the base app.\n\nDefinition of done:\n- A user or admin can find connected-account and integration adapter surfaces.\n- OAuth/connection ownership and permission assumptions are explicit.\n- Webhook/sync health and failure states have a visible operating path.\n- Provider env vars are documented without committed values.\n- Biome lint/format, TypeScript typecheck, tests, production build, responsive settings/admin checks, webhook/OAuth callback smoke checks, and provider dry-runs pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Put user-facing integration settings under `apps/web/src/app/(app)/settings/integrations`.\n- Put admin/provider health surfaces under `apps/web/src/app/(admin)/admin/integrations`.\n- Put OAuth callbacks, provider webhooks, and sync Route Handlers under explicit `apps/web/src/app/api/integrations` paths.\n- Keep provider adapters, permission mapping, sync logs, and webhook verification in `apps/web/src/lib/stackfoundry/integrations`.\n- Use `apps/web/src/app/(app)/settings/integrations/[[...provider]]/page.tsx` only for one shared marketplace/detail renderer. Keep OAuth callbacks and webhooks explicit per provider when signatures or ownership rules differ.\n\nInstall workflow:\n1. Inspect existing App Router groups, auth, account/workspace model, integrations, OAuth callbacks, webhook routes, email/analytics providers, and sync jobs.\n2. Run `pnpm stackfoundry recipe integration-marketplace`.\n3. Run `pnpm stackfoundry add recipe integration-marketplace --target ./my-app --dry-run`.\n4. Summarize connection files, provider adapters, route handlers, env notes, ownership assumptions, webhook/sync paths, and path conflicts.\n5. Ask before installing if the app already has OAuth callbacks, connected accounts, integration settings, or provider webhook code.\n6. Install after approval and review the diff for leaked provider credentials, unsafe callback handling, missing ownership checks, and unclear permissions.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, responsive settings/admin checks, OAuth/webhook smoke checks, and any provider-specific validation available.\n8. Finish with an operator handoff: what integrations work, what provider setup is required, which callbacks/webhooks must be configured, and what remains before production.\n\nExpected modules:\n`connected-accounts`, `github-integration`, `resend-email`, and `posthog-analytics`.\n\nKeep each provider an adapter. Do not make one integration provider a hidden dependency of the whole app.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-minimal-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-minimal-saas.md",
      "content": "# One-Shot Prompt: Ship a Complete Minimal SaaS\n\nUse this prompt when an app needs the smallest complete SaaS foundation before heavier provider choices.\n\n```text\nYou are taking this app to a completed minimal SaaS endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app has a usable product shell, settings structure, database conventions, auth boundary, billing path, pricing surface, invoices path, audit trail, health checks, and security headers. It should feel like a small real SaaS app that can be extended, not a placeholder template.\n\nDefinition of done:\n- A maintainer can navigate the shell, settings, auth/account area, pricing/billing path, invoices path, health surface, and audit/security basics.\n- The app keeps provider choices visible and replaceable.\n- Env notes, schema/migration guidance, checklists, and maintenance skills are installed with the source.\n- Existing app code is not overwritten without explicit approval.\n- Biome lint/format, TypeScript typecheck, tests, production build, migration review, responsive checks, and smoke checks for shell/settings/billing/health pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Keep public pages in `apps/web/src/app/(marketing)` and authenticated SaaS pages in `apps/web/src/app/(app)` so the shell, nav, and loading/error boundaries are shared at the right level.\n- Put auth provider pages and callbacks in `apps/web/src/app/(auth)` or `apps/web/src/app/api/auth` depending on provider requirements.\n- Put admin-only operations in `apps/web/src/app/(admin)/admin` and shared UI in `apps/web/src/components/stackfoundry`.\n- Put reusable product config, navigation, and env helpers in `apps/web/src/lib/stackfoundry`, not inside route files.\n- Use catch-all routes sparingly: `apps/web/src/app/(app)/settings/[[...section]]/page.tsx` is acceptable for a DRY settings renderer, but keep billing, auth, and health routes explicit when they have different authorization or runtime behavior.\n\nInstall workflow:\n1. Inspect existing App Router groups, layouts, settings pages, auth provider, database package, and billing provider.\n2. Run `pnpm stackfoundry recipe saas-starter-minimal`.\n3. Run `pnpm stackfoundry add recipe saas-starter-minimal --target ./my-app --dry-run`.\n4. Summarize the source files, env notes, dependencies, registry dependencies, and likely path conflicts.\n5. Ask before installing if any shell, auth, billing, or database code already exists.\n6. Install only after the dry-run is accepted.\n7. Review the diff for duplicated shells, duplicate auth routes, misplaced database files, and provider assumptions.\n8. Run Biome lint/format, TypeScript typecheck, tests, production build, migrations, responsive checks, and smoke checks for the shell, settings, billing, and health routes.\n9. Finish with a concise launch-readiness summary: working surfaces, env/migrations required, verification run, and remaining blockers.\n\nExpected modules:\n`next-saas-shell`, `settings-layout`, `drizzle-postgres`, `tenant-context`, `auth-core`, `account-settings`, `account-modes`, `clerk-auth`, `billing-core`, `stripe-billing`, `pricing-page`, `invoices`, `audit-log`, `system-health`, and `security-headers`.\n\nKeep the base scaffold small. Treat providers as adapters, not hard dependencies.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-security-center.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-security-center.md",
      "content": "# One-Shot Prompt: Ship a Complete Security Center\n\nUse this prompt when a B2B SaaS app needs a visible security posture center and review workflow.\n\n```text\nYou are taking this app to a completed security center endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app exposes workspace security posture, MFA expectations, browser/API protections, secrets hygiene, dependency audit visibility, data retention/export/deletion controls, and audit history. The result should support enterprise security reviews without hiding important controls in provider dashboards only.\n\nDefinition of done:\n- Admins can find security posture, MFA, headers/CSRF/CORS, secrets, dependency audit, retention/export/deletion, and audit surfaces.\n- Sensitive security and data lifecycle behavior is documented.\n- Secrets are never committed and public env vars do not expose private values.\n- Risky access/data flows are reviewed before install is accepted.\n- Biome lint/format, TypeScript typecheck, tests, production build, migration review, responsive security-center checks, security header checks, and route smoke checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Put security center UI under `apps/web/src/app/(admin)/admin/security` with shared admin layout and authorization.\n- Keep user-facing security settings, if needed, under `apps/web/src/app/(app)/settings/security`.\n- Put security Route Handlers under explicit `apps/web/src/app/api/security` paths and keep webhook/callback handlers separate when providers require unique verification.\n- Keep policies, audit helpers, data lifecycle helpers, and secrets checks in `apps/web/src/lib/stackfoundry/security`.\n- Use `apps/web/src/app/(admin)/admin/security/[[...section]]/page.tsx` for a DRY security section renderer only if every section shares the same authorization boundary. Keep account deletion, export, and audit APIs explicit.\n\nInstall workflow:\n1. Inspect existing App Router groups, auth, workspace model, security headers, CSRF/CORS handling, secrets strategy, audit logs, data export/deletion, and dependency tooling.\n2. Run `pnpm stackfoundry recipe security-center`.\n3. Run `pnpm stackfoundry add recipe security-center --target ./my-app --dry-run`.\n4. Summarize security files, data lifecycle files, env notes, route changes, policy assumptions, schema changes, and path conflicts.\n5. Ask before installing if the app already has security center, compliance, audit, export, deletion, or security middleware code.\n6. Install after approval and review the diff for unsafe defaults, missing authorization checks, leaked secrets, and duplicated security policies.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, migration review, responsive security-center checks, security header checks, and any route/API smoke checks.\n8. Finish with a security-readiness handoff: enabled controls, required policy decisions, env/config setup, checks run, and production blockers.\n\nExpected modules:\n`mfa-security`, `security-headers`, `csrf-protection`, `cors-policy`, `secrets-management`, `dependency-audit`, `data-retention`, `data-export`, `account-deletion`, and `audit-log`.\n\nPrioritize correctness, explicit policy, and least privilege over broad UI coverage.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/one-shot-support-ops.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/one-shot-support-ops.md",
      "content": "# One-Shot Prompt: Ship Complete Support Ops\n\nUse this prompt when an app needs customer support, feedback, incident, on-call, and status workflows tied together.\n\n```text\nYou are taking this app to a completed support operations endpoint with StackFoundry source modules.\n\nTarget outcome:\nThe app gives operators customer context, support surfaces, bug reports, feature requests, roadmap visibility, incident management, on-call escalation, postmortem workflows, public status updates, and system health signals. Support should connect to incidents and roadmap decisions instead of living as disconnected pages.\n\nDefinition of done:\n- Operators can find support console/widget, bug reports, feature requests, roadmap, incidents, on-call, postmortems, status, and health surfaces.\n- Customer context and escalation paths are clear.\n- Incident/status workflows have visible ownership and update paths.\n- No private customer data, provider credentials, or generated local metadata are committed.\n- Biome lint/format, TypeScript typecheck, tests, production build, responsive support/status checks, route smoke checks, and incident/status workflow checks pass or have documented follow-up items.\n\nRecommended Next.js App Router structure:\n- Put operator support pages under `apps/web/src/app/(admin)/admin/support` and incident/status operations under `apps/web/src/app/(admin)/admin/operations`.\n- Put customer-facing support widgets or public roadmap/status pages under `apps/web/src/app/(marketing)` when they are public.\n- Put bug report, feature request, incident, and status Route Handlers under explicit `apps/web/src/app/api/support` or `apps/web/src/app/api/operations` paths.\n- Keep escalation, status, customer context, and feedback helpers in `apps/web/src/lib/stackfoundry/support` and `apps/web/src/lib/stackfoundry/operations`.\n- Use `apps/web/src/app/(admin)/admin/support/[[...queue]]/page.tsx` only for shared queue/detail rendering. Keep incident mutation APIs, status update APIs, and public status pages explicit.\n\nInstall workflow:\n1. Inspect existing App Router groups, support pages, admin console, customer/account model, feedback channels, incident workflow, status page, monitoring, and health checks.\n2. Run `pnpm stackfoundry recipe support-ops`.\n3. Run `pnpm stackfoundry add recipe support-ops --target ./my-app --dry-run`.\n4. Summarize support files, incident files, health/status files, env notes, ownership assumptions, and path conflicts.\n5. Ask before installing if the app already has support, feedback, roadmap, incidents, status, or on-call code.\n6. Install after approval and review the diff for private data leakage, missing authorization checks, duplicated support routes, and unclear escalation ownership.\n7. Run Biome lint/format, TypeScript typecheck, tests, production build, responsive support/status checks, route smoke checks, and any status/incident workflow validation available.\n8. Finish with an operations handoff: what support workflows work, which roles own them, which checks ran, and what remains before production.\n\nExpected modules:\n`support-console`, `support-widget`, `bug-reports`, `feature-requests`, `public-roadmap`, `incident-management`, `oncall-alerting`, `postmortem-runbook`, `status-page`, and `system-health`.\n\nKeep customer context useful but minimal. Do not expose private customer data in logs, public status pages, or feedback surfaces.\n```\n"
    },
    {
      "path": ".stackfoundry/prompts/install-api-saas.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/install-api-saas.md",
      "content": "# Agent Prompt: Install API SaaS Infrastructure\n\nYou are helping install StackFoundry infrastructure into an existing app.\n\nGoal: add the `api-saas-starter` recipe as editable source, not as a black-box starter.\n\nUse this workflow:\n\n1. Inspect the target app structure and package manager.\n2. Run:\n\n```bash\npnpm stackfoundry recipe api-saas-starter\npnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run\n```\n\n3. Summarize the proposed files, dependencies, env vars, registry dependencies, and maintenance skills.\n4. Ask for approval before writing files unless the user already approved install.\n5. Install with:\n\n```bash\npnpm stackfoundry add recipe api-saas-starter --target ./my-app\n```\n\n6. Review the resulting diff.\n7. Run the target app's Biome lint/format, TypeScript typecheck, migration, test, production build, and responsive smoke-check commands.\n8. Do not commit secrets, `.env.local`, provider credentials, generated caches, or local provider metadata.\n\nPrimary modules to expect:\n\n- `api-keys`\n- `usage-metering`\n- `quota-enforcement`\n- `credit-wallet`\n- `stripe-billing`\n- `webhook-inbox`\n- `webhook-delivery`\n- `api-docs`\n- `audit-log`\n\nIf paths, framework, package manager, auth provider, or database ownership are unclear, stop and ask before installing.\n"
    },
    {
      "path": ".stackfoundry/prompts/review-stackfoundry-install.md",
      "type": "registry:file",
      "target": ".stackfoundry/prompts/review-stackfoundry-install.md",
      "content": "# Agent Prompt: Review a StackFoundry Install\n\nYou are reviewing a StackFoundry install diff.\n\nPrioritize risks before summaries:\n\n- overwritten or misplaced target files\n- undeclared runtime dependencies\n- missing env documentation\n- provider credentials or secrets committed by mistake\n- schema changes without migration guidance\n- auth, billing, API key, webhook, or permission logic that is unsafe\n- modules installed without tests/checklists or maintenance skills\n\nCheck these commands when available:\n\n```bash\npnpm stackfoundry diff api-keys --target ./my-app\npnpm registry:doctor\npnpm lint:web\npnpm lint\npnpm typecheck:web\npnpm typecheck\npnpm test\npnpm build\n```\n\nReview output format:\n\n1. Findings, ordered by severity.\n2. Open questions.\n3. What installed successfully.\n4. Verification run and remaining gaps.\n\nDo not approve the install if secrets, local provider metadata, or generated caches are staged.\n"
    },
    {
      "path": "docs/stackfoundry/agent-ready-installs.md",
      "type": "registry:file",
      "target": "docs/stackfoundry/agent-ready-installs.md",
      "content": "# Agent-Ready StackFoundry Installs\n\nStackFoundry modules are designed for code review and coding-agent workflows. Coding assistants can inspect recipes, dry-run installs, review generated diffs, and keep the installed source maintainable.\n\n## Default Flow\n\n```bash\npnpm stackfoundry recipe api-saas-starter\npnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run\npnpm stackfoundry add recipe api-saas-starter --target ./my-app\npnpm stackfoundry diff api-keys --target ./my-app\n```\n\n## What Agents Should Read\n\n- `.stackfoundry/context/agent-ready-installs.json`\n- `.stackfoundry/prompts/install-api-saas.md`\n- `.stackfoundry/prompts/one-shot-api-saas.md`\n- `.stackfoundry/prompts/one-shot-cloudflare-saas.md`\n- `.stackfoundry/prompts/one-shot-minimal-saas.md`\n- `.stackfoundry/prompts/one-shot-enterprise-saas.md`\n- `.stackfoundry/prompts/one-shot-ai-saas.md`\n- `.stackfoundry/prompts/one-shot-customer-intelligence.md`\n- `.stackfoundry/prompts/one-shot-integration-marketplace.md`\n- `.stackfoundry/prompts/one-shot-security-center.md`\n- `.stackfoundry/prompts/one-shot-support-ops.md`\n- `.stackfoundry/prompts/review-stackfoundry-install.md`\n- module docs in `.stackfoundry/skills/**/SKILL.md`\n- module checklists in installed `tests/checklist.md` files\n\n## Safety Rules\n\n- Dry-run before writing files.\n- Review all source files, dependency metadata, env notes, and maintenance skills.\n- Keep provider adapters explicit.\n- Never commit secrets, `.env.local`, provider credentials, generated caches, or local provider metadata.\n- Run Biome lint/format, TypeScript typecheck, tests, production build, responsive smoke checks, and migration review after install.\n\n## Best First Path\n\nUse `api-saas-starter` first. It maps to the most concrete SaaS pain: API keys, usage tracking, quotas, credits, billing, docs, webhooks, and request visibility as editable source.\n\n## One-Shot Prompts\n\nUse these prompts when a maintainer asks a coding agent to run a complete recipe workflow and finish with a working SaaS endpoint:\n\n- `one-shot-api-saas.md`: front-door API SaaS path.\n- `one-shot-minimal-saas.md`: compact app foundation.\n- `one-shot-enterprise-saas.md`: enterprise identity, compliance, support, and incident path.\n- `one-shot-ai-saas.md`: AI product surface with metering and quota controls.\n- `one-shot-customer-intelligence.md`: analytics, event ingestion, usage, and account intelligence.\n- `one-shot-cloudflare-saas.md`: Cloudflare runtime, storage, queues, workflows, security, and deploy path.\n- `one-shot-integration-marketplace.md`: connected accounts, provider adapters, permissions, health, and sync visibility.\n- `one-shot-security-center.md`: security posture, data lifecycle, controls, secrets, and audit center.\n- `one-shot-support-ops.md`: support, feedback, incidents, on-call, postmortems, status, and health workflows.\n\nEach prompt tells the agent to inspect the target app, run the recipe inspection command, dry-run before writing, summarize risks, ask before install, review the diff, run the target app's checks, and finish with a handoff that says what works and what remains before production.\n\n## App Router Structure Rules\n\n- Use route groups such as `(marketing)`, `(auth)`, `(app)`, and `(admin)` to share layouts without changing URLs.\n- Keep public Route Handlers under `app/api`; do not place `route.ts` next to `page.tsx` in the same segment.\n- Keep reusable product logic in `src/lib/stackfoundry` and schema in `packages/db/src/schema`.\n- Use `[[...slug]]` or `[...path]` only when one renderer or dispatcher owns nested paths with the same auth/runtime boundary.\n- Keep billing webhooks, OAuth callbacks, deletion/export APIs, and provider-specific signature verification explicit.\n"
    }
  ],
  "maintenanceSkills": [
    {
      "name": "agent-ready-installs",
      "target": ".stackfoundry/skills/agent-ready-installs/SKILL.md",
      "content": "---\nname: agent-ready-installs\ndescription: Maintain agent-ready StackFoundry install prompt packs and context files.\n---\n\n# Agent-Ready Installs Maintenance Instructions\n\n- Keep prompts focused on dry-run, install, review, and verification workflows.\n- Keep tool references compatible with generic coding assistants and avoid tool-specific assumptions.\n- Do not add secrets, user-specific paths, local provider metadata, or generated caches.\n- Keep `api-saas-starter` as the default first path unless public positioning changes.\n- Update docs, prompt files, module manifests, and context JSON together.\n- One-shot prompts must map to real `registry/recipes/*.json` files and should name the expected modules.\n- Each one-shot prompt should define the completed SaaS endpoint, tell the agent to inspect first, dry-run before writing, ask before install when boundaries are unclear, review the diff, run the target app's checks, and finish with a production-readiness handoff.\n- Each one-shot prompt should include a Next.js App Router structure section with route groups, explicit `app/api` Route Handler guidance, shared `src/lib/stackfoundry` ownership, and careful catch-all usage.\n- Verification guidance should explicitly include Biome lint/format, TypeScript typecheck, tests, production build, and responsive smoke checks.\n\n## Verification\n\n- `pnpm registry:doctor`\n- `pnpm stackfoundry add agent-ready-installs --target /tmp/stackfoundry-agent-ready --dry-run`\n- Confirm installed prompt files are generic and safe to commit.\n"
    }
  ],
  "envVars": {},
  "docs": "# Agent-Ready Installs\n\nPrompt packs and context files for coding agents to install SaaS infrastructure safely.\n\nThis module makes StackFoundry's source registry easier to operate from coding-agent environments. It gives agents a stable prompt pack, context JSON, and review checklist for dry-running, installing, and verifying infrastructure modules.\n\n## Owns\n\n- `.stackfoundry/context/agent-ready-installs.json`\n- `.stackfoundry/prompts/install-api-saas.md`\n- `.stackfoundry/prompts/one-shot-api-saas.md`\n- `.stackfoundry/prompts/one-shot-cloudflare-saas.md`\n- `.stackfoundry/prompts/one-shot-minimal-saas.md`\n- `.stackfoundry/prompts/one-shot-enterprise-saas.md`\n- `.stackfoundry/prompts/one-shot-ai-saas.md`\n- `.stackfoundry/prompts/one-shot-customer-intelligence.md`\n- `.stackfoundry/prompts/one-shot-integration-marketplace.md`\n- `.stackfoundry/prompts/one-shot-security-center.md`\n- `.stackfoundry/prompts/one-shot-support-ops.md`\n- `.stackfoundry/prompts/review-stackfoundry-install.md`\n- `docs/stackfoundry/agent-ready-installs.md`\n\n## Best First Path\n\n```bash\npnpm stackfoundry recipe api-saas-starter\npnpm stackfoundry add recipe api-saas-starter --target ./my-app --dry-run\n```\n\n## One-Shot SaaS Prompts\n\nUse the one-shot prompts when a maintainer wants an agent to execute a whole recipe workflow with the right boundaries and a completed SaaS endpoint:\n\n- `one-shot-api-saas.md`: complete API keys, usage, quotas, credits, billing, docs, and webhooks.\n- `one-shot-minimal-saas.md`: complete small app shell, settings, database, auth, billing, health, and security.\n- `one-shot-enterprise-saas.md`: complete SSO, SCIM, RBAC, audit, retention, support, incidents, and status.\n- `one-shot-ai-saas.md`: complete AI SDK routes, chat UI, metering, quota enforcement, and cost controls.\n- `one-shot-customer-intelligence.md`: complete analytics, large event ingestion, usage, and account health.\n- `one-shot-cloudflare-saas.md`: complete Cloudflare runtime, storage, queues, workflows, security, and deploy path.\n- `one-shot-integration-marketplace.md`: complete connected accounts, adapters, permissions, health, and sync visibility.\n- `one-shot-security-center.md`: complete security posture, controls, data lifecycle, and audit center.\n- `one-shot-support-ops.md`: complete support, feedback, incidents, on-call, postmortems, status, and health workflows.\n\nEach prompt includes Next.js App Router structure guidance. Route groups such as `(marketing)`, `(auth)`, `(app)`, and `(admin)` keep layouts DRY without changing URLs. Catch-all routes are recommended only for shared renderers or dispatchers with the same auth and runtime boundary; high-risk handlers stay explicit under `app/api`.\n\nEach prompt also asks the installer to run Biome lint/format, TypeScript typecheck, tests, production build, and responsive smoke checks after source lands.\n\n## Maintenance\n\n- Keep prompts product-focused and tool-neutral.\n- Coding assistants should all be able to follow the same workflow without tool-specific assumptions.\n- Keep the API SaaS recipe as the first install path.\n- Never include secrets, user-specific metadata, or local provider state.\n",
  "meta": {
    "category": "developer-platform",
    "env": [],
    "status": "ready",
    "maturity": "ready",
    "recommendedFor": []
  }
}