AI Prompt Packs

These prompts give buyers reusable AI workflows that start from the right source paths and keep risky boundaries explicit.

On this page

Account and profile feature prompt

AI prompt
You are maintaining the account and profile domain. Change <account workflow> for <actor>.

Context:
- User outcome: <what the person needs to do>
- Acceptance criteria: <observable success conditions>
- Non-goals: <behavior that must remain unchanged>
- Environment: <local, preview, or production-like>

Inspect first: the profile action, session profile loader, persistence helper, route guard, schema, RLS/migration impact, and nearby tests. Summarize current identity and ownership behavior before editing.

Implement the smallest complete change. Preserve server-owned identity, validate and normalize input at the boundary, derive ownership from the authenticated session, avoid trusting client-supplied profile ids, keep authorization on the server, and do not leak private profile fields. Add regression coverage for unauthenticated access, invalid input, cross-user access, and partial failure when relevant.

Return the plan, changed files and reasons, invariants preserved, tests and exact commands with results, manual checks, migration or env follow-up, and remaining risks. If the desired behavior conflicts with an existing permission or data contract, stop and ask for the product decision.
Inspect first
  • src/features/account/server/actions/profile.ts
  • src/lib/auth/session/profile.ts
  • src/features/account/server/persistence/profile.ts
  • src/lib/auth/guards/route.ts

Verify

  • pnpm run test:features
  • pnpm run quality

Billing and payment feature prompt

AI prompt
You are maintaining the billing domain. Change <billing workflow> for <customer or operator>.

Context:
- Commercial outcome: <what the customer buys or manages>
- Provider and mode: <Stripe or Lemon Squeezy; test or live>
- Acceptance criteria: <setup, checkout, portal, entitlement, or history behavior>
- Non-goals: <catalog, pricing, tax, or subscription behavior that must not change>

Inspect provider selection, catalog configuration, setup/readiness checks, checkout service, claim/idempotency state, webhook route, signature verification, event processor, customer projection, and nearby tests. Trace the provider event to the local billing state before editing.

Preserve catalog/provider consistency, server-owned pricing, webhook signature verification, event idempotency, duplicate and out-of-order handling, retry-safe projections, request-id/provider-event logging, and customer-safe error messages. Never use a UI-only entitlement check, accept unverified provider payloads, or modify live billing data from a test-mode change. Add regression coverage for invalid price or provider, duplicate events, retries, and partial updates when relevant.

Return the plan, changed files, contract and schema impact, exact verification commands and results, provider test-mode steps, migration/env/webhook follow-up, repair or rollback plan, and remaining risks. Stop when a catalog or commercial decision is missing.
Inspect first
  • src/features/billing/server/runtime/provider.ts
  • src/features/billing/server/catalog/configuration.ts
  • src/features/billing/server/runtime/readiness.ts
  • src/features/billing/server/checkout/service.ts
  • src/app/api/webhooks/stripe/billing/route.ts
  • src/lib/security/webhooks/processing.ts

Verify

  • pnpm run test:features
  • pnpm run quality
  • Open /billing/setup.

Email and notification prompt

AI prompt
You are maintaining the application email and notification domain. Change <notification workflow> for <recipient and trigger>.

Context:
- User outcome: <what the recipient should receive or understand>
- Event and delivery mode: <event, immediate or queued, provider>
- Acceptance criteria: <content, recipient, status, and retry behavior>
- Non-goals: <templates, preferences, or transport behavior that must not change>

Inspect event definitions, delivery registry, runtime templates, default templates, recipient resolution, outbox persistence and worker, provider adapter, webhook request handling, and nearby tests. State where the durable delivery state lives and how duplicate delivery is prevented.

Preserve template validation, recipient privacy, retry and dead-letter state, duplicate-safe delivery, provider boundaries, webhook signature verification, idempotent status projection, and no-secret structured logging. Keep provider SDK shapes out of UI code. Add regression coverage for invalid templates, missing recipients, transient failure, duplicate events, webhook replay, and permanent failure when relevant.

Return the plan, changed files and reasons, event/state transitions, exact commands and results, provider or webhook test steps, migration/env follow-up, operational recovery steps, and remaining risks. Do not claim delivery from a local enqueue alone.
Inspect first
  • src/features/notifications/shared/events/registry.ts
  • src/features/notifications/server/events/dispatch.ts
  • src/features/notifications/server/templates/services/runtime.ts
  • src/features/notifications/shared/templates/defaults.ts
  • src/features/notifications/server/outbox/services/worker.ts
  • src/lib/security/webhooks/request.ts

Verify

  • pnpm run test:features
  • pnpm run quality

Admin and permissions prompt

AI prompt
You are maintaining an admin or team-permissions workflow. Change <admin workflow> for <actor>.

Context:
- Administrative outcome: <what authorized staff should be able to do>
- Roles and scope: <who can do it and which records are in scope>
- Acceptance criteria: <allowed and denied outcomes>
- Non-goals: <roles, navigation, or audit behavior that must not change>

Inspect the route guard, RBAC feature map, navigation config, permissions service, invite or mutation action, audit logger, persistence/RLS, and nearby tests. Separate visibility from authorization and describe the current fail-closed path before editing.

