verify-mechanical-change

Verify Mechanical Change Skill

Use this skill when the user wants to confirm that a change is purely mechanical and contains no changes to behavior, UI, or application logic.

Workflow

1. Retrieve the Git Diff: Identify the diff to analyze. If the user specifies a commit, branch, or PR/CL, use git commands to get that diff. Otherwise, get the unstaged and staged changes in the workspace:

   • Get staged changes: git diff --cached
   • Get unstaged changes: git diff
   • Combine them or ask the user if they want to analyze staged, unstaged, or both. Save this diff as DIFF_CONTENT.

   If DIFF_CONTENT is empty, stop and ask the user to provide a diff or commit, or verify if there are any changes to check.

2. Invoke Two Parallel Subagents: Invoke two parallel subagents using the invoke_subagent tool with TypeName: research (to ensure they have read-only tools to explore the codebase for tracing symbol usage/definitions).

   Pass the identical prompt and DIFF_CONTENT to both.

   • Subagent 1 (MechanicalChangeReviewer1):
     • Role: Mechanical Change Reviewer A
     • Prompt:

       You are an expert code reviewer. Your task is to analyze the git diff provided below and determine if it is purely mechanical.
       
       A change is "purely mechanical" if and only if it consists entirely of:
       - Code style formatting (whitespace, indentation, line endings)
       - Renaming symbols (variables, functions, classes, properties) consistently across files
       - Modifying imports, exports, or namespace declarations (e.g. moving a file/module)
       - Adding, updating, or removing comments/documentation (e.g. JSDoc) without modifying implementation
       - Upgrading/downgrading dependencies/configurations that do not change application logic or UI
       - Adding or modifying unit/integration/end-to-end tests
       
       A change is NOT purely mechanical if it contains:
       - Logic changes (conditionals, loops, calculations, algorithm modifications)
       - UI/UX layout or styling changes (HTML, CSS, Component layout/attributes, localization strings)
       - Data model changes (DB schema, API payloads, config parameters affecting behavior)
       - Side-effects (network requests, console logs added/removed, state changes)
       - Any potential change in runtime behavior, error handling, performance characteristics, or user interface.
       
       Use any available tools to read files and explore the codebase to trace the definition and usage of renamed symbols or modified functions to confirm that no functional change was introduced.
       
       CRITICAL GUIDELINES:
       - Do NOT run any tests. Assume that all existing tests pass.
       - If the change is purely mechanical:
         - State "CONFIRMED: The change is purely mechanical." and explain why.
         - Look for and recommend opportunities where related or untouched behaviors affected by this change could be tested to increase coverage/confidence.
       - If the change is NOT purely mechanical:
         - State "REJECTED: The change contains behavioral or UI modifications."
         - List all the specific lines/files and logical details that violate the mechanical-only criteria.
         - Provide recommendations on how these behavioral changes could/should be covered by tests.
       
       Diff:
       <DIFF_CONTENT>