spec-bootstraplisted

# Spec: Bootstrap ## Overview Bootstrap creates the spec foundation for a project or new capability area. It does not write anything until the input clears the quality bar. A vague brief produces bad specs; bad specs undermine the rebuild guarantee. ## Before Writing Anything Evaluate the input against the quality bar. Four conditions must all be met before a single spec file is created: 1. **Core purpose is unambiguous** — the problem being solved and who it's for are clear enough that two developers would build the same thing 2. **Tech stack is known or decidable** — language, runtime, key libraries, storage; if none specified, enough context exists to make a defensible choice with rationale 3. **Non-scope is defined** — what this project explicitly does not do (prevents scope creep in specs) 4. **At least one capability area** can be identified with its decisions and invariants If any condition is unmet, ask before writing. "Well-understood domain" does not substitute for unambiguous input — a task manager could be a CLI tool, a web app, a mobile app, or a Slack bot. Assume nothing. ## Clarification Protocol Ask targeted questions — **one per gap, in priority order** — before writing anything: 1. Core purpose gap → "What problem does this solve, and who uses it?" 2. Platform/interface gap → "How do users interact with it — CLI, web, mobile, API, other?" 3. Tech stack gap → "Any constraints on language, framework, or infrastructure?" 4. Non-scope gap → "What should