Fix inconsistent styling

.cursor/prompts/review.prompt.md

@@ -0,0 +1,32 @@
+Review my code changes against the Quran.com frontend project guidelines.
+
+## Context
+
+- Next.js (Pages Router), TypeScript strict mode, SCSS modules
+- next-translate for i18n, useSWR for data fetching, Radix UI components
+
+## Check For
+
+**TypeScript**: No `any` types, explicit return types on exports, interfaces for objects, enums for repeated values
+
+**React**: Functional components only, Props interface, proper memoization, no unnecessary useEffect, skeleton loaders for async data
+
+**Code Quality**: Functions <30 lines, DRY code, proper error handling with fallbacks, no unused code, comments explain "why"
+
+**API/Data**: useSWR for fetching, error states handled, API response fallbacks, optimistic updates
+
+**Localization**: All text uses `t('key')` from next-translate, no hardcoded strings, RTL-safe CSS (logical properties like margin-inline-start)
+
+**Accessibility**: Semantic HTML, ARIA attributes, keyboard navigation
+
+**Security**: No hardcoded secrets, env vars for config, input validation
+
+**Testing**: Tests for new functionality, edge cases, error scenarios
+
+## Output Format
+
+1. **🚨 Critical** - Must fix before PR
+2. **💡 Suggestions** - Improvements to consider
+3. **✅ Good** - What's done well
+
+Include file paths and line numbers.

.cursor/rules/bug-handling-with-todo-comments.mdc

@@ -0,0 +1,5 @@
+---
+description: Specifies the usage of TODO comments to outline problems or bugs encountered in existing code, regardless of file type.
+globs: **/*.*
+---
+- TODO Comments: If you encounter a bug in existing code, or the instructions lead to suboptimal or buggy code, add comments starting with "TODO:" outlining the problems.

.cursor/rules/clean-code.mdc

@@ -0,0 +1,56 @@
+---
+description: Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing or reviewing code to ensure consistency and quality.
+globs: 
+alwaysApply: false
+---
+# Clean Code Guidelines
+
+## Constants Over Magic Numbers
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+
+## Encapsulation
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+
+## Code Quality Maintenance
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Testing
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names 

.cursor/rules/codequality.mdc

@@ -0,0 +1,45 @@
+---
+description: Code Quality Guidelines
+globs:
+alwaysApply: false
+---
+# Code Quality Guidelines
+
+## Verify Information
+Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
+
+## File-by-File Changes
+Make changes file by file and give me a chance to spot mistakes.
+
+## No Apologies
+Never use apologies.
+
+## No Understanding Feedback
+Avoid giving feedback about understanding in comments or documentation.
+
+## No Whitespace Suggestions
+Don't suggest whitespace changes.
+
+## No Inventions
+Don't invent changes other than what's explicitly requested.
+
+## No Unnecessary Confirmations
+Don't ask for confirmation of information already provided in the context.
+
+## Preserve Existing Code
+Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
+
+## Single Chunk Edits
+Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
+
+## No Implementation Checks
+Don't ask the user to verify implementations that are visible in the provided context.
+
+## No Unnecessary Updates
+Don't suggest updates or changes to files when there are no actual modifications needed.
+
+## Provide Real File Links
+Always provide links to the real files, not x.md.
+
+## No Current Implementation
+Don't show or discuss the current implementation unless specifically requested.

.cursor/rules/coding-guidelines---early-returns-and-conditionals.mdc

@@ -0,0 +1,6 @@
+---
+description: Applies coding guidelines related to using early returns and conditional classes in all files.
+globs: **/*.*
+---
+- Utilize Early Returns: Use early returns to avoid nested conditions and improve readability.
+- Conditional Classes: Prefer conditional classes over ternary operators for class attributes.

.cursor/rules/comment-usage.mdc

