Understanding G‑Stack Safety Guardrails: `/careful`, `/freeze`, and `/guard`

G‑Stack provides three built‑in safety guardrails—/careful, /freeze, and /guard—that intercept destructive commands and restrict file edits to designated directories through PreToolUse hooks.

The garrytan/gstack repository implements these guardrails as optional skills you can activate during AI‑driven development sessions. Each guardrail installs lightweight shell hooks that analyze tool calls before execution, preventing accidental data loss or unauthorized file modifications.

What Are G‑Stack Safety Guardrails?

Guardrails in gstack are session‑scoped protections implemented as skill modules. When activated, they register PreToolUse hooks that examine incoming Bash, Edit, or Write commands against predefined safety rules. If a command violates a rule, the hook returns a permissionDecision—either "ask" for user confirmation or "deny"—blocking execution immediately.

All guardrail logic resides in self‑contained skill directories within the repository, with hook scripts installed locally when you enable a skill.

The Three Guardrail Skills

/careful – Destructive Command Detection

The /careful guardrail scans every Bash command for high‑risk patterns such as rm -rf, DROP TABLE, git push --force, and kubectl delete. When a pattern match occurs in careful/bin/check‑careful.sh, the skill returns permissionDecision: "ask" and renders a terminal warning, allowing you to approve or cancel the operation.

According to careful/SKILL.md (lines 41‑50), the pattern table is hard‑coded into the check script, ensuring zero‑latency detection without external dependencies. This guardrail is ideal when debugging production clusters or databases where a single mistyped command could wipe critical data.

/freeze – Directory‑Constrained Editing

The /freeze guardrail restricts Edit and Write operations to a single directory you specify at activation. The skill stores your chosen path in ${GSTACK_STATE_ROOT}/freeze‑dir.txt and runs check‑freeze.sh as a PreToolUse hook for both file modification tools.

If the target file path does not start with the frozen directory, the hook returns permissionDecision: "deny" and blocks the edit. As defined in freeze/SKILL.md (lines 19‑30), this prevents accidental changes outside your current focus area—such as modifying configuration files while working deep inside a specific module.

/guard – Combined Protection Mode

The /guard guardrail merges the capabilities of /careful and /freeze into a single activation command. It registers three simultaneous hooks: one for Bash commands (using check‑careful.sh) and two for file operations (using check‑freeze.sh).

This "maximum safety" mode ensures destructive command warnings remain active while edits are physically constrained to your designated boundary. The skill definition in guard/SKILL.md (lines 19‑34) declares these combined hooks, making it the recommended choice for risky refactors or production hotfixes.

How the Guardrails Work Under the Hood

Each guardrail operates through PreToolUse hooks defined in the respective SKILL.md files. When you issue a command like /careful, gstack installs the hook script locally and begins intercepting tool calls.

• Hook Execution: Before any Bash, Edit, or Write tool runs, gstack executes the corresponding check script (e.g., careful/bin/check‑careful.sh).
• Decision Logic: The script analyzes the command JSON. For /careful, it pattern‑matches against risky strings; for /freeze, it performs a path prefix check against freeze‑dir.txt.
• Response Handling: The hook outputs a JSON response with permissionDecision set to "ask", "deny", or "allow", which gstack evaluates to determine whether to proceed, warn, or block.

Analytics data regarding skill usage is optionally logged to ~/.gstack/analytics/skill‑usage.jsonl, though this remains local and is never transmitted off‑machine.

Practical Usage Examples

Activate selective protection depending on your risk surface:

# Enable destructive command warnings only

/careful

# → G‑Stack now warns before any dangerous Bash command

# Attempt a risky deletion (will be intercepted)

rm -rf /important/data

# ⚠️ Warning: destructive command detected. Proceed? (yes/no)

Restrict edits to a specific module boundary:

# Limit all file modifications to the src/api directory

/freeze

# (Assistant prompts) Which directory should I restrict edits to?

# > src/api

# → Subsequent Edit/Write actions outside src/api/ are blocked

# Attempt to edit a file outside the boundary (blocked)

Edit ./README.md

# ❌ Edit denied: file is outside the freeze directory.

Enable comprehensive safety for high‑risk sessions:

# Activate combined protection mode

/guard

# (Assistant prompts) Guard mode: which directory should edits be restricted to?

# > src/api

# → Both safeguards now active

# Dangerous commands still trigger warnings

git push -f origin main

# ⚠️ Warning: force‑push detected. Proceed? (yes/no)

# Valid edits within the boundary succeed

Edit ./src/api/userController.ts

# ✅ Edit allowed

Summary

• /careful intercepts destructive Bash patterns (e.g., rm -rf, git push --force) via check‑careful.sh, requiring explicit user confirmation before execution.
• /freeze constrains Edit and Write operations to a single designated directory using check‑freeze.sh, blocking any file modifications outside that path.
• /guard combines both mechanisms, registering three PreToolUse hooks for maximum safety during production work or complex refactors.
• All guardrails are session‑scoped, remaining active until you explicitly end the conversation or disable them (e.g., via /unfreeze).

Frequently Asked Questions

What happens if I run a dangerous command while /careful is active?

If the command matches a risky pattern defined in careful/bin/check‑careful.sh, gstack pauses execution and displays a warning in the conversation thread. You must explicitly confirm with "yes" to proceed, or "no" to cancel the operation. This prevents accidental execution of commands like kubectl delete or DROP TABLE.

Can I change the frozen directory after activating /freeze?

Yes. Running /unfreeze deactivates the current boundary, allowing you to run /freeze again and specify a new directory. The path is stored in ${GSTACK_STATE_ROOT}/freeze‑dir.txt, and the check‑freeze.sh hook reads this file for every subsequent Edit or Write operation.

Does /guard create separate log entries for analytics?

The analytics system logs skill usage to ~/.gstack/analytics/skill‑usage.jsonl regardless of whether you use /careful, /freeze, or /guard individually. When using /guard, the system records the activation event but does not duplicate entries for the underlying sub‑skills; it treats /guard as a single combined session scope.

Are these guardrails available in all gstack environments?

The guardrails are implemented as optional skills within the garrytan/gstack repository. They are available wherever you can install gstack skills, including local CLI usage and supported IDE integrations, provided the skill files (careful/SKILL.md, freeze/SKILL.md, guard/SKILL.md) are present in your installation.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}