guard — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited guard (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use when asked to "guard mode", "full safety", "lock it down", or "maximum safety".
Activates both destructive command warnings and directory-scoped edit restrictions. This is /careful + /freeze in a single command.
Dependency note: This skill references hook scripts from the sibling /careful and /freeze skill directories. Both must be installed (they are installed together by the vibestack install script).
Where this is enforced. Both protections run as Claude Code PreToolUse hooks. Cursor, Kiro and Codex install the same skill, but the hooks are not guaranteed to run there; outside Claude Code /guard is instruction-only. On those hosts, tell the user guard mode is advisory: you will confirm before a destructive command and keep your own edits inside the boundary, but nothing blocks a tool call you get wrong.
Copilot CLI is the exception. When the configuration payload is installed (./install --with-config or --only=config), the user hook file ~/.copilot/hooks/vibestack.json (under $COPILOT_HOME when set) enforces both halves: the destructive-command and gate-file check is always on, in every session, and the edit boundary blocks while a freeze directory is set. Without the configuration payload it is instruction-only there as well.
Ask the user which directory to restrict edits to:
"Guard mode: which directory should edits be restricted to? Destructive command warnings are always on. Files outside the chosen path will be blocked from editing."
Once the user provides a path, set it with the shared state writer (see /freeze):
bash "${CLAUDE_SKILL_DIR:-$HOME/.claude/skills/guard}/../freeze/bin/freeze-state.sh" set "<user-provided-path>"Report guard mode active only if the command exits 0 and prints FREEZE_DIR=. On FREEZE_ERROR (a mistyped or missing path, or /), tell the user no edit boundary was set and ask for the path again. On FREEZE_BUSY, retry once the other writer finishes; never write or delete the state file directly.
Tell the user:
/ or ~, force-push to the default branch) are blocked outright; an Edit or Write to a gate file (lint, type-check, CI or migration config) also warns"<FREEZE_DIR>/. Edits outside this directory are blocked."~/.vibestack/freeze-dir.txt and outlives this session: any later session that loads the freeze hook (/freeze, /guard, /investigate) enforces it again. To remove it, run /unfreeze. Ending the session turns off the destructive command guard only."See /careful for the two decision tiers, the full pattern list, and the safe exceptions. See /freeze for how edit boundary enforcement works.
Both hooks fail safe when they cannot read a tool payload — /careful asks, /freeze denies. Guard mode runs both, so an unreadable Edit, Write or NotebookEdit payload is blocked, not waved through.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.