Skill: yconst/request-approval (version 1.0.0)

--- name: request-approval description: Use Preloop's request_approval tool to get human approval before risky operations like deletions, production changes, or external modifications compatibility: Requires Preloop MCP server configured and accessible metadata: author: preloop version: "1.0" --- # Request Approval Skill Use Preloop's `request_approval` MCP tool to get human approval before executing risky operations. Preloop will notify the user (via Slack, email, mobile apps, etc.) and wait for their response. ## Setup Preloop must be configured as an MCP server. See [references/SETUP.md](references/SETUP.md) for configuration details. ## When to Request Approval ### ALWAYS Request Approval For: - Deleting anything (files, directories, database records, cloud resources) - Production changes (deployments, config changes, environment variables) - Database operations (schema changes, migrations, bulk deletions/updates) - External modifications (creating/merging PRs, posting to APIs, sending emails) - Security changes (permissions, access controls, API keys) - Financial operations (purchases, charges, refunds) - System modifications (installing packages, changing system settings, CI/CD changes) ### Usually Request Approval For: - Creating pull requests or issues (unless explicitly requested) - Pushing commits to main/master branches - Modifying critical files (package.json, requirements.txt, docker-compose.yml, etc.) - Running commands that modify system state - Making bulk changes (affecting many files/records) ### DON'T Request Approval For: - Reading files or data - Searching or querying - Creating feature branches - Running tests (in isolated environments) - Making commits to feature branches ## How to Use Call the `request_approval` tool BEFORE executing the risky operation. ### Parameters **Required:** - `operation` (string): Clear, specific description of what you'll do - ✅ Good: "Delete the logs/2024-01/ directory containing 1,234 log files (2.3GB)" - ❌ Bad: "Delete some logs" - `context` (string): Additional details about what will be affected - ✅ Good: "This directory contains archived application logs from January 2024. The logs have been backed up to S3. Deleting will free up 2.3GB." - ❌ Bad: "Old logs" - `reasoning` (string): Why this operation is necessary - ✅ Good: "Disk usage is at 92% capacity. These logs are archived in S3 and no longer needed locally." - ❌ Bad: "Need more space" **Optional:** - `caller` (string): Auto-populated by Preloop - `approval_policy` (string): Specific approval policy name (uses account default if omitted) ### Response The tool returns a string: - **Approved**: Success message → proceed with the operation - **Denied**: "Approval denied" or "Approval denied: {reason}" → STOP, don't execute - **Error**: Error message → check configuration or try again ## Quick Example **Task**: User asks to delete old cache files **Your workflow**: 1. Check what exists: 3,421 cache files, 1.8GB, from last week 2. Call `request_approval`: - operation: "Delete the temp-cache/ directory" - context: "Contains 3,421 cache files totaling 1.8GB from batch jobs that ran last week. All jobs completed successfully." - reasoning: "Cache is no longer needed and is consuming disk space. Results are in the database." 3. Wait for response 4. If "denied" in response → tell user it's cancelled, ask for alternatives 5. If approved → proceed with deletion See [references/EXAMPLES.md](references/EXAMPLES.md) for more examples. ## Decision Framework When unsure: 1. **Can this be undone easily?** NO → Request approval 2. **Could this cause harm or data loss?** YES → Request approval 3. **Is this modifying production or external systems?** YES → Request approval 4. **Would a human want to review this first?** YES → Request approval 5. **Am I uncertain about the safety?** YES → Request approval **Golden Rule**: When in doubt, request approval. Better to ask unnecessarily than to cause harm. ## If Approval is Denied 1. **Stop immediately** - do NOT proceed 2. **Check for comments** - denial may include reasoning 3. **Inform the user** - explain why it was cancelled 4. **Look for alternatives** - can you accomplish the goal differently? 5. **Don't retry** - don't ask again unless circumstances change ## Best Practices **DO:** - ✅ Request approval BEFORE executing - ✅ Be specific and detailed - ✅ Include numbers (file count, size, affected records) - ✅ Explain the impact - ✅ Respect denials **DON'T:** - ❌ Execute first, then ask - ❌ Be vague - ❌ Bundle multiple operations - ❌ Proceed if denied - ❌ Skip approval because you think it's "probably fine" ## Additional Resources - [references/SETUP.md](references/SETUP.md) - Configuration and MCP server setup - [references/EXAMPLES.md](references/EXAMPLES.md) - Detailed examples and workflows - [references/TROUBLESHOOTING.md](references/TROUBLESHOOTING.md) - Common errors and solutions --- **Remember**: Safety first! Trust is earned by being cautious and respectful of the user's systems and data.