Preserve fail-closed authorization on the server for every mutation and sensitive read, use canonical roles only, validate target ownership and scope, prevent privilege escalation, keep UI checks as presentation only, and log meaningful actor, target, result, and request identifiers without secrets or unnecessary personal data. Add regression coverage for unauthenticated, authenticated-but-denied, cross-scope, invalid input, and duplicate invite or mutation cases when relevant.

Return the plan, changed files, permission matrix, audit impact, exact commands and results, manual role checks, migration/env follow-up, and remaining risks. Stop if the desired role semantics are not defined.
Inspect first
  • src/lib/auth/guards/route.ts
  • src/lib/auth/rbac/features.ts
  • src/lib/auth/rbac/nav-config.ts
  • src/features/team/server/access/services/permissions.ts
  • src/features/team/server/access/actions/staff-invites.ts
  • src/lib/audit/log.ts

Verify

  • pnpm run test:features
  • pnpm run quality

CMS and content prompt

AI prompt
You are maintaining the content and CMS domain. Change <content workflow> for <editor, reviewer, or visitor>.

Context:
- Content outcome: <what can be authored, reviewed, published, or viewed>
- Content kind and lifecycle: <kind, draft/review/published behavior>
- Acceptance criteria: <observable editor and public behavior>
- Non-goals: <content types, URLs, or publishing rules that must not change>

Inspect content-kind definitions, editor action, editor upsert service, shared validation, persistence/RLS, route usage, metadata builders, and nearby tests. Trace draft-to-public behavior and existing URL/slug ownership before editing.

Preserve slug uniqueness, publish status and authorization behavior, validation and normalization, server-owned writes, safe rendering, generated metadata, stable public URLs, and cache or revalidation semantics. Add regression coverage for invalid content, duplicate slugs, unauthorized publishing, draft visibility, and partial update when relevant.

Return the plan, changed files, content state transitions, exact commands and results, browser checks for editor and public views, migration/env/generated-artifact follow-up, and remaining risks. Do not silently change a public URL or publish rule.
Inspect first
  • src/features/cms/shared/documents/kinds.ts
  • src/features/cms/server/documents/actions/editor.ts
  • src/features/cms/server/documents/services/editor-upsert.ts
  • src/features/cms/shared/editor/validation/validation.ts
  • src/lib/seo/metadata/builders.ts

Verify

  • pnpm run test:features
  • pnpm run quality

Waitlist and lead-capture prompt

AI prompt
You are maintaining the public waitlist or lead-capture workflow. Change <lead capture workflow> for <visitor, lead, or operator>.

Context:
- Conversion outcome: <what the visitor submits or confirms>
- Mode and consent: <single opt-in, double opt-in, notifications, or disabled mode>
- Acceptance criteria: <success, duplicate, confirmation, and operator outcomes>
- Non-goals: <fields, retention, or notification behavior that must not change>

Inspect payload schemas, route-facing action, submit service, persistence helper, settings, rate-limit policy, bot protection, confirmation token handling, notification side effects, export behavior, and nearby tests. Identify where personal data is validated, stored, rate-limited, and exposed.

Preserve validation and normalization, duplicate handling, bot resistance, settings toggles, request context, privacy-safe errors, confirmation-token consumption, rate limits, spreadsheet-safe exports, and notification idempotency. Add regression coverage for invalid payloads, duplicates, abuse limits, disabled mode, expired or replayed confirmation, and authorized export when relevant.

Return the plan, changed files, data/privacy impact, exact commands and results, browser/API checks, migration/env follow-up, operational recovery notes, and remaining risks. Do not weaken abuse controls to improve a happy-path demo.
Inspect first
  • src/features/waitlist/server/signup/schemas/payload.ts
  • src/features/waitlist/server/signup/actions/submit-route.ts
  • src/features/waitlist/server/signup/services/submit.ts
  • src/features/waitlist/server/signup/persistence/signups.ts
  • src/features/waitlist/server/settings.ts
  • src/lib/security/rate-limit/policy.ts

Verify

  • pnpm run test:features
  • pnpm run quality

Settings and branding prompt

AI prompt
You are maintaining the settings and branding configuration domain. Change <configuration workflow> for <owner or admin>.

Context:
- Configuration outcome: <what can be configured and where it appears>
- Input and scope: <settings, tenant, environment, or public/private surface>
- Acceptance criteria: <saved, normalized, rendered, and fallback behavior>
- Non-goals: <env names, URLs, uploads, or defaults that must not change>

Inspect website settings actions, settings schemas, normalizers, defaults, branding settings, upload media types, public config, route guards, persistence/RLS, and nearby tests. Identify which values are runtime settings versus deployment env values before editing.

Preserve canonical env names, safe production URLs, server-side authorization, upload validation and size/type limits, settings normalization, safe defaults, cache invalidation, and separation between public configuration and server-only secrets. Add regression coverage for invalid URLs, unauthorized updates, unsupported media, normalization, and missing optional values when relevant.

Return the plan, changed files, config ownership map, exact commands and results, browser checks, migration/env follow-up, rollback or default-reset path, and remaining risks. Never move a secret into a public or NEXT_PUBLIC_ setting.
Inspect first
  • src/features/settings/server/actions/website-settings.ts
  • src/features/settings/server/schemas/settings.ts
  • src/features/settings/server/normalizer/settings-normalizer.ts
  • src/features/settings/server/config/defaults.ts
  • src/features/branding/shared/settings.ts
  • src/lib/uploads/media-types.ts
  • src/lib/config.ts

Verify

  • pnpm run test:features
  • pnpm run quality