design-gate-audit

Audits design doc acceptance gates for honesty and feasibility before implementation begins.

2|Updated Jul 18, 2026
One-click install
npx skills add https://github.com/Arasz/ai-badger --skill design-gate-audit-arasz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-gate-audit
Source: https://github.com/Arasz/ai-badger/tree/main/features/common/skills/design-gate-audit
Command: npx skills add https://github.com/Arasz/ai-badger --skill design-gate-audit-arasz

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Acceptance gates in design docs often certify broken or vacuous behavior: tests that pass for the wrong reason, negative assertions that can never fail, or gates referencing test files and seams that do not exist. This Skill audits every gate before implementation so the design doc cannot green-light broken features. ## Core Features & Use Cases - Honesty checks: Attacks each gate for vacuous negatives, timing-window vacuity, poll-interval vs timeout conflicts, unprovable real-time halves, routing/dispatch false negatives, port races, and process-global env poisoning. - Feasibility verification: Greps the actual test project to confirm named test files, patterns (FakeTimeProvider settles, host-shape pins, E2E factories), and production seams exist, and verifies factual claims like "no test churn" by counting literal constructions. - Structured report: Emits a verdict summary, findings table with MUST-FIX/SHOULD-FIX/NIT severities, per-criterion HONEST/FEASIBLE verdicts, corrected TDD order per work package, and missed test cases. - Use Case: Before implementing a BackgroundService idle watchdog design with 13 acceptance gates, run the audit to catch that a "shutdown within 5s" gate is unsatisfiable with a 1-minute poll loop and that a negative pin passes whether or not routing exists. ## Quick Start Audit the acceptance gates in my design doc for honesty and feasibility before I start implementing the work packages.

Frequently Asked Questions about design-gate-audit

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

FAQPage Schema
How do I audit acceptance criteria in a design doc before implementation?

Check every gate against two questions: would it fail if the feature were broken (HONEST), and does the named test file, framework, or seam actually exist (FEASIBLE). Verify feasibility by reading the real test project rather than trusting the doc, then attack each gate for wrong-reason passes and vacuous negatives.

What is a vacuous negative test and how do I detect it?

A vacuous negative is an assertion like "X not called before timeout" that passes regardless of correctness, often because the first fake-clock Advance after StartAsync is lost. Fix it by following negative assertions with a settled positive or by using invocation counters on fakes.

Why does a shutdown-timeout gate fail with a polling BackgroundService?

A gate expecting shutdown within ~5 seconds is unsatisfiable when the loop polls every minute, since shutdown fires up to one poll late. The design must derive poll interval from the timeout (e.g. poll = min(baseline, timeout/2)) or the gate must be rewritten.

Can I use WebApplicationFactory to test blocking entry-point paths?

No. WebApplicationFactory uses TestServer, which replaces Kestrel, so bound-URL and blocking-run semantics are unrepresentative. Use a dispatch seam with an injectable runner and positive pins, plus a held TcpListener for busy-port tests.

When should gate-honesty findings block a design doc?

Rate gate-honesty bugs as MUST-FIX even when the fix is only a design-doc edit, because the doc is the build contract. An unsatisfiable or vacuous gate certifies broken behavior, so it must be corrected before implementation starts.