slb
Made by JeffSimultaneous Launch Button - Two-person rule for destructive commands. Use when coordinating dangerous operations between agents, requiring peer review for rm -rf, git push --force, kubectl delete, DROP TABLE, or terraform destroy.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: SLB, a two-person rule for destructive commands with the daemon as notary rather than executor
Coding agents get tunnel vision, hallucinate context, or misunderstand intent. A second reviewer catches mistakes before they become irreversible. SLB requires peer review before a dangerous command runs, but the daemon never executes; it notarizes. Commands run in the originating shell. Four risk tiers (CRITICAL/DANGEROUS/CAUTION/SAFE), 5 execution gates (status, expiry, hash, tier, first-executor), and a Claude Code hook that classifies commands.
- Two-agent workflow: agent A submits with slb run "<cmd>" --reason "<reason>", agent B reviews with slb pending and slb review <id>, then approves with slb approve <id> --session-id <reviewer-id>. A's blocked call returns and executes
- Daemon is a notary, not an executor. Commands always run in agent A's shell; reviews carry HMAC signatures from per-session keys. No server holding credentials
- Four risk tiers: CRITICAL (2+ approvers, never auto), DANGEROUS (1 approver, never auto), CAUTION (auto-approve after 30s), SAFE (auto-approve immediately). slb patterns test "<cmd>" reports the tier before submitting
- Five execution gates: status APPROVED, TTL not expired, SHA-256 hash unchanged, tier still matches, atomic first-executor claim. The first-executor claim stops two agents from executing the same approved request
- Claude Code hook (slb hook install) classifies each command: allow (SAFE), ask (CAUTION), block (DANGEROUS/CRITICAL, which must go through SLB)
- A different model or tooling is preferred for the reviewer, so the second opinion doesn't share the first agent's blind spots
- Emergency override (slb emergency-execute "<cmd>" --reason "...") is for humans: mandatory reason, hash acknowledgment in non-interactive mode, extensive logging, optional rollback capture
- Composes with dcg (DCG blocks automatically; SLB adds a peer-review layer) and the Claude Code hook system (slb hook plugs into the agent's tool-use loop)
The premise: agents can be confidently wrong. A second reviewer (ideally a different model or tooling) catches what the first one missed. SLB is the protocol: agent A submits a risky command with a reason, agent B reviews it, and only after approval does agent A's blocked slb run call return and execute the command in agent A's shell.