Claude Code 部署 AI 應用前可要求檢查的 7 項事項

You built an app or a game with an AI assistant. It works on your laptop. Before you send the link to anyone, spend ten minutes on the things that usually go wrong after launch, not while you are building.

Here are seven checks you can paste into Claude Code (or Cursor, or any assistant that can read your project folder). Each one is written to be read-only: it asks the assistant to look and report, not to change anything.

Two rules before you start:

• Read-only. If your tool has a plan or ask mode, use it. Every prompt below says "don't fix it". Keep it that way until you have read the report.
• An AI review is not an audit. It will miss things. For anything that matters, have a person look too.

1. Keys and passwords in your code

Find API keys, passwords and tokens written directly in my code or config files. Report only the file path and the kind of secret, never the value, and do not open .env files. If this is a git repository, check the history too (all branches) and tell me if there is no git. Separate keys that are public by design (for example a Stripe key starting with pk_) from ones that must stay secret. Point out secret-looking values that end up in browser code (variables starting with NEXT_PUBLIC_, VITE_, and similar). Do not fix anything.

Why: a key that was ever pushed to a public repository should be treated as leaked, even if you deleted it later. The fix is to revoke it and create a new one.

2. Who can see or change what

List every page and API endpoint that works without logging in, as a table. Flag any that return personal data or another user's data, and any where changing a number or id in the address shows someone else's record. Check that actions only logged-in users should do (edit, delete, pay, admin) are enforced on the server or in database rules, not just hidden in the page. If I use Supabase or Firebase, check whether row level security or the security rules are on, and tell me what you cannot verify from the code. Do not send any request to a running server. Do not fix anything.

Why: a button hidden in the page does not protect anything. Anyone can call the address behind it directly.

3. What breaks on a real server

Tell me the build command, start command, runtime version and port this app needs, and list every environment variable it reads (names and purposes only, no values). List what must change once it has a real address: localhost or http:// URLs, login callback URLs, allowed origins, webhook URLs. Find development leftovers: debug mode, test accounts, default admin passwords (where, not the values), verbose error pages. Do not run any build, install or migration. Do not fix anything.

Why: "works on my computer" fails most often because of a missing setting or an address that only exists on your machine.

4. Will you know when it breaks?

Check whether I would find out when something fails after launch: error handling, logging, a health-check endpoint, alerts. If you do not know where I will host it, explain the main cases (serverless, container or server, static hosting). Suggest the simplest ways to get notified, as options. Do not change code.

Why: after launch, errors reach you only if you set something up. Otherwise you hear about them from a visitor, or not at all.

5. What could make the bill explode?

Find every place where usage costs money: AI API calls, database queries, file storage, email or SMS sending, scheduled jobs. For each, check whether it needs login, whether there is a limit per user, and whether input length and file size are capped. Pay special attention to AI endpoints a stranger can call. Tell me where to set monthly spending limits and billing alerts at each provider. Do not fix anything.

Why: a limit in the page is not a limit. If an AI endpoint is open to the internet, strangers can spend your money.

6. Where does the data live?

Tell me where this app stores data (database, files, in-memory state, browser storage), and what would be lost on a restart or redeploy. Check whether the same database could end up used for development and production, and whether migrations or seed scripts run automatically. Tell me what to back up and how I would go back to the previous version if a release goes wrong. Look at structure only; do not open real data. Do not fix anything.

Why: many hosts give your app a disposable disk. Files saved by the app can disappear on the next deploy.

7. A checklist for the first 30 minutes after launch

Read this project and write me a short checklist to follow right after it goes live: open the site in a private window and on a phone, sign up with a brand-new account, check that confirmation and password-reset emails arrive, run the app's main flow end to end, check the payment flow with a test card if there is one, see what visitors see on an error page, know where the logs are, and know how to roll back.

Why: the first thirty minutes catch the problems that only show up with a stranger's account on a real address.

Prefer a command?

I put these seven checks, plus an optional one for payments and personal data, into a free open-source Claude Code plugin. It restricts the assistant to reading, never prints secret values, and ends every report with what it could not verify.

claude plugin marketplace add ym2629/lavela-preflight
claude plugin install lavela-preflight@lavela

Then run /lavela-preflight:all in your project folder. Source and details: https://github.com/ym2629/lavela-preflight

I tested two of the checks (secrets and access) on a small app with deliberately planted weaknesses: fake keys in the browser code and in git history, an endpoint that returns any user's record, and an admin action protected only by a hidden button. They found every planted weakness in their scope, with file and line, and printed none of the fake secrets. It is still an AI review, so treat the output as a starting point.

I work on lavela, a service that lets an AI agent deploy an app from a GitHub repository and report on it afterwards. These prompts and the plugin work on any project and do not need it.