Code Change Approval

Code Change Approval Skill

Purpose

Ensures all file modifications are approved by the user before execution, and that existing functionality is checked before making changes.

When This Activates

• About to use Edit tool on existing file
• About to use Write tool to overwrite existing file
• About to perform destructive operations (rm, mv, chmod)
• About to install packages or modify system
• Keywords detected: "change", "modify", "update", "edit", "delete"

Instructions

Phase 1: Research Before Changing

1. Search for Existing Functionality Before proposing changes, always check:

   • Does this functionality already exist elsewhere?
   • Are we duplicating code?
   • Should we modify existing instead of adding new?

   Use appropriate tools:

   # Search for similar functions/classes
   grep -r "function_name" .
   
   # Find related files
   find . -name "*related*"
   
   # Use glob for pattern matching
   glob "**/*pattern*"
   

2. Understand Current Implementation

   • Read the file being modified
   • Understand what it currently does
   • Identify dependencies
   • Check for tests that might break

Phase 2: Request Approval

3. For Existing File Modifications

   Always ask with this format:

   I propose changing [WHAT] in [FILE]. Proceed?
   
   Proposed changes:
   - [Change 1]
   - [Change 2]
   - [Change 3]
   
   Reason: [WHY]
   

   Example:

   I propose changing the authentication logic in src/auth.ts. Proceed?
   
   Proposed changes:
   - Add JWT token refresh
   - Update token expiry from 1h to 24h
   - Add refresh token rotation
   
   Reason: Current tokens expire too quickly for user workflow
   

4. For New Files (see new-file skill)

   If creating new file:

   Should I create new file [FILE] for [PURPOSE]?
   
   Alternative: Could modify existing file [EXISTING] instead.
   

5. For Destructive Operations

   Always suggest dry-run first:

   I need to [OPERATION] on [TARGET].
   
   Should I:
   1. Run dry-run first to see what would happen?
   2. Proceed directly?
   3. Skip this operation?
   
   Dry-run command: [COMMAND --dry-run]
   

   Example:

   I need to delete old migration files.
   
   Should I:
   1. Show what would be deleted first (ls old_migrations/)?
   2. Proceed with deletion?
   3. Skip this operation?
   

6. For Package/System Changes

   Always detail what will be installed:

   Need to install [PACKAGE] version [VERSION]
   
   This will:
   - Add [PACKAGE] to dependencies
   - Install [SIZE] of new dependencies
   - Modify package.json/requirements.txt
   
   Proceed?
   

Phase 3: Execute with User Confirmation

7. Wait for Explicit Approval

   • User must respond with: "yes", "proceed", "go ahead", etc.
   • If user says "no", "skip", "wait" → Don't execute
   • If user asks questions → Answer first, then re-ask for approval

8. Execute Only What Was Approved

   • Change only what was proposed
   • No surprise additional changes
   • If you discover more changes needed → Ask again

Permission Categories

❌ ALWAYS Require Approval

File Modifications:

• Edit existing files
• Write to existing files
• Create new files
• Delete files
• Move/rename files
• Change permissions (chmod)

System Operations:

• Install packages (npm install, pip install, apt install)
• Modify system configuration
• Create directories
• Delete directories
• Symbolic links

Git Operations:

• git commit
• git push
• git merge
• git rebase
• git reset

✅ No Approval Needed

Exploratory Operations:

• Read files (cat, Read tool)
• List files (ls, glob)
• Search files (grep, Grep tool)
• Git status/diff/log
• File metadata (stat, file)
• Check if file exists

Information Gathering:

• Check package versions
• Read documentation
• Search code
• Analyze structure

Approval Request Templates

Template 1: Simple Edit

I propose changing [WHAT] in [FILE]. Proceed?

Changes: [BRIEF DESCRIPTION]

Template 2: Multiple File Edit

I propose changes to [N] files. Proceed?

Files to modify:
- [FILE1]: [CHANGE1]
- [FILE2]: [CHANGE2]
- [FILE3]: [CHANGE3]

Reason: [WHY]

Template 3: Risky Operation

⚠️ WARNING: This operation [DESCRIBES RISK]

I need to [OPERATION] which will [CONSEQUENCES].

Should I:
1. Show dry-run first?
2. Proceed with operation?
3. Find safer alternative?

Template 4: Package Installation

