Pre Send

/pre-send — Approval ritual for outbound sends

Partner skill to the send-gate.sh PreToolUse hook (ships in [hooks/send-gate.sh](./hooks/send-gate.sh)). The hook blocks every external-send tool unless /tmp/claude-send-approved exists and is │ Channel: │ Recipient: │ Subject: │ Thread: │ Body: │ │ │ Attachments: ╰───────────────────────────────────────────────────────

## Step 3 — Run quality checks (silent unless a check fails)

Before asking for approval, validate:

1. **Voice / style rules** — load whatever local rules you have for outbound (signature per channel, threading expectations, identity framing, no em dashes, formality level). Check the draft against them.

2. **Commitment detection** — scan body for commitment patterns ("I'll", "I will", "we'll", "let me", "I'm going to", "expect [X] from me", and equivalents in any other language you write in). If matched: surface with `⚠ Commitment detected: ""` and ask if the user wants a task created in their task system after send.

3. **Leaked secret scan** — regex for obvious tokens: `sk-[a-zA-Z0-9]`, `eyJ[A-Za-z0-9_-]+\.` (JWT), `ghp_[A-Za-z0-9]+`, `Authorization: Bearer`, 40+ char hex sequences, `password`/`api_key` with `=` or `:`. Surface any match and REFUSE to set the flag until cleaned.

4. **Modified-draft check** — if the user previously approved a draft in this session, verify the current draft body matches or the user acknowledges the change. **Exception: voice-rule compliance fixes** (em-dash → period, missing signature added, greeting normalization, formatting cleanup, trailing whitespace) apply automatically without re-approval — they're mechanical and bring the draft INTO compliance with already-approved rules. Content changes (new claims, different recipient, different ask, different quantity/price/date) require explicit re-approval. Rule of thumb: if the fix is "something the user's voice rules would have required anyway", apply silently and proceed to Step 5.

   **Structural backstop:** the 300s TTL + single-use flag mean every send requires a fresh /pre-send invocation that re-shows the current body. Drift between approval and send is bounded by 5 minutes; the second send needs a second /pre-send. This is what makes re-approval enforceable rather than purely behavioural.

If any check fails: surface the finding, ask the user whether to proceed anyway (commitment/modified-draft are advisory) or fix (secret leak is non-negotiable).

## Step 4 — Require explicit confirmation

Ask verbatim: `Send it? (reply "send it" / "ship it" / "go ahead" to confirm — any other reply aborts)`.

Accept as confirmation:
- `send it`, `send`, `ship it`, `ship`, `go ahead`, `yes send`
- equivalents in other languages you operate in
- case-insensitive, leading/trailing whitespace OK

Reject as confirmation:
- `ok`, `go`, `start`, `proceed`, `yes` alone — all ambiguous and historically misinterpreted
- Any negative or neutral reply

If rejected: say `Aborting /pre-send. Flag NOT set. Re-run when ready.`

## Step 5 — Create the approval flag

On confirmation:
```bash
touch /tmp/claude-send-approved

The flag gets the current mtime. The gate checks mtime within 300s TTL and consumes (rm) the flag on allow. So ONE /pre-send → ONE send. For a second send, re-run /pre-send.

Emit: ✓ Approved. Calling now. Then IMMEDIATELY invoke the send tool — the gate passes, the tool fires, the flag is consumed.

Step 6 — After send

After the send tool returns success:

• Log to your CRM / system-of-record if relevant.
• If a commitment was detected in Step 3 and the user said yes, create the follow-up task in your task system.
• Never silently retry on failure — surface the error so the user can decide whether to re-approve or abandon.

Optional: autopilot exception

The bundled hooks/send-gate.sh whitelists sessions that opt in to autopilot mode (env var CLAUDE_AUTOPILOT_SESSION=1, or a tmux session name matching the autopilot pattern). If you build a long-running unattended automation that legitimately needs to send without per-message human approval, set that env var. Use sparingly — the gate exists for a reason.

Failure modes

• Flag exists from earlier, still fresh — the hook consumes it on first send; /pre-send recreates on next invocation. No conflict.
• Concurrent sends from two sessions — single-use flag: whichever session's send tool fires first consumes the flag; the second blocks. Expected.
• TTL expired between /pre-send and send — hook blocks with stale-approval message. Re-run /pre-send. Doesn't happen if send fires immediately after approval (typical case).
• Secret leak detected — refuse to set flag. User fixes draft and re-runs.

Why This Exists

Three categories of failures drove this skill:

1. Interpreted confirmations — agent reads "start" or "go" as "send it" and fires.
2. Modified-draft drift — user approves draft v1, agent edits to v2, fires v2 without re-confirmation.
3. Wakeup-triggered sends — a deferred task fires without a human in the loop and infers approval from the wakeup prompt itself.

The behavioural rule "never send without explicit approval" existed in all three cases and was violated anyway. The structural fix — a PreToolUse hook that physically blocks the send unless a fresh single-use flag exists, paired with this skill as the ONLY supported path to creating that flag — removes the interpretation layer entirely.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: davidsimoes
• Source: davidsimoes/claude-skills-shared
• License: MIT

Install and usage instructions live in the source repository linked above.