@@ -0,0 +1,8 @@
+---
+description: This rule dictates how comments should be used within the codebase to enhance understanding and avoid clutter.
+globs: **/*.*
+---
+- Use comments sparingly, and when you do, make them meaningful.
+- Don't comment on obvious things. Excessive or unclear comments can clutter the codebase and become outdated.
+- Use comments to convey the "why" behind specific actions or explain unusual behavior and potential pitfalls.
+- Provide meaningful information about the function's behavior and explain unusual behavior and potential pitfalls.

.cursor/rules/follow-up-questions.mdc

@@ -0,0 +1,7 @@
+
+---
+description: When you have questions or need clarification, I'll ask follow-up questions to ensure I understand your requirements before providing a solution. This helps me deliver more accurate and useful code that meets your specific needs.
+globs: 
+alwaysApply: true
+---
+Do not make any changes, until you have 95% confidence that you know what to build ask me follow up questions until you have that confidence.

.cursor/rules/function-length-and-responsibility.mdc

@@ -0,0 +1,7 @@
+---
+description: This rule enforces the single responsibility principle, ensuring functions are short and focused.
+globs: **/*.*
+---
+- Write short functions that only do one thing.
+- Follow the single responsibility principle (SRP), which means that a function should have one purpose and perform it effectively.
+- If a function becomes too long or complex, consider breaking it into smaller, more manageable functions.

.cursor/rules/function-ordering-conventions.mdc

@@ -0,0 +1,5 @@
+---
+description: Defines the function ordering conventions, where functions that compose other functions appear earlier in the file, regardless of the file type.
+globs: **/*.*
+---
+- Order functions with those that are composing other functions appearing earlier in the file. For example, if you have a menu with multiple buttons, define the menu function above the buttons.

.cursor/rules/general-code-commenting.mdc

@@ -0,0 +1,6 @@
+---
+description: Ensures helpful comments are added to the code and that old, relevant comments are preserved.
+globs: **/*.*
+---
+- Always add helpful comments to the code explaining what you are doing.
+- Never delete old comments, unless they are no longer relevant because the code has been rewritten or deleted.

.cursor/rules/general-coding-principles.mdc

@@ -0,0 +1,7 @@
+---
+description: Applies general coding principles like simplicity, readability, performance, maintainability, testability, and reusability to all files.
+globs: **/*.*
+---
+- Focus on simplicity, readability, performance, maintainability, testability, and reusability.
+- Remember less code is better.
+- Lines of code = Debt.

.cursor/rules/minimal-code-changes-rule.mdc

@@ -0,0 +1,7 @@
+---
+description: Enforces the principle of making minimal code changes to avoid introducing bugs or technical debt in any file.
+globs: **/*.*
+---
+- Only modify sections of the code related to the task at hand.
+- Avoid modifying unrelated pieces of code.
+- Accomplish goals with minimal code changes.

.cursor/rules/naming-conventions.mdc

@@ -0,0 +1,7 @@
+---
+description: This rule focuses on using meaningful and descriptive names for variables, functions, and classes throughout the project.
+globs: **/*.*
+---
+- Choose names for variables, functions, and classes that reflect their purpose and behavior.
+- A name should tell you why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent.
+- Use specific names that provide a clearer understanding of what the variables represent and how they are used.

.cursor/rules/next-js-app-router-rule.mdc

@@ -0,0 +1,7 @@
+---
+description: Applies Next.js App Router specific guidelines to components and pages within the 'app' directory.
+globs: app/**/*.tsx
+alwaysApply: false
+---
+- You are an expert in Next.js Pages Router.
+- Follow Next.js documentation for best practices in data fetching, rendering, and routing.

.cursor/rules/next-js-configuration-rule.mdc

@@ -0,0 +1,7 @@
+---
+description: Rules specifically for the Next.js configuration file.
+globs: /next.config.js
+alwaysApply: false
+---
+- Ensure the Next.js configuration is optimized for performance.
+- Review and update the configuration regularly based on project needs.

.cursor/rules/next-js-conventions.mdc

