drive-featurelisted

# drive-feature - audit the feature end-to-end against its spec drive-feature asks: **"does this feature actually work, for every case someone might hit, in a way that matches what we said we were building?"** It's a logic-and-completeness audit, not a code-style pass and not a UX walkthrough. It traces the data flow from entry to exit (UI → API → service → repository → side effects) and checks each step for: - **Edge cases** - empty, null, large, concurrent, out-of-order, partial. - **Error handling** - every failure has a defined, surfaced response. - **Loading / pending states** - explicit idle, loading, success, error. - **Side effects** - analytics, logs, DB writes, jobs, emails, webhooks: intentional, documented, idempotent. - **Spec match** - ADR/spec vs. what the code actually does. The skill produces a **gap list**. It applies obvious fixes inline but leaves judgment calls to the user. ## Phase 0 - Find the spec The spec is the source of truth. Look for one before reading any code. Search in this order; collect all hits, don't stop at the first: ```bash # ADR / RFC directories (common conventions) fd --type f --extension md . \ docs/adr docs/architecture docs/rfcs docs/specs \ adr architecture rfcs specs \ .docs design-docs 2>/dev/null # Feature-named docs rg -l --type md "<feature-name-or-keyword>" docs/ .docs/ 2>/dev/null # PR description and linked issues gh pr view --json body,closingIssuesReferences --jq '.body, .closingIssuesReferences' # Then fo