What problem does it solve? Teams using SpecBind need a disciplined way to decide which durable specification boundaries a change request belongs to before any lifecycle state is mutated. This Skill turns a change request or an explicit Source Collection into a confirmed scope proposal, preventing scope from being built on guesses or applied without user approval. ## Core Features & Use Cases - Scope classification: Classifies each part of a request as Direct work, an existing Spec update, or a new Spec, based on ownership rather than size, and names the gates that must be invalidated. - Source Collection providers: Acquires complete read-only snapshots from explicitly supplied local files or a GitHub Milestone (OWNER/REPO plus number), with full source coverage reporting and version-shaped release label binding. - Confirmation-first mutation: Presents a four-field confirmation payload (work items, new Specs, gate invalidations, dependencies) and performs CLI-driven rewinds, milestone creation or scope updates, Brief authoring, and adapter-directed checkpoints only after explicit approval. - Use Case: A maintainer supplies acme/widgets Milestone 3 and asks to plan the release; the Skill reads every Issue, proposes the work-item decomposition, and after confirmation creates the milestone scope, writes per-Spec Briefs, and binds the release label. ## Quick Start Ask the assistant to use sb-discovery to classify your change request or a supplied GitHub Milestone into milestone scope and confirm the proposed work items before anything is changed.
