tdg-personal/gateguard
Fact-forcing gate that blocks Edit/Write/Bash (including MultiEdit) and demands concrete investigation (importers, data schemas, user instruction) before allowing the action. Measurably improves output quality by +2.25 points vs ungated agents.
46
46%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
17%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description reads more like an internal technical specification or research finding than a skill description meant to help Claude select the right tool. It lacks natural trigger terms, has no 'Use when...' clause, and the marketing-style quality claim (+2.25 points) adds no selection value. The core concept—requiring investigation before making changes—is buried under jargon.
Suggestions
Add an explicit 'Use when...' clause describing the situations where this gate should activate, e.g., 'Use when Claude is about to edit code or write files without first verifying facts, schemas, or user requirements.'
Replace jargon like 'fact-forcing gate' and 'ungated agents' with natural language a user or Claude would recognize, e.g., 'Enforces a research-before-editing workflow to ensure changes are grounded in actual project data.'
Remove the benchmark claim (+2.25 points vs ungated agents) as it provides no selection signal and replace it with concrete examples of what 'investigation' means (e.g., reading imports, checking data models, confirming user intent).
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names some concrete actions (blocks Edit/Write/Bash, demands investigation of importers/data schemas/user instruction) but the description is more about the mechanism than listing specific capabilities the skill performs for the user. | 2 / 3 |
Completeness | Describes what it does (blocks actions until investigation is done) but has no 'Use when...' clause or equivalent explicit trigger guidance. The 'when' is entirely missing, which per the rubric caps completeness at 2, but the 'what' is also unclear from a user perspective, warranting a 1. | 1 / 3 |
Trigger Term Quality | Contains technical jargon like 'fact-forcing gate', 'MultiEdit', 'ungated agents' that users would never naturally say. No natural trigger terms a user would use when needing this skill. | 1 / 3 |
Distinctiveness Conflict Risk | The concept of a 'fact-forcing gate' is somewhat distinctive, but the description's mention of Edit/Write/Bash is broad enough to potentially conflict with any skill involving code editing or file manipulation workflows. | 2 / 3 |
Total | 6 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill has a clear and novel concept with well-defined gate types and specific prompt templates that are genuinely useful. However, it spends too many tokens on motivation and evidence that Claude doesn't need, the Quick Start lacks complete executable setup instructions, and the workflow between gate stages could be more explicit about validation and error recovery.
Suggestions
Remove or drastically shorten the 'Core Concept' motivation and 'Evidence' sections — Claude doesn't need to be convinced, it needs instructions. Move these to a separate RATIONALE.md if desired.
Complete the Quick Start with actual hooks.json configuration content or a full working example showing how the gate integrates, rather than just referencing a file path.
Add an explicit validation step between FORCE and ALLOW — e.g., 'If the presented facts reveal unexpected imports or schema mismatches, revise the planned edit before proceeding.'
Show a concrete end-to-end example of a gate firing: the blocked action, the investigation output, and the allowed retry, so Claude can pattern-match on real usage.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill includes some unnecessary content like the 'Core Concept' section explaining why self-evaluation doesn't work (Claude doesn't need this motivation), the evidence table with A/B test results, and repeated emphasis on experimental verification. However, the gate templates themselves are lean and useful. | 2 / 3 |
Actionability | The gate prompt templates are concrete and specific, which is good. However, the Quick Start options are incomplete — Option A references a hook file path but doesn't show the hooks.json configuration, and Option B's `pip install gateguard-ai` and `gateguard init` lack follow-up on what to configure or verify. There's no complete, copy-paste-ready implementation. | 2 / 3 |
Workflow Clarity | The three-stage gate (DENY → FORCE → ALLOW) is clearly described conceptually, and the gate types are well-differentiated. However, there's no explicit validation step after the facts are presented — how does the gate verify the facts are sufficient before allowing the action? The feedback loop between FORCE and ALLOW is implicit rather than explicit. | 2 / 3 |
Progressive Disclosure | The content is reasonably well-structured with clear sections, but it's somewhat monolithic — the evidence section, anti-patterns, and best practices could be trimmed or moved to a separate file. The references to related skills and the hook file are good, but the inline content is heavier than needed for a SKILL.md overview. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents