playbooks

home / skills / sounder25 / google-antigravity-skills-library / 18_pre_action_guard

18_pre_action_guard skill

/18_pre_action_guard

This skill validates high-stakes actions before execution, preventing data loss by ensuring safety rules align with the current plan.

npx playbooks add skill sounder25/google-antigravity-skills-library --skill 18_pre_action_guard

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
2.5 KB
---
name: Pre-Action Guard
description: A QA gate that validates potentially destructive or irreversible actions before execution.
version: 1.0.0
author: Antigravity Skills Library
created: 2026-01-16
leverage_score: 5/5
---

# SKILL-018: Pre-Action Guard

## Overview

Enforces a **"Measure Twice, Cut Once"** philosophy. This skill intercepts high-stakes actions (file writes, command execution) and validates them against safety rules and the current active plan to prevent accidental data loss or system corruption.

## Trigger Phrases

- `check safety`
- `verify action`
- `is this safe`
- `guard check`

## Inputs

| Parameter | Type | Required | Default | Description |
|-----------|------|----------|---------|-------------|
| `--Action` | string | Yes | - | The tool/verb being performed (e.g. `write_to_file`, `rm`) |
| `--Target` | string | Yes | - | The file path or command argument |
| `--Plan` | string | No | $null | The current plan context for alignment check |

## Outputs

### 1. Assessment Result (JSON)

```json
{
  "allowed": false,
  "risk_level": "CRITICAL",
  "reason": "Root directory deletion detected.",
  "warnings": ["Target matches blocked pattern '/*'."]
}
```

### 2. Risk Levels

- `NONE`: Read-only operations.
- `LOW`: Safe writes (files in temp, new files).
- `MEDIUM`: Modifying existing non-critical files.
- `HIGH`: Modifying config/env files.
- `CRITICAL`: Destructive delete/format commands.

## Preconditions

1. Valid tool/action inputs.
2. PowerShell 5.1+ or Core 7+.

## Safety/QA Checks

1. **Auto-Block**: Root deletions (`/`, `C:\`) are automatically blocked.
2. **Context Awareness**: Checks `.env` and `config` keywords for higher sensitivity.
3. **Command-Only Discipline**:
   - Rejects output containing shell prompts (`PS C:\`, `>`).
   - Rejects lines that look like terminal output (e.g., `Everything up-to-date`, `At line:`, `CategoryInfo:`).
   - Rejects mixed snippets containing both commands and output.
   - **Enforcement**: All runnable commands must be isolated in a clean, validated block.

## Stop Conditions

| Condition | Action |
|-----------|--------|
| Missing Action/Target | Return error |
| CRITICAL risk | Return `allowed: false` |
| Mixed Output Detected | Return `allowed: false` |

## Implementation

See `scripts/guard_check.ps1`.

## Integration with Other Skills

**All agents must:**

1. Call this skill BEFORE running `write_to_file` on existing files.
2. Call this skill BEFORE running any `run_command` containing `rm`, `del`, `drop`.
3. If `allowed` is false, **STOP** and ask user for confirmation.

Overview

This skill implements a Pre-Action Guard that validates potentially destructive or irreversible actions before execution. It enforces a "measure twice, cut once" policy to prevent accidental data loss or system corruption by blocking or flagging high-risk operations.

How this skill works

The guard inspects the declared action (e.g., write_to_file, rm) and its target, evaluates them against a set of safety checks and contextual plan information, and returns a structured assessment with allowed, risk_level, reason, and warnings. It auto-blocks clear dangerous patterns (root deletions), raises sensitivity for config/env targets, and detects mixed command/output snippets to enforce command-only discipline.

When to use it

  • Before any file write to an existing file
  • Before running commands that include rm, del, drop, format
  • When an agent proposes changes to config or environment files (.env, config)
  • When plan context is available and actions must be aligned with intent
  • Prior to bulk or recursive operations affecting many files or directories

Best practices

  • Always provide explicit --Action and --Target parameters; return an error if missing
  • Supply the current --Plan when available to enable alignment checks
  • Treat CRITICAL results as blockers: stop and ask for explicit user confirmation
  • Keep runnable commands isolated in clean blocks without terminal output
  • Favor safe defaults (deny on ambiguity) and surface clear remediation steps in reason/warnings

Example use cases

  • Agent wants to delete a directory: guard inspects target and blocks root or wildcard patterns
  • Agent plans to overwrite a config file: guard flags HIGH risk and requires confirmation
  • Automated deploy step proposes removing files: guard detects mixed output in snippet and rejects
  • CI job attempts recursive delete: guard returns CRITICAL for patterns like /* or C:\
  • Scripted migration writes new temporary files: guard marks as LOW or NONE depending on target

FAQ

What happens if the guard returns allowed: false?

The agent must stop and prompt the user for explicit confirmation before proceeding; do not execute the action automatically.

How does the guard treat config or .env targets?

Targets containing config or .env keywords are treated with elevated sensitivity and typically rank as HIGH risk unless additional context reduces risk.