structural-verifying

Verifies fixes, features, and migrations against running-system behavior with red-before-green proof.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-verifying-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: structural-verifying
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/structural-verifying
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-verifying-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often declare work done based on a passing unit test or a green diff, only to discover the bug still exists in production. This Skill enforces running-system verification: reproduce the failure where it lived, then prove it passes where the code will actually run. ## Core Features & Use Cases - Red-before-green proof: Reproduce the original defect before the fix and confirm it is gone after, so a green check actually means something. - Boundary and failure-path checks: Drive worst-case inputs (oversized, malformed, hostile, wrong auth) and exercise timeouts, dependency outages, and fallback paths. - Concurrency, scale, and prod-like validation: Run stateful operations twice, concurrently, and interrupted; verify cost-bearing paths at reachable scale in staging or canary environments. - Use Case: After fixing a race condition in a job queue, use this Skill to structure proof: replay the failing scenario, run the job concurrently, watch production-like signals, and pin a permanent regression test. ## Quick Start Ask the agent to verify that your recent fix actually works in a running system using the structural-verifying checklist.

Frequently Asked Questions about structural-verifying

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

FAQPage Schema
How do I verify a bug fix actually works in production?

Reproduce the original failure before the fix, then prove it is gone after the fix in a staging, canary, or prod-like environment. Watch the signals you shipped and keep a permanent regression test for the escaped bug.

What is red-before-green verification?

Red-before-green means the test or check must fail against the original defect before it passes with the fix. A green check that was never red proves nothing about the bug it claims to cover.

Why is a passing unit test not enough verification?

A unit test only proves isolated logic, not running-system behavior. Verification must exercise acceptance criteria, worst boundary inputs, failure and degraded paths, and concurrency or scale risks where they exist.

How do I test failure and degraded paths in a release?

Exercise timeouts, dependency outages, open circuit breakers, and visible fallbacks deliberately. Run stateful operations twice, concurrently, and interrupted where those risks exist, and confirm behavior in prod-like configuration.

When should performance claims be verified at scale?

Verify cost-bearing paths at reachable scale whenever the caller can send large input, or assert a stable query count or algorithmic bound. Verifying on toy data while production sends large payloads is a red flag.