A. Security & Data Safety · Prompt 11

Pre-Deploy Production Readiness Check

Get the free PDF

Why it matters

Many launch incidents are missing safeguards a short checklist would have caught before the first real user.

Modeled on

Production-readiness checks engineering teams run before a release.

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
Read the report. Keep the IDs you agree with.
Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Pre-Deploy Production Readiness Check: what to check
Walk these checks against the repo and say pass, fail, or needs manual check. Do not change config in this pass.
1. List required environment variables and whether startup fails clearly when one is missing, or continues and breaks later.
2. Confirm debug flags default to off, and that routes named test, debug, or seed are not registered in the production build. Show the router file.
3. Look for security headers: X-Content-Type-Options, X-Frame-Options or CSP frame-ancestors, Strict-Transport-Security, and a Content-Security-Policy. Say where they are set (app or host config).
4. Check CORS. Flag Access-Control-Allow-Origin: * combined with credentials. A public API with no cookies can allow a wildcard. An API that uses cookies should not.
5. Say whether HTTP redirects to HTTPS and whether cookies are marked Secure. Host-level redirects may be Needs manual check.
6. Say whether the database connection string uses TLS and is not a default password. Reachability of the port is Needs manual check if you cannot see the network rules.
7. Say whether the repo or docs mention backups and a tested restore. If they do not, mark it as a gap I must confirm in the host console. Do not claim a backup exists because a vendor offers one.
8. Confirm a lockfile is present so installs are reproducible. Name the file.
9. Say whether there is a health-check route and where uptime would be monitored. Monitoring outside the repo is Needs manual check.
10. Say whether a previous version can be redeployed, based on the host config in the repo (for example Firebase Hosting releases or a platform rollback command). If it is only a console button, mark Needs manual check.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P11, for example P11-1, P11-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Get the free PDF

Related prompts

Share this prompt

WhatsApp LinkedIn X

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.

Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.

Read the report. Keep the IDs you agree with.

Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.

Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.

Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.

Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands that change anything: no installs, migrations, git commits, deploys, or "--fix" flags. If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt. Before you start: - Tell me the stack you detect (framework, language, database, auth, hosting, payment provider) and which folders you will review. - If a check below does not apply to this stack, write "Not applicable" and why. - If you can run read-only commands, run the ones listed. If you cannot, list them so I can run them and paste the output. Pre-Deploy Production Readiness Check: what to check Walk these checks against the repo and say pass, fail, or needs manual check. Do not change config in this pass. 1. List required environment variables and whether startup fails clearly when one is missing, or continues and breaks later. 2. Confirm debug flags default to off, and that routes named test, debug, or seed are not registered in the production build. Show the router file. 3. Look for security headers: X-Content-Type-Options, X-Frame-Options or CSP frame-ancestors, Strict-Transport-Security, and a Content-Security-Policy. Say where they are set (app or host config). 4. Check CORS. Flag Access-Control-Allow-Origin: * combined with credentials. A public API with no cookies can allow a wildcard. An API that uses cookies should not. 5. Say whether HTTP redirects to HTTPS and whether cookies are marked Secure. Host-level redirects may be Needs manual check. 6. Say whether the database connection string uses TLS and is not a default password. Reachability of the port is Needs manual check if you cannot see the network rules. 7. Say whether the repo or docs mention backups and a tested restore. If they do not, mark it as a gap I must confirm in the host console. Do not claim a backup exists because a vendor offers one. 8. Confirm a lockfile is present so installs are reproducible. Name the file. 9. Say whether there is a health-check route and where uptime would be monitored. Monitoring outside the repo is Needs manual check. 10. Say whether a previous version can be redeployed, based on the host config in the repo (for example Firebase Hosting releases or a platform rollback command). If it is only a console button, mark Needs manual check. Evidence rules: - Every finding cites a file path and line number, or the exact command output used. - Mark each finding Confirmed (seen in the code) or Needs manual check (depends on something outside the repo, such as a dashboard setting or production data). - Never print a full secret. Show the first 4 characters and the location only. - If you are not sure, say so. Do not invent files, settings, or results. Severity: Critical = exploitable now, or leaks real data or money. High = serious with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene. Report: - Summary: count of findings by severity. - Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort (IDs for this prompt use the prefix P11, for example P11-1, P11-2.) - Checked and fine: what you verified is already OK. - Could not check: what I need to look at myself, and where. Then stop. Do not fix anything. Ask me which IDs I want fixed.