extracting-acceptance-criterialisted

# Extracting Acceptance Criteria A feature description is usually a paragraph: "users should be able to create accounts with email + password, get a verification email, and log in once verified." That description has three or four implicit acceptance criteria woven together. This skill pulls them out into a list a builder can implement against and a reviewer can check. The output is the **input** to `authoring-acceptance-probe` (which probes each AC) and `dispatching-spec-review` (which verifies each AC was met). ## When to Invoke | Caller | Trigger | |---|---| | `/ship-discuss` | Right after the user's feature pitch crystallizes — convert prose into ACs before edge-case discovery | | `/ship-spec` | When auditing or rewriting a feature spec; pull ACs out of buried prose | | `/ship-sprint` | When breaking a feature into tasks, each task gets a slice of the feature's ACs | | `/ship-bug` | Convert a bug report into a regression AC ("the system shall not <symptom>") | If the spec already has a clean numbered AC list with one observable per item, don't invoke this skill — there's nothing to extract. Run `discovering-edge-cases` instead to find missing ACs. ## Inputs - `feature_text` — the prose description, user request, or existing spec section. - `parent_context` — optional pointer to the parent feature/epic for inheritance (a sub-feature inherits the parent's domain ACs unless overridden). - `domain_hints` — `["payments", "auth", "external-api", ...]`, used to pre-load d