scope-checklisted

# Scope Check Enumerate a ticket's acceptance criteria into a checklist BEFORE any code is written, then re-state the checklist after each commit until every box is ticked or explicitly deferred. ## When this skill activates This skill is **auto-loaded by description match**, not by a typed slash command. Claude loads it when: - The user mentions a ticket ID (`NAPP-1234`, `PROJ-456`, `#123`) - The user asks "what's the scope of X" / "what does ticket Y cover" - The user references "acceptance criteria" or "AC" - A parent skill (`/etk:fix-bug`, `/etk:develop`, `/etk:review-mr`) delegates to it as Phase 0 There is no `/etk:scope-check` slash command on purpose — invisible enrichment is the contract. ## Why this exists Recurring `/insights` friction: - **Narrower than intended** — "you only fixed one of three findings"; "shipped login events when the ticket covered login + reset + help" - **Wider than intended** — "you refactored adjacent code without asking" A 60-second AC enumeration up front catches both classes. The checklist becomes the contract Claude is held to, not the user's recollection of the ticket. ## Workflow ### Step 1: Detect the ticket source Inspect the conversation and working directory: | Signal | Source | |---|---| | Ticket ID matches `^[A-Z]+-\d+$` (e.g., `NAPP-3589`, `PROJ-12`) | Jira | | Reference like `#123`, `gh issue 123`, `github.com/.../issues/123` | GitHub | | Branch name embeds a ticket ID (e.g., `feat/NAPP-3589-login-redesign`) | Jira