path: references/EXAMPLES.md
content: # Detailed Examples

This document provides comprehensive examples of using the `request_approval` tool in various scenarios.

## Example 1: Deleting Files

**Scenario**: User asks "Delete the old log files to free up space"

**Step-by-step workflow**:

1. **Investigate first**:
   - Check what files exist: `ls -lh logs/`
   - Find: logs/2024-01/ directory
   - Contains: 1,234 files
   - Total size: 2.3GB
   - Last modified: 2 weeks ago

2. **Call request_approval**:
   - operation: "Delete the logs/2024-01/ directory"
   - context: "Contains 1,234 log files totaling 2.3GB from January 2024. These are archived application logs. A backup exists in S3 bucket 'company-logs'. Deleting will free up 2.3GB of disk space."
   - reasoning: "Disk usage is at 92% capacity. These logs are archived in S3 and no longer needed locally. The application is showing warnings about low disk space."

3. **Wait for response**:
   - If approved: "Approval granted. You may proceed with the operation."
   - If denied: "Approval denied: Please verify the S3 backup first."

4. **Act on response**:
   - If approved: Execute `rm -rf logs/2024-01/` and confirm to user
   - If denied: Tell user "The deletion was cancelled because the approver wants to verify the S3 backup first. Would you like me to check if the backup exists?"

## Example 2: Creating a Pull Request

**Scenario**: You've fixed a bug and need to create a PR

**Workflow**:

1. **Review changes**:
   - Files modified: auth.py, middleware.py, tests/test_auth.py
   - Lines changed: +47, -12
   - Branch: feature/fix-auth-bug → main

2. **Call request_approval**:
   - operation: "Create pull request: 'Fix authentication bug #1234'"
   - context: "PR will merge feature/fix-auth-bug into main branch. Changes: 3 files modified (auth.py, middleware.py, tests/test_auth.py), +47 lines, -12 lines. Adds validation for expired tokens and handles edge case where tokens expire during request processing."
   - reasoning: "Bug #1234 causes users with expired tokens to see a 500 error instead of being redirected to login. This PR fixes the issue and adds test coverage. All tests pass locally."

3. **Handle response**:
   - If approved: Create the PR using `gh pr create --title "Fix authentication bug #1234" --body "..."`
   - If denied: "Approval denied: Please add integration tests first."
     - Tell user: "The PR was not created because the reviewer wants integration tests added first. Should I add those tests now?"

## Example 3: Production Deployment

**Scenario**: User asks "Deploy version 2.4.1 to production"

**Workflow**:

1. **Gather context**:
   - Current production version: 2.4.0
   - New version: 2.4.1
   - Changes: Bug fixes for issues #1234, #1235, #1236
   - Staging status: Deployed 48 hours ago, all tests passing
   - Affected services: api-server, worker, scheduler, notifications
   - Expected downtime: ~30 seconds

2. **Call request_approval**:
   - operation: "Deploy version 2.4.1 to production environment"
   - context: "Deployment will update 4 backend services (api-server, worker, scheduler, notifications) and restart them. Expected downtime: ~30 seconds. Current version: 2.4.0. Staging deployment has been running for 48 hours with all tests passing. No customer-reported issues in staging."
   - reasoning: "This release includes critical bug fixes for issues #1234, #1235, and #1236 affecting 12% of users. The bugs cause intermittent failures in the checkout flow. Changes have been thoroughly tested in staging."

