stop

Gate implementation on BDD scenarios in features.json with evidence-based verification.

1|Updated Apr 24, 2026
One-click install
npx skills add https://github.com/shawnpetros/claude-skills --skill stop-shawnpetros
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stop
Source: https://github.com/shawnpetros/claude-skills/tree/main/stop
Command: npx skills add https://github.com/shawnpetros/claude-skills --skill stop-shawnpetros

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents “it works on my machine” releases by requiring verifiable BDD scenarios before implementation and forcing evidence-based verification after changes.

Core Features & Use Cases

  • Gate In (Plan-to-Code): Extracts and stores BDD scenarios in features.json (with passes: false) before you start implementing.
  • Gate Out (Verification Loop): Verifies each unpassed scenario with concrete evidence (tests preferred, runtime validation otherwise) and flips passes: true only after successful observation.
  • Optional Enforcement Hooks: Supports hard and soft enforcement via Claude hooks to block or remind at key moments in the workflow.
  • Practical Scenario Guidance: Provides scenario quality checks, loop caps, and structured findings output.

Quick Start

Use the stop skill to turn your spec into features.json scenarios, implement only what those scenarios require, and then verify every scenario before marking the feature complete.

Frequently Asked Questions about stop

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

FAQPage Schema
How do I enforce BDD scenario verification before shipping code?

BDD scenario verification gates implementation by storing scenarios in features.json with passes set to false, then flips passes to true only after observing concrete evidence during a verification loop.

What is spec-driven development gating for release readiness?

Spec-driven development gating requires writing BDD scenarios with id, description, given, when, then, and passes fields to features.json before coding, then verifying each scenario with observable evidence to prove release readiness.

How do I structure BDD scenarios in features.json for scenario gating?

Scenarios in features.json require a schema containing id, description, given, when, then, and a passes field initialized to false, which only changes to true after successful evidence-based verification.

Can I use automated hooks to block deployments when BDD scenarios fail?

Optional enforcement hooks support hard and soft enforcement to block or remind teams at key workflow moments, ensuring unpassed BDD scenarios prevent code from being marked as complete.

What happens when a BDD scenario is blocked during the verification loop?

The verification loop handles blocked cases explicitly by requiring observable evidence to set passes to true, preventing scenarios from being silently skipped or falsely marked as passed during validation.

Does spec-driven development gating work for ad-hoc and trivial code patches?

Scenario gating applies across planned, ad-hoc, and trivial implementation tiers, ensuring regression-proof patches and post-implementation validation even for minor changes outside standard planning workflows.