Morphism Pr Audit Compliance Prompt

assetactive

Morphism Pr Audit Compliance Prompt

Source: morphism-pr-audit-compliance-prompt.md (ingested 2026-03-28)

Conduct a comprehensive audit of all historical Pull Requests (PRs) within the designated repositories to ensure full alignment with current project requirements, architectural standards, and coding guidelines. The review process must systematically identify and document any legacy, orphaned, unused, untracked, unimplemented, or otherwise redundant files, code segments, or project plans introduced or modified by these PRs.

Detailed Instructions:

  1. Define Scope and Timeframe:

    • Specify the exact repositories to be included in this audit.
    • Establish a clear start date for the "past PRs" to be reviewed (e.g., all PRs merged since ${start_date}, or the last ${number_of_months} months).
  2. Sequential Review Process:

    • Review PRs in chronological order of their merge date, starting from the oldest within the defined scope. This approach helps in understanding the evolution of the codebase and identifying the introduction points of potential issues.
    • For each PR, examine the changes introduced (added, modified, deleted files and code).
  3. Compliance Check against Recent Requirements:

    • Current Requirements Baseline: Obtain and reference the latest project requirements, architectural specifications, coding standards, security policies, and performance benchmarks.
    • Feature Alignment: Verify that features or modifications introduced by the PRs are still relevant and correctly implemented according to current functional requirements.
    • Architectural Adherence: Assess if the code changes conform to the current architectural patterns, design principles, and technology stack.
    • Coding Standards: Check for adherence to current coding conventions, style guides, and best practices (e.g., naming conventions, error handling, logging).
    • Security Compliance: Ensure that no vulnerabilities or insecure practices were introduced or remain unaddressed based on current security guidelines.
  4. Identification of Redundant/Problematic Elements:

    • Legacy Files/Code: Identify files, functions, or modules that are outdated, use deprecated technologies, or implement features no longer required but still exist in the codebase.
    • Orphaned Files/Code: Locate files or code blocks that are no longer referenced or called by any active part of the application. This includes configuration files, utility scripts, or test files that have lost their context.
    • Unused Assets: Detect images, stylesheets, or other static assets that were added but are no longer utilized by the application.
    • Untracked Elements (if applicable): While PRs typically deal with tracked files, investigate if any PRs inadvertently led to the creation of untracked files in the deployment environment or local development setups that should be managed.
    • Unimplemented Plans/Features: Review PR descriptions, comments, and associated tickets to identify any proposed features, refactorings, or improvements that were partially implemented or merged but never fully completed or integrated into the live system.
    • Redundant Logic: Identify duplicate code segments or redundant implementations of functionality that could be consolidated or removed.
    • Dead Code: Pinpoint code that is unreachable or serves no purpose in the current application state.
  5. Documentation and Reporting:

    • For each identified issue (legacy, orphan, unused, unimplemented, etc.), create a detailed entry in a structured report or a new task in the project management system.
    • Each entry must include:
      • The specific PR number and merge date.
      • The exact file path(s) and line numbers of the problematic code/file.
      • A clear description of the issue (e.g., "Legacy API endpoint," "Unused utility function," "Orphaned configuration file").
      • The rationale for why it's considered problematic (e.g., "Violates current security policy," "No longer referenced by any active module," "Feature was deprecated").
      • A proposed action (e.g., "Delete file," "Refactor module," "Create new task for implementation," "Update documentation").
  6. Deliverables:

    • A comprehensive audit report detailing all findings, categorized by type of issue (legacy, orphan, unused, etc.).
    • A prioritized list of actionable tasks (e.g., JIRA tickets, GitHub Issues) for addressing each identified problem, including estimated effort where possible.
    • A summary of the overall compliance status of the codebase based on the PR review.

Tools and Resources:

  • Version control system (e.g., Git, GitHub/GitLab/Bitbucket PR interface) for reviewing PR history and code changes.
  • Code analysis tools (e.g., linters, static analyzers) to assist in identifying dead or unused code.
  • Project management system for creating and tracking remediation tasks.
  • Access to current requirement documents, architectural diagrams, and coding standards.