3. **Handle response**:
   - If approved: Execute deployment commands
   - If denied: "Approval denied: Please schedule during maintenance window (tonight 2-4am)."
     - Tell user: "The deployment was not approved for immediate execution. The approver requested it be scheduled during tonight's maintenance window (2-4am). Should I schedule it for then?"

## Example 4: Database Migration

**Scenario**: Running a database migration that modifies schema

**Workflow**:

1. **Review migration**:
   - Migration file: migrations/2024_01_add_user_preferences.sql
   - Actions: Add new table `user_preferences`, add foreign key to `users` table
   - Affected rows: 0 (new table, no existing data)
   - Reversible: Yes (down migration exists)

2. **Call request_approval**:
   - operation: "Run database migration: 2024_01_add_user_preferences"
   - context: "This migration creates a new table 'user_preferences' with columns id, user_id, preferences (jsonb), created_at, updated_at. It adds a foreign key constraint to the users table. No existing data will be modified. A rollback migration is available. Estimated execution time: <5 seconds."
   - reasoning: "User preferences feature requires a dedicated table to store per-user settings. The migration has been tested in dev and staging environments without issues."

3. **Handle response**:
   - If approved: Run migration, verify success, inform user
   - If denied: "Approval denied: Please run during low-traffic hours."
     - Explain to user and offer to schedule for later

## Example 5: Modifying Production Config

**Scenario**: Changing an environment variable in production

**Workflow**:

1. **Identify change**:
   - File: config/production.env
   - Variable: DATABASE_URL
   - Old value: postgres://prod-db:5432/app
   - New value: postgres://prod-db-replica:5432/app
   - Impact: Switches read operations to replica

2. **Call request_approval**:
   - operation: "Modify environment variable DATABASE_URL in production config"
   - context: "Current value: postgres://prod-db:5432/app\nNew value: postgres://prod-db-replica:5432/app\nThis switches the application to use the read replica database for read operations. The primary database will still handle writes. Services will need to be restarted for the change to take effect."
   - reasoning: "Primary database is under heavy load (85% CPU usage). Switching read operations to the replica will distribute the load and improve response times. The replica is fully synced and healthy."

3. **Handle response**:
   - If approved: Update config file, note that restart is needed
   - If denied: "Approval denied: The replica is currently 5 minutes behind. Wait for sync."
     - Inform user and monitor replica lag

## Example 6: Conditional Approval

**Scenario**: Only request approval in production, not in dev/staging

**Workflow**:

1. **Determine environment**:
   - Check current branch or environment variable
   - Production detected

2. **Conditional logic**:
   - If production: Call `request_approval` (as shown above)
   - If dev/staging: Proceed directly without approval

3. **Tell the user**:
   - Production: "I've requested approval for this operation. Waiting for response..."
   - Dev/Staging: "This is a development environment, so I'm proceeding directly without approval."

## Example 7: Bulk File Operations

**Scenario**: Deleting multiple files matching a pattern

**Workflow**:

1. **Find files**:
   - Pattern: `*.tmp` files
   - Found: 156 files across 23 directories
   - Total size: 487 MB
   - Oldest: 45 days ago

2. **Call request_approval**:
   - operation: "Delete 156 temporary files matching *.tmp pattern"
   - context: "Found 156 .tmp files across 23 directories, totaling 487 MB. Files are distributed throughout the project. Oldest file is 45 days old. These are temporary build artifacts and cache files that are safe to delete."
   - reasoning: "Cleaning up temporary files to reduce repository size and improve clone times. All files have .tmp extension indicating they are temporary. None are tracked in git."

3. **Handle response**:
   - If approved: Delete files, report count
   - If denied: Explain cancellation and ask for guidance

## Example 8: Installing Dependencies

**Scenario**: User asks to install a new npm package

**Workflow**:

1. **Identify package**:
   - Package: lodash@4.17.21
   - Type: Production dependency
   - Size: 1.4 MB
   - License: MIT

2. **Call request_approval**:
   - operation: "Install npm package: lodash@4.17.21"
   - context: "Package: lodash@4.17.21 (production dependency)\nSize: 1.4 MB\nLicense: MIT\nThis will modify package.json and package-lock.json. The package provides utility functions for data manipulation."
   - reasoning: "User requested lodash for array manipulation in the data processing module. This is a widely-used, well-maintained package with 50M+ weekly downloads."

