- Follow Next.js patterns, use app router and correctly use server and client components.
- Use Tailwind CSS for styling.
- Use Shadcn UI for components.
- Use TanStack Query (react-query) for frontend data fetching.
- Use React Hook Form for form handling.
- Use Zod for validation.
- Use React Context first then Jotai if necessary for state management.
- Use PascalCase when creating new React files. UserCard, not user-card.
- Use kebab-case when creating the rest file, like hooks, lib, utils, parsers, etc.
- Use named exports when creating new react components.
- Besides of that, keep the consistency from currently codebase context and follow their code's style.
- DO NOT TEACH ME HOW TO SET UP THE PROJECT, JUMP STRAIGHT TO WRITING COMPONENTS AND CODE.

Please review my Next.js code with a focus on security issues.

Use the below as a starting point, but consider any other potential issues

You do not need to address every single area below, only what is relevant to the user's code.

1. Data Exposure:
- Verify Server Components aren't passing full database objects to Client Components
- Check for sensitive data in props passed to 'use client' components
- Look for direct database queries outside a Data Access Layer
- Ensure environment variables (non NEXT_PUBLIC_) aren't exposed to client

2. Server Actions ('use server'):
- Confirm input validation on all parameters
- Verify user authentication/authorization checks
- Check for unencrypted sensitive data in .bind() calls

3. Route Safety:
- Validate dynamic route parameters ([params])
- Check custom route handlers (route.ts) for proper CSRF protection
- Review middleware.ts for security bypass possibilities

4. Data Access:
- Ensure parameterized queries for database operations
- Verify proper authorization checks in data fetching functions
- Look for sensitive data exposure in error messages

Key files to focus on: files with 'use client', 'use server', route.ts, middleware.ts, and data access functions.

Summarize git commit logs and file changes into a concise, collaborator-friendly changelog suitable for a GitHub pull request description, grouping and prioritizing changes by feature or area. Limit the final output to a single-level bullet list containing no more than 5 items, each representing only the most important and impactful changes. Every bullet point must be no longer than 50 characters (including spaces and punctuation) to ensure brevity and clarity. If your analysis produces more than 5 changes or groups, merge or generalize less significant items until only the 5 principal changes or categories remain.
- Only use the provided commit logs and file change stats. - Analyze and group related changes by feature or area. Strictly output a single-level, single-bullet-per-group list with no sub-lists and never more than 5 bullets. - Prioritize and select the **most critical and impactful changes** relevant for reviewers and developers. - If more than 5 distinct groups exist, summarize or combine lower-priority changes to fit the 5-item limit. - Each bullet item’s text must not exceed 50 characters (including spaces and punctuation). - Keep all summaries concise, scannable, and focused on outcomes. - If neither commit nor diff data is provided, output the prescribed guidance for generating a commit log using `--first-parent`.
# Output Format
- Use markdown formatting for the changelog. - Start your output with the heading:
  ```
  ## Changelog
  ```
- Follow with a single-level bullet list (no more than 5 bullets), one per change group. Do not use sub-bullets or secondary lists. Each bullet must be ≤50 characters. For example:
  ```
  ## Changelog

  - Fixed login bug and session timeout
  - Added dashboard summary widgets
  - Improved dashboard accessibility
  - Refactored dashboard data fetching
  - Updated API usage docs
  ```
- If no commit/diff data is provided, output only:
  ```
  To generate a log file for the current branch's commit range, run:
  git log --first-parent --oneline > git-log.txt
  ```

# Examples
**Example 1: (with several related changes)** _Input:_   [git commit logs and file stats including several dashboard tweaks, documentation updates, and two major authentication fixes]
_Output:_   ## Changelog
- Fixed password reset and session timeout - Improved dashboard layout and widgets - Added dashboard color accessibility - Refactored dashboard performance - Updated API docs
**Example 2: (more than 5 distinct areas, requiring summarization)** _Input:_   [commits spanning login, dashboard, reporting, notifications, settings, and documentation]
_Output:_   ## Changelog
- Overhauled login/authentication - Improved dashboard features - Enhanced reports and notifications - Simplified settings management - Updated documentation
**Example 3: (no commit/diff data)** _Output:_   To generate a log file for the current branch's commit range, run: git log --first-parent --oneline > git-log.txt
# Notes
- Do not exceed 5 bullet points in the changelog—even if more change groups exist. Combine or generalize as needed. - Every bullet point must be no longer than 50 characters. - Make each bullet represent a key feature, area, or outcome—not minor details. - Output must be suitable for direct use in a GitHub PR description. - Never use sub-lists or nested formatting. - Output only the prescribed guidance if no data is provided.
Remember:   Summarize and prioritize all changes, selecting only the 5 most important. Ensure every bullet point is no longer than 50 characters. Combine or generalize related or minor changes to stay within these strict formatting limits before producing the changelog. Always output as a ≤5-item, single-level markdown bullet list for PR use.

Write a concise, copy-ready Git commit message based on a provided git diff or diff context.
- Generate only a single commit message header (maximum 40 characters, starting with a capital letter, no prefixes like feat:, fix:, chore:, etc.). - Include an optional bullet-point body (each line starts with "- ") **only if essential context or explanation is needed for clarity**. By default, output *only the header*. Most changes do not require any body. - If no git diff or context is provided, reply: "No diff context provided. Use `@Git Diff` to include your changes." - If the diff shows no changes, reply: "No changes to commit." - Always wrap code-related identifiers (function names, variable names, file names, commands) in backticks. - For file paths, use only the file name with extension (e.g., `fileName.js`), not the full directory path. - Your output should be ready for direct copy with no extra commentary, markdown code blocks, or wrappers.
# Steps
1. Check if input is provided. If not, output the appropriate message. 2. Check if the diff shows any changes. If not, output the appropriate message. 3. Analyze the changes to draft a single, ≤ 40-character commit header (capitalized, no prefixes). 4. Add a bullet-point explanation only if *strictly necessary* for clarity (e.g., change is complex or ambiguous), following formatting rules for code/context.
  - **In most cases, no body is necessary or should be included.**
5. Abbreviate all file paths mentioned to `fileName.{ext}` in any explanations.
# Output Format
- A single header line (≤ 40 characters) - (Truly optional; rare) One or more bullet points beneath, only if absolutely necessary, each starting with "- " - No extraneous text, explanations, or markdown blocks.
# Examples
Example 1: No input   Input: [none]   Output:   No diff context provided. Use `@Git Diff` to include your changes.
Example 2: Diff with no changes   Input: [diff contains no changes]   Output:   No changes to commit.
Example 3: Normal git diff with functions and files   Input:   (diff shows updates in `src/logic/calculator.js` function `addNumbers` and `helperFunction`)   Output:   Update calculator logic
- Modified `addNumbers` and `helperFunction` in `calculator.js`
Example 4: Simple, self-explanatory change (header only)   Input:   (diff shows renaming `myVariable` to `total` throughout `utils.js`)   Output:   Rename `myVariable` to `total` in `utils.js` (Note: In real usage, do not include a body here, as the header is self-explanatory.)
Example 5: Complex/confusing change (header plus essential body)   Input:   (diff refactors `parseData` to accept extra arguments, impacting multiple files; context is non-obvious)   Output:   Refactor `parseData` for new arguments
- Updated `parseData` usage in `main.js`, `data.js`
# Notes
- Only add a body if omitting it would make the commit ambiguous or unclear. - Most commits should include only the header. - Always use backticks for code-like identifiers. - Never include extra commentary before or after the main message.
**Reminder:** Only add bullet-point explanations if absolutely necessary. By default, output only the header line. Keep all output copy-friendly and concise.

Write a concise, copy-ready Git commit message based on a provided git diff or diff context, strictly following the Conventional Commit specification for header formatting.
- Generate a single commit message header line using the Conventional Commits format:  
  `type(scope?): description`  
  - The `type` is mandatory and describes the kind of change (e.g., feat, fix, refactor, docs, test, chore, perf, build, ci, style, revert).  
  - The optional `scope` (in parentheses) is the file or component affected (use just the main file name with extension, e.g., `calculator.js`, not directories).
  - The `description` summarizes the change (use the imperative mood and ≤ 40 characters in total for the header).

- Add an optional bullet-point body beneath (using "- " at the start of each line) **only if essential context or explanation is needed for clarity**.  
  - Most changes do not require any body—output only the header by default.
  - In the body and header, wrap code-related identifiers (function names, variable names, file names, commands) in backticks.  
  - For file paths in explanations, use only the file name with extension.

- If no git diff or context is provided, reply: `No diff context provided. Use @Git Diff to include your changes.` - If the diff shows no changes, reply: `No changes to commit.` - Your output must be ready for direct copy-paste (no extra commentary, markdown code blocks, or wrappers).
# Steps
1. Check if input is provided. If not, output the appropriate message. 2. Check if the diff shows any changes. If not, output the appropriate message. 3. Analyze the code changes. Choose the most suitable conventional commit `type`, optional `scope` (main file/component), and a ≤ 40-character imperative `description`. 4. Only if strictly necessary (e.g., ambiguous or complex change), add 1–3 bullet points of additional context (each beginning with "- "), following formatting rules above.
  - Most commits should include **only** the header.
5. Abbreviate all file paths in headers or explanations to `fileName.{ext}`.
# Output Format
- A single header line using the correct Conventional Commit format (≤ 40 characters total). - (Truly optional; rare) One or more bullet points beneath, only if absolutely necessary, each starting with "- " - No extraneous text, explanations, markdown blocks, or commentary.
# Examples
Example 1: No input   Input: [none]   Output:   No diff context provided. Use @Git Diff to include your changes.
Example 2: Diff with no changes   Input: [diff contains no changes]   Output:   No changes to commit.
Example 3: Normal git diff with functions and files   Input: (diff shows updates in `src/logic/calculator.js` function `addNumbers` and `helperFunction`)   Output:   fix(calculator.js): update calculator logic
- Modified `addNumbers` and `helperFunction` in `calculator.js`  
Example 4: Simple, self-explanatory change (header only)   Input: (diff shows renaming `myVariable` to `total` throughout `utils.js`)   Output:   refactor(utils.js): rename `myVariable` to `total`
(Normally, no body needed here; header is self-explanatory.)
Example 5: Complex/confusing change (header plus essential body)   Input: (diff refactors `parseData` to accept extra arguments, impacting multiple files; context is non-obvious)   Output:   refactor(parseData.js): add arg to `parseData`
- Updated `parseData` usage in `main.js`, `data.js`
(Real examples should feature actual types [feat, fix, refactor, etc.], a short scope, and keep the message under 40 characters.)
# Notes
- The Conventional Commits header is required and must include a correct type and, when applicable, a scope (the main affected file/component). - The header must be no more than 40 characters long. - Add bullet-point body only if omitting it would make the commit ambiguous or unclear. - Wrap all code-like identifiers in backticks. - Do not include any commentary, wrappers, or markdown code blocks outside of the message.
**Reminder:** By default, output only the header line in correct Conventional Commit form. Add a bullet-point explanation only if absolutely essential for clarity. 
**Objective Reminder:** Write a concise, Conventional Commits-compliant commit message ready for direct copy-paste, including a scoped header and a brief, optional explanation only when necessary for clarity.