Pre-Release Security Analysis

```xml
<prompt>
  <objective>
  Analyze the current implementation of our project to identify potential
  vulnerabilities, overlooked issues, and areas requiring refinement before
  proceeding to the release phase. The goal is to ensure a robust, secure, and
  production-ready state.
  </objective>

  <context>
  We are nearing the completion of the development cycle for Project [Project
  Name/Identifier]. The implementation includes [briefly describe key
  components, technologies, and functionalities, e.g., "a web application built
  with React and Node.js, utilizing a PostgreSQL database, and incorporating
  user authentication via OAuth."]. We are preparing for the upcoming release
  phase, which involves [describe release phase activities, e.g., "deployment to
  production servers, public access, and user onboarding."]. Before this
  transition, a thorough assessment of the current state is critical to mitigate
  risks.
  </context>

  <requirements>
  <analysis_scope>
  The analysis must cover, but is not limited to, the following areas:
      <security_vulnerabilities>
          Identify potential security weaknesses, such as:
          - Cross-Site Scripting (XSS)
          - SQL Injection
          - Insecure Direct Object References (IDOR)
          - Authentication and Authorization flaws
          - Data exposure or leakage
          - Use of outdated or vulnerable libraries/dependencies
          - Common Web Application Security risks (e.g., OWASP Top 10)
      </security_vulnerabilities>
      <performance_bottlenecks>
          Detect potential performance issues that could impact user experience
  or system stability, including:
          - Slow response times
          - High resource utilization (CPU, memory, network)
          - Inefficient database queries
          - Scalability concerns
      </performance_bottlenecks>
      <bugs_and_defects>
          Uncover any known or potential bugs, logical errors, or deviations
  from expected behavior that may not have been fully addressed.
      </bugs_and_defects>
      <technical_debt>
          Highlight areas of technical debt that could hinder future
  development, maintenance, or stability, such as:
          - Poorly written or undocumented code
          - Lack of error handling
          - Inconsistent coding standards
          - Missing or inadequate unit/integration tests
          - Monolithic architecture challenges (if applicable)
      </technical_debt>
      <compliance_and_regulatory>
          Ensure adherence to relevant industry standards, privacy regulations
  (e.g., GDPR, CCPA), and internal policies.
      </compliance_and_regulatory>
      <user_experience_friction>
          Identify any aspects of the current implementation that might lead to
  user frustration or confusion, even if not strictly bugs (e.g., confusing
  workflows, unclear error messages).
      </user_experience_friction>
  </analysis_scope>

  <output_format>
  Provide a detailed report structured as follows:
      <summary>
      A concise overview of the key findings and the overall readiness for
  release.
      </summary>
      <detailed_findings>
            For each identified issue:
          - Category (e.g., Security Vulnerability, Performance Bottleneck, Bug,
  Technical Debt)
          - Specific description of the issue
          - Location/Component affected (e.g., file path, function name, API
  endpoint)
          - Potential impact/risk
          - Recommended refinement/action item
          - Severity level (e.g., Critical, High, Medium, Low)
      </detailed_findings>
      <recommendations>
      A prioritized list of recommended actions to address the identified issues
      before release.
      </recommendations>
      <confidence_score>
      An overall confidence score (e.g., percentage) reflecting the assessment
      of the implementation's readiness for release, based on the analysis.
      </confidence_score>
  </output_format>

  <constraints>
  - Focus on actionable insights.
  - Prioritize findings based on severity and potential impact.
  - Avoid making assumptions about the implementation beyond the provided
  context.
  - The analysis should be objective and evidence-based.
  - If specific tools or documentation are required for a deeper analysis, note
  these requirements.
  </constraints>

  <examples>
  <example_security>
  Issue: Potential SQL Injection vulnerability in user login endpoint (/api/
  auth/login).
  Impact: Allows attackers to manipulate database queries, potentially leading
  to data theft or unauthorized access.
  Recommendation: Implement parameterized queries or prepared statements for all
  database interactions. Sanitize user inputs rigorously.
  Severity: Critical
  </example_security>
  <example_performance>
  Issue: High memory consumption on the user profile page (/profile) under heavy
  load.
  Impact: Can lead to slow page loads and potential server crashes during peak
  traffic.
  Recommendation: Optimize image loading, implement lazy loading for components,
  and review data fetching logic.
  Severity: High
  </example_performance>
  <example_technical_debt>
  Issue: Large, complex function `processUserData` in `utils.js` lacks comments
  and unit tests.
  Impact: Difficult to understand, maintain, and refactor. Increases the risk of
  introducing bugs during future changes.
  Recommendation: Refactor the function into smaller, modular units. Add
  comprehensive JSDoc comments and write unit tests.
  Severity: Medium
  </example_technical_debt>
  </examples>
</prompt>
```