Need to install dependencies:
- [PACKAGE1] v[VERSION1]
- [PACKAGE2] v[VERSION2]

Total size: ~[SIZE]
Will modify: [package.json/requirements.txt]

Proceed?

Common Scenarios

Scenario 1: User Asks Question vs Requests Change

User: "How does authentication work?"

• This is a QUESTION → Provide ANSWER
• Do NOT modify code
• Read relevant files and explain

User: "Change authentication to use JWT"

• This is a CHANGE REQUEST → Propose changes and ask approval

Scenario 2: Discovered Additional Changes Needed

While making approved change, you discover related code needs updating:

While implementing [APPROVED CHANGE], I found [RELATED CODE] also needs updating.

Should I also:
- [ADDITIONAL CHANGE]

Or focus only on the approved change?

Scenario 3: Multiple Related Files

When change affects multiple files:

To [ACCOMPLISH GOAL], I need to modify [N] files:

Core changes:
- [FILE1]: [CRITICAL CHANGE]

Supporting changes:
- [FILE2]: [UPDATE IMPORT]
- [FILE3]: [UPDATE CONFIG]

Proceed with all changes?

Rules

✅ Always Do

• Search for existing functionality before proposing changes
• Read files before modifying them
• Explain what will change and why
• Ask explicit approval before Edit/Write/Delete
• Suggest dry-run for destructive operations
• Wait for "yes" or equivalent approval
• Only change what was approved

❌ Never Do

• Modify files without approval
• Make "surprise" additional changes
• Assume questions are change requests
• Skip the approval step
• Change more than what was approved
• Perform destructive operations without dry-run option

⚠️ Special Cases

Typo Fixes:

• Still ask approval, but can be brief: "Fix typo in [FILE] (change 'recieve' to 'receive')?"

Generated Files:

• Usually skip (buildInfo.ts, dist/, etc.)
• If user explicitly asks, then ask approval

Documentation:

• Still ask approval, but lower formality: "Update README to add [SECTION]?"

Decision Flowchart

User request detected
    │
    ├─> Is it a question?
    │   ├─> Yes → Answer, don't change code
    │   └─> No → Continue
    │
    ├─> Does it require file changes?
    │   ├─> No → Just answer/execute
    │   └─> Yes → Continue
    │
    ├─> Search for existing functionality
    │   └─> Report findings
    │
    ├─> Propose specific changes
    │   ├─> What will change
    │   ├─> Which files
    │   └─> Why needed
    │
    ├─> Ask: "Proceed?"
    │   └─> Wait for response
    │
    ├─> User response?
    │   ├─> "Yes"/"Proceed" → Execute changes
    │   ├─> "No"/"Skip" → Don't execute, acknowledge
    │   ├─> Questions → Answer, then re-ask
    │   └─> Unclear → Ask for clarification
    │
    └─> Execute ONLY approved changes
        └─> Report completion

Examples

Example 1: Good Approval Request

User: "Add error handling to the API"

You: "I propose changing the error handling in src/api/routes.ts. Proceed?

Proposed changes:
- Add try-catch blocks to all route handlers
- Create centralized error response formatter
- Add error logging with context

Reason: Currently errors crash the server instead of returning proper HTTP responses"

User: "Yes"

You: [Makes changes]

Example 2: Question vs Change

User: "Why is the API slow?"

You: [Reads code, analyzes]

"Looking at src/api/routes.ts (lines 45-60), the slowness is caused by:
1. N+1 database queries in the user endpoint
2. No caching on frequent lookups
3. Synchronous file operations blocking requests

Would you like me to optimize this?"

[Waits for explicit request to change before proposing changes]

Example 3: Discovering Additional Changes

User: "Update the database schema"

You: "I propose changing the schema in migrations/003_update.sql. Proceed?

Changes:
- Add new 'status' column to users table
- Add index on status for query performance"

User: "Yes"

You: [While implementing, discovers ORM models need updating]

"While adding the database column, I found the ORM models in src/models/user.ts also need updating to reflect the new 'status' field.

Should I also update the ORM models, or just the database schema?"

[Waits for approval on additional change]

Success Criteria

• Every file modification is explicitly approved before execution
• User is never surprised by changes
• Existing functionality is always checked before adding new
• Dry-run options offered for risky operations
• Questions are answered without code changes
• Only approved scope is modified