AI coding tools make it easy to build without fully understanding the project commands.
That is fine while exploring.
It is risky before launch.
Your package.json scripts are the closest thing your app has to a pre-flight checklist. They tell you how the project expects to be linted, tested, compiled, generated, checked and started.
Before sharing a link publicly, you should know which commands matter and what each one proves.
Start with package.json
Open package.json and look at scripts.
Common scripts include:
{
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "eslint",
"test": "vitest",
"typecheck": "tsc --noEmit"
}
}
Do not assume your project has all of these. AI builders often create different names, skip tests, or wire commands through a framework.
Ask your agent:
Read package.json and explain every script in plain English.
For each script, tell me:
- when I should run it
- what it proves
- what kind of launch risk it catches
- whether it is mandatory before production
- what to do if it fails
This turns mystery commands into a launch checklist.
npm run lint
Run:
npm run lint
Linting checks whether your code follows the rules configured for the project.
Depending on the setup, it can catch:
- unused imports
- invalid React hook usage
- accessibility mistakes
- unsafe dependencies in browser code
- missing alt text
- inconsistent patterns
- likely bugs hidden by happy-path testing
If lint fails, do not blindly ask an AI agent to "fix lint." That can produce cosmetic changes that hide real issues.
Use this prompt:
Review the lint output.
For each issue:
- explain the actual risk
- say whether it is a real bug, accessibility issue, security concern, or style issue
- propose the smallest safe fix
- do not disable rules unless there is a clear reason
npx tsc --noEmit
Run:
npx tsc --noEmit
This checks TypeScript without writing build output.
It catches a different class of issue from lint:
- wrong property names
- missing null checks
- invalid function arguments
- mismatched API response shapes
- assumptions about database fields
- incorrect component props
AI-generated code often "looks right" while passing the wrong shape between layers.
TypeScript is the cheap way to catch that before production.
npm run build
Run:
npm run build
This is the most important pre-launch command.
Development mode can hide issues that production will reject. A production build can catch:
- server/client component mistakes
- invalid dynamic imports
- missing environment variables
- pages that fail during static generation
- unsupported browser APIs on the server
- broken metadata or route params
- database client generation problems
If the build fails, the app is not launch-ready.
Use this prompt:
The production build failed.
Explain the first root-cause error, not every downstream error.
Tell me which file likely needs changing, why production catches this when dev may not, and propose the smallest safe fix.
npm audit
Run:
npm audit
This checks your dependency tree for known vulnerabilities.
It does not mean every warning is exploitable in your app. It does mean you should understand the risk before launching.
Good audit triage asks:
- is this dependency used in production?
- is the vulnerable code reachable?
- is there a safe patch version?
- would
npm audit fix --forceintroduce breaking changes? - is the package unnecessary?
Use this prompt:
Triage this npm audit output.
For each vulnerability:
- explain whether it affects production code
- identify the dependency path
- recommend update, replace, remove, or accept
- warn me before any breaking upgrade
Add a smoke test
Even if you do not have a full test suite, you can still smoke test the launch path:
- homepage loads
- signup or waitlist works
- login works if the app has auth
- checkout opens if the app has payments
- dashboard loads for a test user
- important public pages return 200
- key forms show errors when invalid
Ask your agent:
Create a manual smoke test checklist for this app.
Focus on the smallest set of user actions that prove the launch flow works:
homepage, signup, login, payment, dashboard, contact, and error states.
Include expected result and what to capture if a step fails.
What PageLens adds
Local commands check the repo.
PageLens checks the live site.
That distinction matters. A clean build does not prove your Open Graph image works, your security headers are present, your mobile tap targets are usable, or your public pages explain themselves clearly.
Use both.
The command checklist tells you whether the codebase is internally healthy.
The PageLens scan tells you whether the launched surface looks ready from the outside.