3. **Handle response**:
   - If approved: Run `npm install lodash@4.17.21`
   - If denied: "Approval denied: Use native JavaScript methods instead."
     - Inform user and discuss alternatives

## Common Patterns

### Pattern 1: Gather Info → Request → Wait → Act

Always follow this sequence:
1. Gather information about what will be changed
2. Request approval with detailed context
3. Wait for the response
4. Act based on approval/denial

### Pattern 2: Provide Alternatives When Denied

If denied, offer alternatives:
- "Would you like me to [alternative approach] instead?"
- "Should I schedule this for later?"
- "Can I do [safer version] instead?"

### Pattern 3: Include Rollback Information

When available, mention rollback options:
- "A rollback script is available if needed"
- "This change can be reverted by restoring from backup"
- "The previous configuration is saved in [location]"

### Pattern 4: Quantify Everything

Always include numbers:
- File counts
- Sizes (MB, GB)
- Affected records
- Time estimates
- Impact metrics

This helps approvers make informed decisions quickly.


path: references/TROUBLESHOOTING.md
content: # Troubleshooting

This document covers common issues when using the `request_approval` tool and how to resolve them.

## Connection Issues

### Error: "Tool not found"

**Cause**: The MCP server is not properly configured or the agent cannot connect to it.

**Solutions**:
1. Verify Preloop is configured in your agent's MCP settings
2. Check the URL is correct:
   - Production: `https://preloop.ai/mcp/v1`
   - Self-hosted: `https://your-instance.com/mcp/v1`
   - Local: `http://localhost:8000/mcp/v1`
3. Restart your agent after making configuration changes
4. Check network connectivity to the Preloop instance
5. Review agent logs for connection errors

**Testing**:
```bash
# Test if the MCP endpoint is accessible
curl https://preloop.ai/mcp/v1/health

# Should return a success response
```

### Error: "MCP server not responding"

**Cause**: The Preloop instance is down or unreachable.

**Solutions**:
1. Check if the Preloop instance is running
2. Verify your internet connection
3. Check for firewall or proxy blocking the connection
4. Try accessing the Preloop web interface to confirm it's online
5. Contact your Preloop administrator if self-hosted

## Authentication Issues

### Error: "Unauthorized" or "403 Forbidden"

**Cause**: Missing or invalid API token.

**Solutions**:
1. Generate an API token in Preloop:
   - Log in to Preloop
   - Go to Settings → API Tokens
   - Create a new token
   - Copy the token value
2. Add the token to your MCP configuration:
   ```json
   {
     "mcpServers": {
       "preloop": {
         "url": "https://preloop.ai/mcp/v1",
         "headers": {
           "Authorization": "Bearer YOUR_TOKEN_HERE"
         }
       }
     }
   }
   ```
3. Restart your agent

### Error: "Token expired"

**Cause**: Your API token has expired.

**Solutions**:
1. Generate a new API token in Preloop
2. Update your MCP configuration with the new token
3. Restart your agent

## Approval Policy Issues

### Error: "No default approval policy found"

**Cause**: Your Preloop account doesn't have a default approval policy configured.

**Solutions**:
1. Log in to Preloop
2. Navigate to Settings → Approval Policies
3. Create a new approval policy:
   - Name: "Default Agent Approval"
   - Notification method: Slack, email, mobile app, or webhook
   - Approvers: Select users/teams who can approve
   - Timeout: 5 minutes (or your preference)
   - **Check "Set as Default"**
4. Save the policy
5. Try the approval request again

### Error: "Approval policy 'xyz' not found"

**Cause**: You specified a policy name that doesn't exist.

**Solutions**:
1. Check the policy name for typos
2. Verify the policy exists in Preloop (Settings → Approval Policies)
3. Use the exact policy name (case-sensitive)
4. Or omit the `approval_policy` parameter to use the default

## Timeout Issues

### Error: "Approval timed out"