@@ -0,0 +1,12 @@
+---
+description: Key Next.js conventions for state changes, web vitals, and client-side code usage.
+globs: **/*.{ts,js,jsx,tsx}
+alwaysApply: false
+---
+- Rely on Next.js Pages Router for state changes.
+- Prioritize Web Vitals (LCP, CLS, FID).
+- Minimize 'use client' usage:
+  - Prefer server components and Next.js SSR features.
+  - Use 'use client' only for Web API access in small components.
+  - Avoid using 'use client' for data fetching or state management.
+  - Refer to Next.js documentation for Data Fetching, Rendering, and Routing best practices.

.cursor/rules/next-js-folder-structure.mdc

@@ -0,0 +1,14 @@
+---
+description: This rule defines the recommended folder structure for Next.js projects.
+globs: app/**/*.*
+alwaysApply: false
+---
+- Adhere to the following folder structure:
+
+src/
+  components/
+  lib/
+  pages/
+  hooks/
+  utils/
+public/

.cursor/rules/performance-optimization-rules.mdc

@@ -0,0 +1,6 @@
+---
+description: Guidelines for optimizing performance by minimizing client-side operations and using server-side rendering.
+globs: **/*.{js,jsx,ts,tsx}
+---
+- Optimize Web Vitals (LCP, CLS, FID).
+- Use dynamic loading for non-critical components using @src/components/dls/Spinner/Spinner.tsx

.cursor/rules/persona---senior-full-stack-developer.mdc

@@ -0,0 +1,5 @@
+---
+description: Defines the persona as a senior full-stack developer with extensive knowledge applicable to all files.
+globs: **/*.*
+---
+- You are a senior full-stack developer. One of those rare 10x developers that has incredible knowledge.

.cursor/rules/pre-pr-review.mdc

@@ -0,0 +1,63 @@
+---
+description: Pre-PR code review checklist - automatically applied when reviewing code changes
+globs: "**/*.ts,**/*.tsx,**/*.scss"
+alwaysApply: true
+---
+
+# Pre-PR Code Review Standards
+
+When reviewing code changes, check against these Quran.com project guidelines:
+
+## TypeScript
+- Flag any `any` types - use `unknown` or specific types
+- Require explicit return types on exported functions
+- Use interfaces for object shapes, types for unions
+- Use enums for repeated categorical values
+
+## React Components
+- Functional components only - no class components
+- Props interface must be defined
+- Use proper memoization (useCallback, useMemo) for callbacks/expensive computations
+- Flag unnecessary useEffect - prefer event handlers or derived state
+- Require skeleton loaders for async data to prevent layout shifts
+
+## Code Quality
+- Functions should be under 30 lines
+- Flag duplicated code - extract to reusable functions (DRY)
+- Require proper error handling with meaningful fallbacks
+- Flag unused imports, variables, or dead code
+- Comments should explain "why" not "what"
+
+## API & Data Handling
+- Use useSWR for data fetching, not raw fetch in components
+- Handle error states with user-friendly messages
+- Provide fallbacks for API responses - don't blindly trust data
+- Use optimistic updates for predictable actions (bookmark, like)
+
+## Localization
+- All user-facing text must use `t('key')` from next-translate
+- No hardcoded strings in UI
+- Use RTL-safe CSS logical properties (margin-inline-start, not margin-left)
+
+## Accessibility
+- Use semantic HTML elements
+- Add ARIA attributes where needed
+- Ensure keyboard navigation works
+
+## Security
+- No hardcoded secrets or credentials
+- Use environment variables for configuration
+- Validate and sanitize user inputs
+
+## Testing
+- New functionality needs tests
+- Cover edge cases and error scenarios
+- Test file naming: `*.test.ts` or `*.test.tsx`
+
+## Review Output Format
+When providing review feedback:
+1. 🚨 **Critical** - Must fix before PR
+2. 💡 **Suggestions** - Improvements to consider
+3. ✅ **Good** - What's done well
+
+Include file paths and line numbers in feedback.

.cursor/rules/react-functional-components.mdc

@@ -0,0 +1,6 @@
+---
+description: Enforces the use of functional components with hooks in React components.
+globs: src/components/**/*.tsx
+---
+- Always use React functional components with hooks.
+- Use React.FC for functional components with props.