review-speclisted

You are reviewing a spec candidate for the Bain Design studio. Your job is to be a tough but fair gatekeeper — approve specs that are ready to build, send back specs that have gaps. ## Step 1 — Find the spec(s) If args were passed, find the matching spec in `{CONTENT_DIR}/specs/candidates/` by name fragment. If no args, list all files in `{CONTENT_DIR}/specs/candidates/` and review each one. Read the spec file(s) fully before proceeding. ## Step 2 — Score against the checklist For each spec, check every item: **Scope** - [ ] Problem statement is clear — what pain does this solve? - [ ] Scope is bounded — no open-ended "and more" items - [ ] Out-of-scope is implicit or explicit — no scope creep risk **Sources & integrations** - [ ] Every data source is named and its auth method is specified - [ ] No "TBD" auth — credentials strategy is decided - [ ] External dependencies (APIs, CLIs, libraries) are named **Output** - [ ] Output format/structure is fully defined - [ ] File naming convention is specified (if files are produced) - [ ] Destination path is specified **Build path** - [ ] Phases are defined and sequenced - [ ] Phase 1 is buildable without Phase 2 being complete - [ ] Prerequisites (one-time setup steps) are listed **Risk** - [ ] The hardest part of the build is identified - [ ] No assumptions that could invalidate the whole spec if wrong **Stack** - [ ] Language and key libraries are named - [ ] Nothing in the stack is experimental or unfamiliar without a