**Cause**: No one approved or declined within the configured timeout period (default 5 minutes).

**What to do**:
1. Treat this as a denial - do NOT proceed with the operation
2. Inform the user: "The approval request timed out after 5 minutes. No one responded to the request."
3. Ask if they want to retry or take a different approach
4. Consider increasing the timeout in the approval policy if this happens frequently

### Approval is taking too long

**Not an error, but...**:

If approvals are consistently slow:
1. Check that approvers are receiving notifications
2. Verify notification channels are working (Slack, email, etc.)
3. Consider adding more approvers to the policy
4. Adjust the timeout if needed for your workflow

## Request Issues

### Error: "Invalid parameters"

**Cause**: Missing or malformed required parameters.

**Solutions**:
1. Verify all required parameters are provided:
   - `operation` (string, required)
   - `context` (string, required)
   - `reasoning` (string, required)
2. Check parameter types (all should be strings)
3. Ensure parameters are not empty

**Example of correct usage**:
```javascript
request_approval(
  operation: "Delete file: config.yml",
  context: "Production config file, 2KB",
  reasoning: "User requested deletion"
)
```

### Error: "Request failed"

**Cause**: Generic error during request processing.

**Solutions**:
1. Check the full error message for details
2. Verify the Preloop instance is healthy
3. Check agent logs for more information
4. Retry the request
5. Contact support if the issue persists

## Notification Issues

### Approvers aren't receiving notifications

**Cause**: Notification channels not configured or disabled.

**Solutions**:
1. Verify the approval policy has notification methods configured
2. Check that approvers have notification preferences enabled:
   - Log in to Preloop
   - Go to Settings → Notification Preferences
   - Enable email, mobile push, or other channels
3. For Slack:
   - Verify the Slack integration is connected
   - Check the webhook URL is correct
   - Test the Slack channel
4. For email:
   - Check spam/junk folders
   - Verify email addresses are correct
   - Check SMTP settings in Preloop

### Mobile notifications not working

**Cause**: Push notification service not configured or device not registered.

**Solutions**:
1. Install the Preloop mobile app (iOS or Android)
2. Log in to your account
3. Grant notification permissions when prompted
4. Verify your device is registered:
   - Open mobile app
   - Go to Settings → Devices
   - Your device should be listed
5. Test with a sample approval request

## Response Issues

### Unclear whether approval was granted

**Problem**: Response message is ambiguous.

**What to do**:
1. Check if the response contains "denied" (case-insensitive) → treat as denial
2. Check if the response contains "approved" or "granted" → treat as approval
3. If still unclear:
   - Err on the side of caution
   - Do NOT proceed with the operation
   - Ask the user for clarification
   - Log the unexpected response format

### Response seems wrong

**Problem**: Approval was granted but you're unsure it should have been.

**What to do**:
1. Trust the approval - the human approver has made their decision
2. Proceed with the operation as approved
3. If you have serious concerns, you can:
   - Inform the user of your concerns
   - Suggest they verify the approval was intentional
   - But ultimately respect the approval if the user confirms

## Common Mistakes

### Mistake 1: Calling approval AFTER the operation

**Wrong**:
```
1. Delete the file
2. Call request_approval
```

**Right**:
```
1. Call request_approval
2. Wait for approval
3. Delete the file
```

### Mistake 2: Proceeding when denied

**Wrong**:
```
Response: "Approval denied"
Agent: *deletes the file anyway*
```

**Right**:
```
Response: "Approval denied"
Agent: "The operation was cancelled because approval was denied."
```

### Mistake 3: Vague descriptions

**Wrong**:
```javascript
request_approval(
  operation: "Delete stuff",
  context: "Some files",
  reasoning: "Cleanup"
)
```

**Right**:
```javascript
request_approval(
  operation: "Delete 47 temporary files in /tmp/cache/",
  context: "47 .tmp files totaling 234 MB, created >30 days ago",
  reasoning: "Disk usage at 90%, cleaning old temp files"
)
```

### Mistake 4: Bundling multiple operations

**Wrong**:
```javascript
request_approval(
  operation: "Delete logs, update config, and restart services",
  ...
)
```

