name	code-change-approval
description	Request approval before modifying files and verify changes are necessary

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

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*"
```
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

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

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.

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?

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

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
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

code-change-approval

Install Skill

SKILL.md