Production Pages Audit Prompt
A practical checklist and coding agent prompt for reviewing the pages and states around an existing application.
You can use it before development, during development, or before release to find real gaps without creating pages that do not belong to your product.
Contents
Pages to Check
Not every application needs every page. Use this checklist to identify what applies to your product, what already exists, and where there may be a real gap. Production pages are not only legal pages: they also include authentication, account recovery, permissions, payment outcomes, network states, empty states, error states, unknown routes, expired sessions, support paths, and operational states.
Privacy Policy
Explains how personal or device information is collected, used, stored, shared, and deleted.
Check when the application collects, stores, processes, or shares personal or device data.
Terms of Service
Sets the rules for using the product and the relationship between the user and the provider.
Check when users can sign up, transact, or depend on the service over time.
Cookie Policy
Describes the cookies and similar storage the site uses and the purpose of each category.
Check when the site sets non-essential cookies or loads analytics, embedded media, or third-party scripts.
Cookie Preferences
Lets a visitor review and change their consent for non-essential storage after the first visit.
Check when the product relies on consent for analytics, advertising, or third-party cookies.
Refund Policy
States whether and how customers can get money back after a purchase, and within what window.
Check when the product sells goods, services, or subscriptions directly.
Cancellation Policy
Explains how a customer ends a recurring plan or booked service, and what happens to access and billing.
Check when the product has subscriptions, renewals, or scheduled services.
Shipping Policy
Describes delivery methods, timelines, regions served, and costs.
Check when the product sells physical goods that are shipped.
Return or Exchange Policy
Explains how a customer returns or swaps a physical item and the conditions that apply.
Check when the product sells physical goods.
Disclaimer
Clarifies the limits of content presented as professional, financial, medical, or legal guidance.
Check when the product publishes guidance, estimates, or informational content users might act on.
Accessibility Statement
Describes the product's accessibility goals, known limitations, and how to report a barrier.
Check when you have made or intend to make an accessibility commitment for the product.
Data Processing Agreement
Defines responsibilities when the product processes personal data on behalf of business customers.
Check when you sell to businesses that pass their own users’ data through your product.
Acceptable Use Policy
Lists the behavior and content that are not allowed on the platform.
Check when users can post content, send messages, run workloads, or share infrastructure.
Security Policy
Summarizes how the product protects data and systems at a level users or customers can reference.
Check when customers ask how their data is secured, or when procurement requires it.
Responsible Disclosure
Tells security researchers how to report a vulnerability and what response to expect.
Check when the product is publicly reachable and you want a defined channel for security reports.
Community Guidelines
Describes expected conduct in shared or social spaces within the product.
Check when the product has forums, comments, profiles, or other user-to-user interaction.
Login
Lets an existing user authenticate and resume their session.
Check when the product has user accounts.
Register
Creates a new account and starts the user relationship.
Check when users can sign themselves up.
Email Verification
Confirms the user controls the address they signed up with.
Check when email is used for identity, recovery, or important notifications.
Forgot Password
Allows an existing account holder to recover access.
Check when the product supports password based authentication.
Reset Password
Completes the password recovery process. This is not just a page: the backend must support secure recovery tokens, expiration, single use behavior, invalidation after successful use, and protection against account enumeration.
Check when password recovery is implemented.
Onboarding
Guides a new user through the setup needed to get value from the product.
Check when a new account needs configuration, data, or context before the core features work.
Account Settings
Lets a user view and change their profile, credentials, and preferences.
Check when users have accounts with editable details.
Account Deletion
Lets a user remove their account and explains what happens to their data.
Check when the product stores personal data tied to an account.
Billing
Shows the current plan, payment method, invoices, and billing history.
Check when the product charges customers.
Upgrade
Moves a customer to a higher plan or a larger allowance.
Check when the product has more than one paid tier or usage level.
Downgrade
Moves a customer to a lower plan and explains what changes or is lost.
Check when plans differ in features or limits.
Cancel Subscription
Ends a recurring plan and explains access and billing after cancellation.
Check when the product has recurring billing.
Payment Success
Confirms a completed payment and the access the customer now has. The result must come from trusted backend or provider state, not from a value in the URL.
Check when the product processes payments.
Payment Failed
Explains that a payment did not go through and how to retry or fix it.
Check when the product processes payments.
Payment Pending
Communicates that a payment is still being processed and no further action is needed yet.
Check when you support methods that settle asynchronously, such as bank transfers.
Support
Gives users a way to reach a person for help.
Check when users may need assistance that self-service cannot fully resolve.
Help Center
Provides self-serve documentation and answers to common questions.
Check when the product has recurring questions that documentation can answer.
404
Handles an unknown destination and gives the user a safe way to continue.
Check when the product has routable pages, which is almost always.
403
Explains that the user does not have permission without exposing protected information.
Check when the product has permissions or private resources.
500
Handles unexpected application failures without exposing technical internals.
Check when the product runs application code, which is always.
Maintenance
Communicates planned downtime and roughly when the product is expected back.
Check when you take the product offline for deployments or migrations.
Offline
Communicates network loss where the application depends on connectivity and preserves safe unsent work when supported.
Check when the product is used on unreliable networks or as an installed or mobile app.
Empty State
Explains what a screen will contain and how to add the first item.
Check when lists, dashboards, or collections can legitimately start empty.
No Search Results
Confirms the search ran and suggests how to adjust the query or filters.
Check when the product has search or filtering.
Loading State
Shows that work is in progress and gives a sense of what to expect.
Check when views depend on network requests or slow computation.
Error State
Handles a failed operation within a screen and offers a way to recover.
Check when actions can fail without taking down the whole page.
Success State
Confirms an action completed and what happens next.
Check when users complete actions where the outcome is not otherwise obvious.
Session Expired
Handles an expired or invalid session and gives the user a safe path back to authentication.
Check when the product has authenticated sessions.
How the Audit Classifies Pages
The goal is not to build every possible page. It is to place each candidate into exactly one of these, so the work that follows is deliberate.
Exists and adequate
The functionality already exists and does not need unnecessary changes.
Exists and needs improvement
The functionality exists but has a meaningful UX, implementation, integration, or security gap.
Applicable but missing
The product genuinely needs the page or state and it is not currently implemented.
Not applicable
The product does not have the feature or workflow that would require the page.
Blocked by missing information
The page may apply, but accurate implementation depends on business, legal, financial, security, or operational information that has not been provided.
Production Pages Audit Prompt
Give this to your coding agent when you want it to inspect an existing application before creating production pages. The prompt is a tool; the checklist above is the reference.
# Production Pages Audit You are working in an existing application repository. Before creating anything, understand the application that is actually present. Start by inspecting the repository structure, package manifests, application entry points, routes, navigation, layouts, components, configuration, APIs, authentication, authorization, database models, integrations, and deployment configuration. Determine which implementation serves the live application. Do not assume that a README, directory name, or framework identifies the production source. 1. Establish what the product does Identify the users, important workflows, authentication model, permissions, data handling, payments, subscriptions, bookings, uploads, communication features, and any other functionality that affects which pages and states are required. Use the implementation as the primary source of truth. Use documentation as supporting evidence rather than assuming it is current. 2. Inspect the existing implementation Review existing routes, pages, components, layouts, APIs, backend services, database models, middleware, configuration, integrations, and deployment files. Identify which candidate pages and states already exist. When something already exists, inspect how it works before deciding that it needs to be changed. 3. Classify the candidate pages For every candidate page or state, assign exactly one of these classifications: Exists and adequate Exists and needs improvement Applicable but missing Not applicable Blocked by missing information A page should only be considered applicable when the actual product functionality, user workflow, platform requirement, or verified business requirement supports it. Do not create pages simply because they appear on a generic checklist. 4. Review existing functionality before implementing If a page exists and is adequate, leave it alone. If it exists but needs improvement, identify the specific problem before changing it. If it is applicable but missing, implement it using the existing architecture and design system. Do not replace working functionality simply because another implementation would be possible. 5. Preserve the existing application Do not break existing production functionality. Preserve existing routes, APIs, authentication, authorization, data handling, styling, navigation, configuration, and unrelated user changes. Do not introduce a new framework or dependency unless the existing project genuinely requires it. Make the smallest safe set of changes necessary. 6. Legal and business information For legal, financial, privacy, security, compliance, or business specific content, use only facts verified from the repository or information provided by the product owner. Do not invent a legal entity, address, jurisdiction, age requirement, contact information, payment rule, refund rule, cancellation rule, retention period, processor, certification, guarantee, or compliance claim. If accurate implementation requires information that is unavailable, classify the item as Blocked by missing information and report exactly what information is needed. Do not publish invented legal content. 7. Authentication and account recovery Verify authentication flows from the backend as well as the interface. Do not implement password recovery as a UI only feature. Recovery tokens must be securely handled, expire appropriately, be single use, and be invalidated after successful use. Password recovery responses must not reveal whether an account exists. Protected functionality must use backend authorization in addition to frontend navigation controls. Do not treat hidden buttons or client side route guards as the security boundary. 8. Payments If the product handles payments, inspect the actual payment implementation and webhook or backend verification flow. Do not treat a success value supplied through a URL as proof that a payment succeeded. Payment related pages must reflect trusted backend or provider state. 9. UX and system states Implement applicable loading, empty, error, success, offline, permission denied, unknown route, maintenance, and expired session states using the existing application architecture. Give users useful recovery actions where appropriate. Do not expose stack traces, secrets, internal paths, database errors, tokens, or sensitive implementation details. 10. Integration Every implemented page must be connected to the real application. Add real routes. Add real navigation where appropriate. Update the sitemap when the production site uses a repository maintained sitemap. Ensure direct navigation and refresh work. Do not leave orphan pages. 11. Accessibility Use semantic structure, logical headings, accessible labels, keyboard navigation, visible focus states, meaningful error messages, accessible buttons, and appropriate feedback for loading, success, and failure states. Do not claim accessibility compliance unless an actual accessibility audit has been performed. 12. Verification After implementation, run the relevant formatter, linter, type checker, tests, and production build available in the repository. Verify the new routes directly. Verify existing routes that could have been affected. Check responsive behavior, navigation, form behavior, error handling, and important interactions. Do not claim a check passed unless it was actually run. 13. Final report Provide a concise report containing: Application detected Existing adequate pages Existing pages requiring improvement Applicable missing pages Not applicable items Items blocked by missing information Files created Files modified Tests and checks performed Results of those checks Remaining risks
Use It Whenever You Need It
You can run this against a new project before development, an existing product during development, or an application you are reviewing before release.
The goal is not to create as many pages as possible. The goal is to understand which pages your product actually needs, which ones already exist, and where the real gaps are.
This resource is meant to be reused whenever you need it. Treat any generated legal, privacy, or compliance text as a draft for review by a person who knows your business and jurisdiction.
Quick Reference
The full set of candidate pages at a glance.
Legal and Policy
- Privacy Policy
- Terms of Service
- Cookie Policy
- Cookie Preferences
- Refund Policy
- Cancellation Policy
- Shipping Policy
- Return or Exchange Policy
- Disclaimer
- Accessibility Statement
- Data Processing Agreement
- Acceptable Use Policy
- Security Policy
- Responsible Disclosure
- Community Guidelines
Account and Lifecycle
- Login
- Register
- Email Verification
- Forgot Password
- Reset Password
- Onboarding
- Account Settings
- Account Deletion
- Billing
- Upgrade
- Downgrade
- Cancel Subscription
- Payment Success
- Payment Failed
- Payment Pending
- Support
- Help Center
System and UX States
- 404
- 403
- 500
- Maintenance
- Offline
- Empty State
- No Search Results
- Loading State
- Error State
- Success State
- Session Expired