**Right**:
```javascript
// Request 1
request_approval(
  operation: "Delete logs from /var/log/old/",
  ...
)

// Request 2
request_approval(
  operation: "Update production config: database URL",
  ...
)

// Request 3
request_approval(
  operation: "Restart application services",
  ...
)
```

## Getting Help

If you're still stuck:

1. **Check Preloop Status**:
   - Visit status.preloop.ai (if available)
   - Check for known issues or maintenance

2. **Review Logs**:
   - Agent logs for connection/request errors
   - Preloop logs (if self-hosted) for server-side issues

3. **Contact Support**:
   - Documentation: https://docs.preloop.ai
   - Community: https://community.preloop.ai
   - GitHub Issues: https://github.com/preloop/preloop/issues
   - Email: [REDACTED_SECRET] (for enterprise customers)

4. **Provide Details**:
   When reporting issues, include:
   - Error message (full text)
   - Agent type and version
   - Preloop instance URL (without tokens)
   - Steps to reproduce
   - Relevant logs (sanitized)

## Debug Checklist

When troubleshooting, verify:

- [ ] Preloop MCP server is configured in agent settings
- [ ] MCP server URL is correct
- [ ] Agent has been restarted after configuration changes
- [ ] Preloop instance is accessible (try opening in browser)
- [ ] API token is valid (if authentication required)
- [ ] Default approval policy is configured in Preloop
- [ ] Approvers have notification preferences enabled
- [ ] All required parameters are provided in request
- [ ] Request includes specific, detailed information
- [ ] Not proceeding with operation if approval denied

If all items are checked and it still doesn't work, contact support with the error details.


path: references/SETUP.md
content: # Setup & Configuration

This document explains how to configure Preloop as an MCP server for your agent.

## MCP Server Endpoint

Preloop's MCP server is available at:
- **Production**: `https://preloop.ai/mcp/v1`
- **Self-hosted**: `https://your-preloop-instance.com/mcp/v1`
- **Local development**: `http://localhost:8000/mcp/v1`

## Configuration by Agent

### Claude Desktop

Add to your `claude_desktop_config.json`:

```json
{
  "mcpServers": {
    "preloop": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-everything"],
      "env": {
        "PRELOOP_URL": "https://preloop.ai/mcp/v1"
      }
    }
  }
}
```

Or if using HTTP transport directly:

```json
{
  "mcpServers": {
    "preloop": {
      "url": "https://preloop.ai/mcp/v1",
      "transport": "sse"
    }
  }
}
```

**File locations:**
- macOS: `~/Library/Application Support/Claude/claude_desktop_config.json`
- Windows: `%APPDATA%\Claude\claude_desktop_config.json`
- Linux: `~/.config/Claude/claude_desktop_config.json`

### Cline (VSCode Extension)

Add to your Cline settings:

```json
{
  "mcpServers": {
    "preloop": {
      "url": "https://preloop.ai/mcp/v1",
      "transport": "sse"
    }
  }
}
```

### Other Agents

For agents that support MCP servers, configure:
- **URL**: `https://preloop.ai/mcp/v1` (or your instance URL)
- **Transport**: SSE (Server-Sent Events) or HTTP
- **Authentication**: Include your Preloop API token in headers if required

## Verifying Connection

Once configured, restart your agent and verify:
1. The `request_approval` tool appears in the available tools list
2. Test with a simple approval request
3. Check that notifications are being sent (Slack, email, etc.)

## Approval Policy Setup

Before using the skill, you need an approval policy configured in Preloop:

1. Log in to your Preloop instance
2. Navigate to **Settings** → **Approval Policies**
3. Create a new policy:
   - **Name**: e.g., "Default Agent Approval"
   - **Notification Method**: Slack, email, mobile app, or webhook
   - **Approvers**: Select users or teams who can approve
   - **Timeout**: Default is 5 minutes
   - **Set as Default**: Enable this for automatic use
4. Save the policy

Without an approval policy, the `request_approval` tool will return an error.

## Authentication

If your Preloop instance requires authentication:

