authoring-gate-hooks

Write and review allow-or-deny gate hooks that fail closed on unparseable input.

Updated Apr 16, 2025
One-click install
npx skills add https://github.com/damoke012/eks_code --skill authoring-gate-hooks-damoke012
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: authoring-gate-hooks
Source: https://github.com/damoke012/eks_code/tree/main/.claude/skills/authoring-gate-hooks
Command: npx skills add https://github.com/damoke012/eks_code --skill authoring-gate-hooks-damoke012

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Guards that block dangerous actions often fail silently: a parser error gets swallowed, the empty result is read as "nothing to inspect", and a malformed payload carrying a real production mutation sails through while the test suite stays green. This Skill teaches how to design PreToolUse hooks, pre-commit checks, admission policies, and CI gates that fail closed instead of open. ## Core Features & Use Cases - Boundary definition: Forces you to write down what the gate guards, three commands it must block, three similar commands it must pass, and what happens on unreadable input before writing any code. - Fail-open trap detection: Shows the classic bug pattern (2>/dev/null hiding a dying parser, empty output treated as safe) and the fail-closed fix that scans raw input when parsing fails. - Four-case test suite: Pins garbage input (allow), truncated input with real mutation (block), renamed keys (block), and a well-formed control (block), then mutation-tests the gate itself by verifying the suite goes red against the broken version. - Advisory-to-gate promotion: Covers the inverse failure where a new check added to a working path fails closed and causes an outage, with a rule for shipping new checks as advisory warnings until proven on real inputs. - Use Case: You are adding a hook to block mutating kubectl commands against production. Use this Skill to define the boundary, write the fail-closed parser, and pin the four-case test so a malformed payload can never bypass the guard. ## Quick Start Ask the AI to write a PreToolUse hook that blocks destructive commands against production, applying the fail-closed pattern and the four-case test from this Skill.

Frequently Asked Questions about authoring-gate-hooks

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a hook that blocks dangerous commands?▼

Start by writing down the exact resource guarded, three commands that must block, three similar commands that must pass, and the behavior on unreadable input. Then implement the matcher so any parse failure falls back to scanning the raw payload rather than allowing it.

What is the fail-open trap in PreToolUse hooks?▼

The fail-open trap occurs when a hook hides parser errors with 2>/dev/null and treats the resulting empty output as nothing to inspect. A malformed payload carrying a real mutation then passes the guard, and tests using only well-formed input never catch it.

How do I test that a guard hook actually works?▼

Use a four-case suite: garbage input allows, truncated input with a real mutation blocks, a renamed key blocks, and a well-formed control blocks. Then mutation-test by restoring the broken version and confirming the suite goes red, and verify the hook is actually registered.

Why did my check pass but the hook never ran?▼

A green test suite does not prove the guard is wired in. A hook file that exists but is not registered in settings never executes, so verify registration in the maintenance script rather than relying on the file's presence.

When should a new check be advisory instead of a hard gate?▼

Any check added to a path that already works should start advisory, because an unproven permission or precondition can make it fail closed and break the working path. Promote it to a hard gate only after seeing it pass on real inputs with the real identity.

Why does my guard block documentation that quotes a protected command?▼

A guard that pattern-matches raw command text cannot distinguish executing a command from quoting it in a runbook or heredoc. Strip heredoc bodies before matching and pin that as a test case so documenting the danger stays possible.