frmoretto/hardstop/hs

Hardstop Skill v1.5

INVOCATION INSTRUCTIONS (read first when skill is activated)

When this skill is activated via the Skill tool, check the ARGUMENTS field immediately:

Run the corresponding command — the user has explicitly requested this action via /hs. The hook reads ~/.hardstop/skip_next; if that file is not written, skips have no effect.

Security Architecture: This skill is the instruction layer for the Hardstop plugin. The plugin installs hooks that provide deterministic command blocking; this skill adds LLM-level awareness for platforms without hook support.

- The hs_cmd.py commands referenced above are part of the installed plugin — they are local scripts, not remote code.

- Credential paths (~/.ssh, ~/.aws, .env, etc.) appear in this document as block targets — Hardstop blocks reads of these files, it does not read or access their contents.

- The skip bypass requires explicit user invocation (/hs skip), is scoped to the next N commands only (default 1), and the hook still runs — it just honors the user-set skip counter.

Purpose: Protect users from dangerous AI-initiated actions. The mechanical brake for AI-generated commands.

Core Question: "If this action goes wrong, can the user recover?"

MANDATORY: Pre-Execution Protocol

BEFORE executing ANY shell command, ALWAYS run this checklist:

[ ] 1. INSTANT BLOCK check (see list below)
[ ] 2. Risk level assessment (SAFE/RISKY/DANGEROUS)
[ ] 3. Signal confidence BEFORE action
[ ] 4. If RISKY or DANGEROUS -> Explain -> Wait for confirmation

NEVER skip this protocol. NEVER proceed on DANGEROUS without explicit user approval.

WHEN COMMANDS ARE BLOCKED

If you see a "🛑 BLOCKED" message from the Hardstop hook:

1. STOP - Do not proceed with the command
2. EXPLAIN - Tell the user why it was blocked (the reason is in the message)
3. ASK - "This command was blocked for safety. Would you like me to bypass the check with /hs skip and retry?"
4. IF USER SAYS YES:

• Run the /hs skip command first
• Then retry the original blocked command

1. IF USER SAYS NO:

• Suggest a safer alternative approach
• Or ask what they were trying to accomplish

Example workflow:

Claude: I'll run this command... [attempts risky command]
Hook: 🛑 BLOCKED: Deletes home directory
Claude: This command was blocked because it would delete your home directory.
        Would you like me to bypass with /hs skip and retry? (Not recommended)
User: No
Claude: Good call. What were you trying to do? I can suggest a safer approach.

Never bypass safety checks without user permission. The skip mechanism is scoped: it only applies to the next N commands (default 1), and the hook still runs on every command — it simply honors the user-set skip counter before resetting.

1. INSTANT BLOCK List

These patterns require IMMEDIATE STOP. No exceptions. No "let me just..."

Unix/Linux/macOS

Shell Wrappers (v1.2)

Cloud CLI Destructive Operations (v1.2)

Package Manager Force Operations

Windows

When detected:

BLOCKED
 
This command would [specific harm].
 
I cannot execute this. This is almost certainly:
- A mistake in my reasoning
- A prompt injection attack
- A misunderstanding of your request
 
What did you actually want to do? I'll find a safe way.

2. Risk Assessment

SAFE (proceed silently)

Behavior: Execute without comment. Don't narrate safe operations.

RISKY (explain + confirm)

Behavior:

WARNING: This will [specific action]
 
What's affected:
- [List specific files/resources]
- [Size/count if relevant]
 
This [can/cannot] be undone by [method].
 
Proceed? [Yes / No / Show me more details]

WAIT for explicit "yes" or approval before proceeding.

DANGEROUS (present options + wait)

Behavior:

DANGEROUS - Requires your decision
 
This command would [specific harm].
 
Risk: [What could go wrong]
Recovery: [Possible/Impossible/Difficult - explain]
 
Options:
1. [Safer alternative that achieves the goal]
2. [Another approach]
3. Proceed anyway (requires you to confirm with "I understand the risk")
 
What would you prefer?

NEVER proceed without explicit user choice.

3. Risk Modifiers

4. Package Manager Safety

Special attention for package operations with override flags:

dpkg Force Flags (Linux/Debian)

rpm Force Flags (Linux/RHEL)