1. Generate an API token in Preloop (Settings → API Tokens)
2. Add to your MCP server configuration:
   ```json
   {
     "mcpServers": {
       "preloop": {
         "url": "https://your-instance.com/mcp/v1",
         "transport": "sse",
         "headers": {
           "Authorization": "Bearer YOUR_API_TOKEN"
         }
       }
     }
   }
   ```

## Troubleshooting

### Connection Issues

**Problem**: "Tool not found" or "MCP server not responding"

**Solutions**:
- Verify the URL is correct (check for typos)
- Ensure the Preloop instance is running and accessible
- Check network/firewall settings
- Restart your agent after configuration changes

### Authentication Issues

**Problem**: "Unauthorized" or "403 Forbidden"

**Solutions**:
- Verify your API token is valid and not expired
- Check that the token has the correct permissions
- Ensure the token is included in the headers correctly

### No Approval Policy

**Problem**: "No default approval policy found"

**Solution**: Create and configure an approval policy as described above.

## Advanced Configuration

### Multiple Preloop Instances

You can configure multiple Preloop instances:

```json
{
  "mcpServers": {
    "preloop-prod": {
      "url": "https://prod.preloop.ai/mcp/v1",
      "transport": "sse"
    },
    "preloop-dev": {
      "url": "https://dev.preloop.ai/mcp/v1",
      "transport": "sse"
    }
  }
}
```

### Custom Timeout

To override the default timeout:

```json
{
  "mcpServers": {
    "preloop": {
      "url": "https://preloop.ai/mcp/v1",
      "transport": "sse",
      "timeout": 600000
    }
  }
}
```

(Timeout in milliseconds; 600000 = 10 minutes)

## Support

For setup assistance:
- Documentation: https://docs.preloop.ai
- Community: https://community.preloop.ai
- Issues: https://github.com/preloop/preloop/issues


path: README.md
content: # Request Approval Skill

This skill teaches AI agents to use Preloop's `request_approval` MCP tool for safe operation with human oversight.

## Structure

```
request-approval/
├── SKILL.md                    # Main skill file (agents load this first)
├── README.md                   # This file
└── references/
    ├── SETUP.md               # Configuration and MCP server setup
    ├── EXAMPLES.md            # Detailed examples and workflows
    └── TROUBLESHOOTING.md     # Common errors and solutions
```

## Progressive Disclosure

This skill follows the progressive disclosure pattern:

1. **SKILL.md** (~150 lines): Core instructions loaded when skill is activated
   - When to request approval
   - How to use the tool
   - Quick example
   - Decision framework

2. **references/** (loaded on-demand): Detailed documentation
   - SETUP.md: Configuration instructions
   - EXAMPLES.md: 8+ detailed examples
   - TROUBLESHOOTING.md: Error resolution

Agents load SKILL.md initially, then reference additional files only when needed.

## Installation

### For Users

Copy this directory to your agent's skills folder:

**Claude Desktop / Claude Code:**
```bash
cp -r request-approval ~/.claude/skills/
```

**Cline:**
```bash
cp -r request-approval ~/.cline/skills/
```

**Other agents:**
Check your agent's documentation for the skills directory location.

### For Distribution

This skill can be:
- Bundled with Preloop installations
- Distributed via package managers
- Shared as a git repository
- Included in agent presets

## Configuration

Before using this skill:

1. Configure Preloop as an MCP server (see [references/SETUP.md](references/SETUP.md))
2. Create an approval policy in Preloop
3. Set the policy as default
4. Restart your agent

## Usage

Once installed and configured, agents will automatically:
- Identify risky operations that need approval
- Call the `request_approval` tool before executing
- Wait for human approval/denial
- Proceed only if approved

## Validation

This skill follows the [Agent Skills specification](https://agentskills.io/specification).

Validate with:
```bash
npm install -g @agentskills/cli
agentskills validate request-approval/
```

## License

See the main Preloop repository for license information.

## Support

- Documentation: https://docs.preloop.ai
- Community: https://community.preloop.ai
- GitHub: https://github.com/preloop/preloop


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)