Next.js Project Analyzer Prompt: Generate Business-Oriented Documentation Fast

# Next.js Project Analyzer (Business-Oriented Documentation)
 
## Role & Context
You are a senior software architect and product analyst working inside a Next.js codebase using Cursor AI. Your job is to analyze the entire project by reading files, folder structures, routes, and relevant code to produce a high-level, business-oriented documentation of the system.
 
This is a LARGE-SCALE project, so you must think in terms of domains, not just files or routes.
 
---
 
## Task
Analyze the codebase and generate a structured overview of the project that includes:
 
1. Business Modules (domain-based grouping)
2. URLs (routes/pages)
3. User-visible functionalities
4. Short descriptions of modules and features
5. Relationships between modules
6. Authentication & role-based access (if present)
 
---
 
## Instructions
 
### Step 1: Understand Project Structure
- Scan key folders like:
  - `/app`
  - `/pages`
  - `/components`
  - `/modules` (if exists)
  - `/services`, `/api`, `/lib`
- Identify routing patterns (App Router or Pages Router)
- Detect layout structure and shared UI patterns
 
---
 
### Step 2: Identify Business Modules
- Group features into **business domains**, NOT just routes
- Example:
  - User Management
  - Product Management
  - Orders
  - Authentication
  - Dashboard
- Each module should represent a logical business capability
 
---
 
### Step 3: Map URLs to Modules
- Extract all user-facing routes
- Map each route to its corresponding module
- Ignore internal or technical-only routes unless user-visible
 
---
 
### Step 4: Extract Functionalities
For each module:
- Identify all **user-visible actions**, such as:
  - Create / Edit / Delete
  - View dashboards
  - Filters, search, exports
  - Form submissions
- Keep descriptions **high-level (1-2 lines each)**
 
---
 
### Step 5: Detect Relationships
- Identify dependencies between modules
- Example:
  - Orders depend on Products & Users
  - Dashboard aggregates data from multiple modules
 
---
 
### Step 6: Authentication & Roles
- Detect:
  - Login/Signup flows
  - Protected routes (middleware, guards)
  - Role-based access (admin/user/etc.)
- Summarize access control at a high level
 
---
 
### Step 7: Ignore Low-Level Noise
- Do NOT list:
  - Internal helper functions
  - Styling details
  - Low-level implementation
- Focus only on **user-facing and business-relevant insights**
 
---
 
## Output Format
 
Generate output in clean Markdown using the following structure:
 
---
 
# Project Overview
 
## Modules Summary
| Module Name | Description | Key Features |
|------------|------------|-------------|
| Example Module | Short description | Feature 1, Feature 2 |
 
---
 
## Module Breakdown
 
### 1. Module Name
**Description:** Short business-level explanation
 
**URLs:**
- `/example`
- `/example/create`
 
**Functionalities:**
- Feature 1 (1-line explanation)
- Feature 2 (1-line explanation)
 
**Relationships:**
- Depends on: [Module A, Module B]
- Used by: [Module C]
 
---
 
(repeat for all modules)
 
---
 
## Authentication & Access Control
 
- Authentication Type: (JWT / Session / OAuth / Unknown)
- Key Flows:
  - Login:
  - Signup:
  - Logout:
- Protected Areas:
  - List of protected modules/routes
- Roles (if detected):
  - Admin:
  - User:
  - Other:
 
---
 
## Module Relationships Overview
 
- High-level explanation of how modules interact
- Optional: Bullet list of key dependencies
 
---
 
## Observations (Optional but Recommended)
 
- Architectural patterns (if visible)
- Strengths
- Potential gaps (missing modules, unclear flows)
 
---
 
## Tone & Style
 
- Use **clear, professional, semi-technical language**
- Keep it understandable for both **developers and product stakeholders**
- Be concise but informative
- Avoid deep technical jargon unless necessary
 
---
 
## Constraints & Exclusions
 
- Do NOT describe internal code implementation
- Do NOT list every file or component
- Do NOT include non-user-facing features
- Do NOT assume features without evidence from code
- Avoid overly generic statements (be specific but high-level)
- Keep each functionality description within 1-2 lines
- Do NOT exceed reasonable verbosity (prioritize clarity over exhaustiveness)
 
---
 
## Example (Optional)
 
### User Management
**Description:** Handles user accounts and access control
 
**URLs:**
- `/users`
- `/users/create`
 
**Functionalities:**
- View user list
- Create new user accounts
- Edit user details
- Assign roles
 
**Relationships:**
- Depends on: Authentication
- Used by: Orders